I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids. This forces both source and sink to be part of the same network topology...why? What value is this? This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it? We should specify each STP 2-tuple independently. For example: a common topologyid does NOT force the source and sink to be part of a conventional duplex port pair: ( topology="Bonaire", port="B1in" ) := <switch="NYC", port="ge-0-3in", vlan="1780"> ( topology="Bonaire", port="B1out" ) := <switch="CPH", port="ge-0-3out", vlan="27"> Even though a SourceSTP contains ( topology="Bonaire", source="B1out", sink="B1in") there is no relationship otherwise between these two STPs. In this example, the source and sink are on different continents! Thus the common topology id is an arbitrary and unnecessary requirement imposed upon the source and sink. The protocol does not need this form. Regarding the Source and Sink STPs... If we want the source and sink to have some specific relationship, e.g be part of a duplex pair, then we need to specify those characteristic features in the topology database -e.g. a "duplex" attribute on one Port that identifies another Port as the duplex pair and vice versa. This is something that needs to be advertiseable, not fudged somehow. Having specified in the topology that two uni-directional ports are a duplex pair, we can request a bi-directional reservation that creates "bi-directional" connections from the "duplex" pairings. If we want to specify the forward and reverse paths explicitly, we should not require them to have the same number of transit points or otherwise constrain the path they take or their characteristics (e.g. capacity or administrative topology). Thus, if we want to specify forward and reverse paths explicitly, we simply issue two separate uni-directional connection requests. If we wish to force the forward and reverse paths to relate to each other in some broadly useful specific way (e.g. a duplex reverse path of equal capacity), then we should not give the requester the ability to specify both paths - it is unnecessary and it may not be correct...i.e. the path finder should ignore the user's specified reverse path and just build the reverse path that befits the defined relation to the users specified forward path. Thus all we need is a single forward path specification. I suggest we define a single directed path object. This object will always serve as the forward path object. A bi-directional service will use it also to build a reverse path using an explicitly identified topological "duplex" pairing attribute obtained from each element of the forward path. SO I propose the following: *proposal #1:* The Path object describes a single "forward" path. Each transit STP acts as a sink for the prior segment and a source for the subsequent segment. The STP elements of the path object may be uni-directional or bi-directional. Each transit element of the path object consists of a STP Reference - <topology><port><tv1>..<tvn> For uni-directional connections each element of the ERO will be interpretted as follows: a) if the ERO STP is a unidirectional Port, the pathfinder uses that uni port as the start of the next forward path segment and as the terminus of the preceding forward path segment. b) if the ERO STP is a bidirectional Port, the pathfinder uses the "sourcePort" associated with the STP to identify a uni-directional Port to be used as the start of the next (towards the Z end) forward path segment. This same uni-directed Port will be used as the terminus of the previous (towards the A end) forward path segment. For bi-directional connections, each element of the ERO will be interpretted as follows: a) if the ERO STP is a bidirectional Port, the pathfinder uses the sourcePort attribute of the STP to identify a uni port to be used as the start of the next (towards the Z end) forward path segment and as the terminus of the previous (towards the A end) forward segment. The pathfinder will use the sinkPort associated with the bidirectional STP as the start of the upstream (towards the A end) reverse path segment, and as the terminus of the downstream (from the Z end) reverse path segment. b) if the ERO STP is a unidirectional Port, the pathfinder uses that uni port as the start of the next forward path segment and as the terminus of the preceding forward path segment. The PF looks for a "duplex" attribute of the ERO STP to point to a paired uni port that will act as the transit point for the two duplex reverse segments. If an ERO STP does not specify a duplex port, an error is generated. *proposal #2:* I suggest we do away with the SourceSTP and DestSTP in the wsdl Reservation Request message. We instead use the ERO object to contain all transit points: ERO(0) will always be the SourceSTP, and ERO(n) is the DestSTP. This will allow the code to treat all segments the same - not have to treat the first and last segments specially in order to handle the SourceSTP and DestSTP objects. THoughts? Jerry On 9/6/12 1:09 PM, Guy Roberts wrote:

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

_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg

On 6 Sep 2012, at 23:56, Jerry Sobieski <jerry@nordu.net> wrote:

...

I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids. This forces both source and sink to be part of the same network topology...why? What value is this? This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it? We should specify each STP 2-tuple independently. No, the question should be the reverse, why would you ever want to have a reservation request with two different topology IDs in it? Yes I Agree. So what we have in the proposed triple form - _even with a single topology id _- is the ability to specify forward and reverse

On 9/7/12 2:26 AM, Jeroen van der Ham wrote: transit points that are widely geographicaly separated. There is no significant constraints imposed by a single topology. So while I agree with you that we do not want any particular hop to have widely geographically diverse forward and reverse paths, _/a single topology ID does not accomplish this./_ IMO, what we need to do is provide a single forward path ERO. And if the request is for a bi-directional service instance, then that service provider identifies the appropriate reverse path for the "bi-directional connection". If the requester specifies the forward and reverese path, then it is just two uni-directional service requests. And if so, then we should just do two requests so that the user has the ability to define the two paths independently. THis is why I am suggesting we have a single forward path ERO, and the reverse path is not specified in a request. If the request is a bi-directional connection, the provider will build the reverse path. So for such EROs there is not need for a triple at all...just the topology id and port id of the forward path. make sense? J

Think about what an NSA would do with that message, how would it handle that? It would have to forward half of the request to someone else? Why are the two unidirectional connections in the same request? Is there some reason that the need to be together?

Basically, having the possibility of two different topology IDs in a reservation request for one end of a connection opens up a huge can of worms for unexpected behavior. And it does not add anything we can already do. You can simply divide up your two unidirectional connections and request them separately with the same mechanics that we already have without having to change anything.

Jeroen.

Hi,

On 7 Sep 2012, at 12:16, Jerry Sobieski <jerry@nordu.net> wrote:

...

On 9/7/12 2:26 AM, Jeroen van der Ham wrote:

...

On 6 Sep 2012, at 23:56, Jerry Sobieski <jerry@nordu.net> wrote:

...

I do not believe it is appropriate or useful to distribute the "topology ID" across both the source and sink localids. This forces both source and sink to be part of the same network topology...why? What value is this? This does not force any relation to exist between the source and sink ports besides being part of the same topology file - so what is the use case or value of it? We should specify each STP 2-tuple independently. No, the question should be the reverse, why would you ever want to have a reservation request with two different topology IDs in it? Yes I Agree. So what we have in the proposed triple form - _even with a single topology id _- is the ability to specify forward and reverse transit points that are widely geographicaly separated. There is no significant constraints imposed by a single topology. So while I agree with you that we do not want any particular hop to have widely geographically diverse forward and reverse paths, _/a single topology ID does not accomplish this./_ I'm not trying impose geographical restrictions, I'm trying to add logical restrictions. STPs with the same Topology ID should go to the same NSA. This makes the whole behavior a lot more predictable. Yup - by definition: STPs with the same topology ID belong to the same NSA. This is always the case in NSI. But in specifying a path, we do not always want the forward and reverse components to transit the same

Hi Jeroen and all- Sorry this is a bit long - but I propose we do two things: 1) The ERO path be defined as a single [forward] path consisting of one STP reference per hop. 2) each network indicates in their topology description the duplex STP pairings to be used for reverse path construction for bi-directional services. Detail/discussion below. please read and comment. Thanks! Jerry On 9/7/12 7:37 AM, Jeroen van der Ham wrote: path elements. We could, for instance, request that the forward path transit one network, but the reverse path transit a different network. This is perfectly legal and useful. But it can't be done if you cannot specify a different topology Id for the forward and reverse STPs. I.e. /there is no inherent reason the forward and reverse hops must transit a single particular network or even traverse the same number of explicit hops./ Thus, the proposed triple (topology, source port, sink port ) constrains the source and sink to be in the same network - This does not solve any problem, thus is places arbitrary and unnecessary restrictions on path specification. We don't put unnecessary or arbitrary constraints into the standard. The more important question is: _/Do we actually need to specify a reverse path at all? /_ I suggest not. I recommend that we specify the forward path only in the ERO. Each hop would be: ( topology Id, port Id, tv1, tv2,... ). i.e. a STP Type/value reference. If a service request is asking for a uni-directional connection, then there is no need for reverse path ERO elements at all. If a service request is asking for a "bi-directional" circuit, then we let the Provider Agent construct the reverse path according to duplex pairing attributes defined in their topology. Thus, again, there is no need for a reverse ERO element. (Indeed, we can't actually identify the forward transit STP until the forward path segment is confirmed and we can get the "as-built" STP back.) If a "bi-directional connection request" has to do something special to build a bidirectional connection, i.e. not just build two uni-directional connections, then we need to _/define explicitly what a "reverse" path is meant to be./_ Otherwise, it is just another unidirectional connection. And if so, there is no need to have a special primitive that does two uni-directional connections in one request - we just perform two requests and simplify the protocol. If, however, a user wants a connection that has both a forward channel and a back channel, and the back channel transits ports that are "tightly coupled" in some specific manner with the transit ports in the forward path, then we really need a "bi-directional connection service" - it is not just two uni-directional connections. For example: If you want the reverse path to transit a particular receive port because it is associated with a particular transmit port on the forward path, then you need to specify what that "association" is - specifically. Its not implicit or self evident in anything we have adopted to date. The WG has not been able to provide a rigorous and concise definition of what a "bi-directional" Connection instance means. We all know it when we see it :-)...but we have nothing specific that can be adopted as either part of the NSI CS standard, nor even as part of a best practice or service definition. Thus, we are all over the place on how the ERO should look. From experience, we know such connections are generally made up of two adjacent - but separate - uni-directional data flows going in opposite directions - but this is not a formal specification and often not actually the case in the WAN or even the metro space. We have a notion of a "forward" and "reverse" data path - but what *_/SPECIFIC/_* characteristics do they exhibit relative to one another? What do we need defined within the topology database to enable a path finder to identify the topological objects that constitute a "reverse path" relative to some "forward path" ??? Here is my off-the-cuff definition of a "bi-directional" connection instance: -- It has a "forward path" defined by an ordered set of 2 or more STPs as specified in the path object (or ERO). The data flows along this forward path from the first STP ( ERO[0] ) to the last STP ( ERO[n] ). -- It has a "reverse path" defined by a set of STPs identified as "duplex" with the STPs in the forward path. -- The reverse path flows data in the opposite direction of the forward path (assuming the reverse path STPs are ordered in the same order as their corresponding forward path STPs.) -- Duplex STPs are indicated in the topology. (This relation may be any relation that provides the same semantic meaning.) -- The forward and reverse paths have equal capacity (This is not strictly necessary, but simplifies things.) -- The forward and reverse paths are linked. I.e. there is a formal service-specific relationship between the forward and reverse connections. together, they are/can-be treated as a single service instance. The advantage of these "bi-directional" characteristics is that the forward and reverse paths could be constructed by a RA independently. I.e. an RA could reserve a unidirectional connection, query its path, find the duplex STPs in the topology, reverse their order, and request a 2nd uni-directional connection. These two connections taken together would be technically equivalent to a single bidirectional connection - except that the two uni-directional connections would be seen as two separate service instances rather than one. If we adopt this definition for v2.0, then our ERO elements can be single STPs defining the forward path - very simple. A network service provider will define their network topology to be uni-directional STPs (NML Port objects, and will indicate the Port's duplex twin in the database. Note: perhaps the NML folks can concur with this, or pose an alternative relation defining the duplex pairs?) For example: Aruba a nml:Topology ; nml:version "2011112901" ; nml:hasOutboundPort Aruba:ams-ge1out ; nml:hasInboundPort Aruba:ams-ge1in . Aruba:ams-ge1out a nml:PortGroup ; nmleth:vlans "1780-1783" ; nsi:isDuplexWith ams-ge1in ; <---------------- duplexity nml:alias NetherLight:cph-a . Aruba:ams-ge1in a nml:PortGroup ; nmleth:vlans "1780-1783" ; nsi:isDuplexWith ams-ge1out ; <---------------- duplexity nml:alias NetherLight:cph-b . My proposal is to have the local network provide the appropriate forward/reverse pair mapping in their topology description. Bi-directional connection requests would then use that mapping for path construction. How we specify the mapping syntactically in the NML topology can be flexible...but it must be simple and consistent. Thoughts? Jerry

Jeroen.

Hi, On 10 Sep 2012, at 11:48, Guy Roberts <Guy.Roberts@dante.net> wrote:

Jeroen,

"IMO, what we need to do is provide a single forward path ERO. And if the request is for a bi-directional service instance, then that service provider identifies the appropriate reverse path for the "bi-directional connection". If the requester specifies the forward and reverese path, then it is just two uni-directional service requests. And if so, then we should just do two requests so that the user has the ability to define the two paths independently."

This is a simple and quite elegant solution, but I have a strong concern with this approach as it forces providers to describe their topology using a network modelling method where all STPs map to unidirectional STPs (exclusive use of bi-directional STPs would not be allowed) . This is quite a severe constraint for transmission equipment as ITU-T MIB models do not include uni-directional ports as part of their model.

I like that simple solution indeed. It provides for simple semantics of the reservation command, yet does not limit users in what they can reserve. I don't see the constraint for the bi/uni-directional STPs. In practice the names of STPs are not those of the original ports, and a mapping is defined to go from an STP name to the management-plane name of that port. The uni-directional names of those ports would work in a similar fashion. Jeroen.

Jeroen, I think that the SourceSTP and DestSTP need to be separated from the EROs for the following reasons: - for unidirectional connections the source and destination need to be identified - I don't like using the idea of using a convention that the first ERO in the list source and the last destination. - the two end STPs are mandatory whereas EROs are optional. Guy -----Original Message----- From: Jeroen van der Ham [mailto:vdham@uva.nl] Sent: 07 September 2012 10:04 To: Jerry Sobieski Cc: Guy Roberts; nsi-wg@ogf.org Subject: Re: [Nsi-wg] uml proposal for STPs path object specifications... Hi, On 6 Sep 2012, at 23:56, Jerry Sobieski <jerry@nordu.net> wrote:

*proposal #2:* I suggest we do away with the SourceSTP and DestSTP in the wsdl Reservation Request message. We instead use the ERO object to contain all transit points: ERO(0) will always be the SourceSTP, and ERO(n) is the DestSTP. This will allow the code to treat all segments the same - not have to treat the first and last segments specially in order to handle the SourceSTP and DestSTP objects.

In NSIv1 we had a query message where the source and destination of a reservation were separate of the path. It was a bit annoying that the path description did not include them. I do agree that the path object should include both the start and destination of a connection. However, the source and destination are still important characteristics of a connection request. They are used a lot more often than just the path of the object. Optimization is good, but we should try not to make this so obfuscated that it makes it hard to do the general things with these messages. Jeroen.