Jeroen, Your assumptions about my UML diagram are correct, but as I did not like my proposal very much, so I have sent 3 variations to the list for discussion. In response to your question about the 'ERO problem', I think even with bidirectional STPs we can get an unambiguous result from path computation if we use SDPs in ERO as follows: path is an ordered list of: AendSTP ((STPa, STPb), (STPc, STPd) ... ) ZendSTP where (STPa, STPb) is an SDP. Consequently for bidirectional connections I don't really see a case for uni-directional STPs, particularly since nml has a bidirectionalPort object it seems like a waste to re-produce this in NSI. So I propose that we use unidirectional STPs for unidirectional connections and bidirectional STPs for bidirectional connections. Regarding the LabelId = <type><value> tuple, I am wondering how we identify which types are allowed. I would like to allow the option of for example <type> = nmleth:vlans so we allow the user to add the nml namespace here.. .any thoughts? Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 06 September 2012 10:47 To: Guy Roberts Cc: nsi-wg@ogf.org Subject: Re: [Nsi-wg] uml proposal for STPs Hi, Let me try to see if I understand this correctly: - The StpType identifiers refer to unidirectional ports in the topology. - The PathType can be used to request a bidirectional reservation and then you need to use four different StpTypes, with pairs describing the two unidirectional connections I think there is problem with the current ERO definition, because it doesn't define which part of the unidirectional connection it refers to. A solution would be to make them a tuple, with the first element defining an ERO for the path from AendSrcSTP to ZendSinkSTP, and the second element an ERO for ZendSrcSTP and ZendSinkSTP. This is kind of messy, because if you use multiple EROs for the multiple connections you end up with (A,B'), (B,A') (with A,B the EROs for one direction and A',B' for the other). Perhaps we should use two separate ERO lists? Guy mentioned during the call that you may want to add a restriction that the path for both direction traverse the same cables, or you may want to explicitly request diverse paths. I think this should be possible to request without specifying EROs. Should we add path-attributes to the request to make that possible? Jeroen. On 5 Sep 2012, at 17:18, Guy Roberts <Guy.Roberts@dante.net> wrote:
Here is a possible unidirectional STP shown in UML format:
<image001.png>
_____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316
DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net Like us on: www.facebook.com/GEANTnetwork Follow us at: www.twitter.com/GEANTnews
DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg