Hi all, Due to the way that the original AutoGOLE topologies were generated everyone is currently using separate hasInboundPort Relation elements for each inbound Port. The NML spec actually allows you also to have multiple inbound ports contained in a single hasInboundPort Relation element (and similarly for outbound ports). Question to the group: Would this break current parsers? Jeroen.
I can handle it in the code I just wrote for the SURFnet/ESnet aggregator. On a related question, is anything stopping us from populating an isAlias on the bidirectional port? It seems to be legal in the XSD, and would save some pretty ugly code. John On 2013-09-25, at 8:42 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi all,
Due to the way that the original AutoGOLE topologies were generated everyone is currently using separate hasInboundPort Relation elements for each inbound Port. The NML spec actually allows you also to have multiple inbound ports contained in a single hasInboundPort Relation element (and similarly for outbound ports).
Question to the group: Would this break current parsers?
Jeroen.
Hi, On 25 Sep 2013, at 14:56, John MacAuley <john.macauley@surfnet.nl> wrote:
On a related question, is anything stopping us from populating an isAlias on the bidirectional port? It seems to be legal in the XSD, and would save some pretty ugly code.
It's not legal in the XSD as far as I can see. Jeroen.
Ooops, you are correct. Head is a little cloudy after so much NML. I was thinking of the Bidirectional link. Can I model two interconnected bidirectional ports with a bidirectional link? On 2013-09-25, at 9:11 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 25 Sep 2013, at 14:56, John MacAuley <john.macauley@surfnet.nl> wrote:
On a related question, is anything stopping us from populating an isAlias on the bidirectional port? It seems to be legal in the XSD, and would save some pretty ugly code.
It's not legal in the XSD as far as I can see.
Jeroen.
Hi, On 25 Sep 2013, at 15:14, John MacAuley <john.macauley@surfnet.nl> wrote:
Ooops, you are correct. Head is a little cloudy after so much NML. I was thinking of the Bidirectional link. Can I model two interconnected bidirectional ports with a bidirectional link?
I'm not entirely sure what you mean here. The connection between domains has been defined by the NSI group to use the isAlias construct. Anything else may not work properly. If you would want to disregard that (and probably break some pathfinders), you would have to include unidirectional Link elements, and then create a BidirectionalLink element that contains those. Jeroen.
Ah yes, so I could use the isAlias in the unidirectional ports to determine port connectivity, then create the NML link objects for the unidirectional ports, and group them into Bidirectional links. Now how are bidirectional links related to the bidirectional ports? I can't seem to see a relationship for this. Am I using a label? On 2013-09-25, at 9:39 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 25 Sep 2013, at 15:14, John MacAuley <john.macauley@surfnet.nl> wrote:
Ooops, you are correct. Head is a little cloudy after so much NML. I was thinking of the Bidirectional link. Can I model two interconnected bidirectional ports with a bidirectional link?
I'm not entirely sure what you mean here.
The connection between domains has been defined by the NSI group to use the isAlias construct. Anything else may not work properly.
If you would want to disregard that (and probably break some pathfinders), you would have to include unidirectional Link elements, and then create a BidirectionalLink element that contains those.
Jeroen.
Hi, On 25 Sep 2013, at 16:10, John MacAuley <john.macauley@surfnet.nl> wrote:
Ah yes, so I could use the isAlias in the unidirectional ports to determine port connectivity, then create the NML link objects for the unidirectional ports, and group them into Bidirectional links. Now how are bidirectional links related to the bidirectional ports? I can't seem to see a relationship for this. Am I using a label?
They can not be related to prevent people from turning the description into bidirectional topologies instead of unidirectional topologies. Jeroen.
Hmm… that seems to be an unneeded artificial restriction. I should be able to build up my unidirectional topologies into other network constructs based on my needs. Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black. On 2013-09-25, at 10:38 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 25 Sep 2013, at 16:10, John MacAuley <john.macauley@surfnet.nl> wrote:
Ah yes, so I could use the isAlias in the unidirectional ports to determine port connectivity, then create the NML link objects for the unidirectional ports, and group them into Bidirectional links. Now how are bidirectional links related to the bidirectional ports? I can't seem to see a relationship for this. Am I using a label?
They can not be related to prevent people from turning the description into bidirectional topologies instead of unidirectional topologies.
Jeroen.
Hi, On 25 Sep 2013, at 16:49, John MacAuley <john.macauley@surfnet.nl> wrote:
Hmm… that seems to be an unneeded artificial restriction. I should be able to build up my unidirectional topologies into other network constructs based on my needs. Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black.
As soon as we would add this construct everyone would just use NML to construct bidirectional topologies, and leaving out the unidirectional part. Then if the need ever arises to do asymmetrical, unidirectional, or disjoint return paths, then you can't because everyone is using bidirectional constructs. Jeroen.
I think you are assuming a more nefarious intention. At the moment I am only using the NML to bootstrap my NSI topology, and I was trying to figure out how I could utilize more as the core model to my path finder. Here is what I am doing now: 1. Read individual NML definitions (NSA). 2a. Create NSA, Network, and Port (unidirectional and bidirectional) objects. At this point I am done with NML. 2b. Determine bidirectional port connectivity via the unidirectional component objects. 3. Topology consolidation - Create unidirectional and bidirectional STP from the Port definitions. 4. Create unidirectional and bidirectional SDP using the port connectivity information. Path finding validates source and destination STP, then uses networks (vertices) and SDP (edges) for the graph. I was hoping to keep NML further into the process by using the link objects to consolidate the individual topologies for path finding, removing the need for me to create SDP. But if this is bad then I will continue to model the topology using NSI objects. John On 2013-09-25, at 4:11 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
On 25 Sep 2013, at 16:49, John MacAuley <john.macauley@surfnet.nl> wrote:
Hmm… that seems to be an unneeded artificial restriction. I should be able to build up my unidirectional topologies into other network constructs based on my needs. Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black.
As soon as we would add this construct everyone would just use NML to construct bidirectional topologies, and leaving out the unidirectional part. Then if the need ever arises to do asymmetrical, unidirectional, or disjoint return paths, then you can't because everyone is using bidirectional constructs.
Jeroen.
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
Hmm… that seems to be an unneeded artificial restriction. I should be able to build up my unidirectional topologies into other network constructs based on my needs. Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black.
Agreed 100%. While most things are unidirectional at the bottom (there are exceptions like true ethers), some equipment can only be controlled from a bidirectional point of view (say, most switches). They are by all accounts bidirectional as that is what can be controlled.
As soon as we would add this construct everyone would just use NML to construct bidirectional topologies, and leaving out the unidirectional part. Then if the need ever arises to do asymmetrical, unidirectional, or disjoint return paths, then you can't because everyone is using bidirectional constructs.
If everyone could just buy ready-made cars, no-one would assemble their own cars or build weird 7-cylinder combustion engines, and very few people would even know how a car worked. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
SOme other considerations on unidirectional vs bidirectional Connections and Topology: 1- Unidirectional topology is (IMO) just the atomic construct for an interface. And as JvdH says, we should be able to construct more complex or capability specific topo components from these atomic elements. 2. Atomic Bidirectional links are problematic. For path finders, these circuit paths are almost never actually occupying the same physical resources- these are typically paired up elements that have been packaged together for human convenience - not for automated agents. For example: switches employ [only] unidirectional fabrics internally. The fabric has a set of input ports and a separate following set of output ports. The device switches circuits or frames or packets from any input port to a designated output port according to a Look Up Table (LUT). The design engineers simply relate an arbitrary input port on the fabric with an output port on the fabric, and then connect those two unidirectional ports to a duplex connectors on the faceplate and they call it a single interface with transmit and receive sides. Even ethernet does this inside a switch, as do routers. And other technologies - such as optical DWDM platforms - don't even hide this fact...the engineers do everything manually and unidirectionally in the transmit receive optics. So if we really want to be able to avoid lots of technology specific hacks in the topology descriptions and path finders, we should adopt the unidirectional interface as an atomic element, and then make sure we have appropriate and generalized means of composing other topological service constructs from those atomics. 3. Bidirectional Connections with guarantees capacity/performance will pose scaling problems in the point to multipoint model. In a mp connection model, the output capacity at any destination endpoint must be the sum of all input capacities of the other endpoints. This is fine if you have a single source (i.e. unidirectional) p2mp connection. But in bidirectional mp connections you have multiple sources. It becomes a mp2mp connection (!!) (e.g. if 5 endpoints all want to be part of a bidirectional connection, then you have actually created a broadcast domain, a mp2mp tree - not a single source p2mp multicast tree. And if each of those 5 endpoints want to transmit at 1 Gbps, then it is possible that all endpoints will get 5 Gbps of traffic delivered to them.) If you do not maintain this summation rule, then you cannot guaranty the performance of the bidirectional Connection under all input conditions - and so it becomes a best effort class of service. (Its starting to sound more and more like conventional ethernet, eh?) If you can only guarranty best effort for the mp2mp broadcast domain, then there is no real value to requesting a capacity specification in the first place. Further, if you add an endpoint to a bidir mp2mp connection, you then need to modify all of the existing endpoints and their output segments if you wish to maintain performance guarantees, which becomes totally impractical as the number of endpoints increases or gets large (N^2 problem) 4. Bidirectional Connections would be better served if we treated them as two unidirectional connections bound together by some specific service constraints constraints that path finders can chew on. The notion that such circuits transit the "same ports" in both directions is flawed and inaccurate in almost all cases. For instance, what specifically is our definition of a "bidirectional" NSI Connection? It does not really occupy the same fibers or ports end to end, and it is often separated by a meter or [much] more distance as it transits different transport kit in the pops. So what are the specific constraints we feed the path finders that differentiate a "valid" bidirectional Connection layout from an "invalid" Connection path layout? And if we can define a set of standard constraints that govern the relation between forward and backward paths, do we have those attributes defined in the topology such that path finders can see them and use them? I think bidirectional "Connections" (dba mp2mp "Broadcast Domains") are useful - even without capacity guarantees. These are very practical and useful service constructs (IMO) and it would be good (and easy!) for NSI to support the reservation and provisioning of these. We can extend the NSI-CS DestSTP semantics to include multiple end points. These would build a single source tree for unidirectional Connections, with or without capacity guarantees. And the same Reservation() syntax and semantics can be used to build bidirectional mp2mp Connections - again with capacity (slow and likely to exhaust resources) or without capacity (the b.e. broadcast domain). The protocol can be extended easily (IMO) to support both modes and maintain backward compatbility to current v2 implementation. So, the question comes down to this: Do we really need to differentiate Unidirectional and Bidirectional connection constructs? Can we simplify to just unidirectional, then build two independent connections going each way? (Its what happens internally anyway...) What do we get from a "bidirectional Connection" that you do not get from two "unidirected Connections"? Its not sufficient to say we want bidir connections because thats what Ethernet does...a) Ethernet does not do this (see above), and b) this makes NSI technology specific rather than "service" oriented. So what is the service requirement that dictates Bidirectional connections be differentiated from Unidirectional connections? (And how do we define that for PFs?) Would it not simplify NSI protocol and syntax if we could have only unidirectional connections and we compose more sophisticated services on top of those atomics ? For instance: "Given circuit A1:=A1>Z1, I would like a circuit A2:= Z2>A2 that is less than "R" radius from A1, AND the circuit A2 has an average latency equal to +/-5% average latency of A1. Or just the opposite: I want a circuit A2:= A2>Z2 that is greater than "R" radius from this other circuit A1:=A1>Z1. (The former example would construct a reverse path circuit A2 that is "close" to A1, the latter would construct a diverse circuit A2 that is "far away" from A1.) My point is that these types of constraint based specifications allow a much richer set of functionality for the user, or for a service provider who wants to compose higher level service constructs from the NSI base protocols. These can scale globally so much easier because they do not rely on specific hardware features, traditional human factors, or antiquated service concepts. ...just some thoughts for discussion next week...:-) J On 9/27/13 6:21 AM, Henrik Thostrup Jensen wrote:
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
Hmm... that seems to be an unneeded artificial restriction. I should be able to build up my unidirectional topologies into other network constructs based on my needs. Saying you can only have unidirectional topology is like saying you can paint as much art as you want but only using black.
Agreed 100%.
While most things are unidirectional at the bottom (there are exceptions like true ethers), some equipment can only be controlled from a bidirectional point of view (say, most switches). They are by all accounts bidirectional as that is what can be controlled.
As soon as we would add this construct everyone would just use NML to construct bidirectional topologies, and leaving out the unidirectional part. Then if the need ever arises to do asymmetrical, unidirectional, or disjoint return paths, then you can't because everyone is using bidirectional constructs.
If everyone could just buy ready-made cars, no-one would assemble their own cars or build weird 7-cylinder combustion engines, and very few people would even know how a car worked.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
Question to the group: Would this break current parsers?
For OpenNSA, only the last isAlias would be used. So a little. But I see the case with port mirror, /multiple sources/sinks and whatnot. Followup question: Is anyone using this? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 25 Sep 2013, at 16:45, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
Question to the group: Would this break current parsers?
For OpenNSA, only the last isAlias would be used. So a little. But I see the case with port mirror, /multiple sources/sinks and whatnot.
Followup question: Is anyone using this?
That's not really what I mean, consider the example of the SwitchingService in the original NML spec, adapted to the NSI context: <nml:Topology id="urn:ogf:network:example.net:2013:topology"> <nml:name>Topology_A</nml:name> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:in" /> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:out"/> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasService"> <nml:SwitchingService id="urn:ogf:network:example.net:2013:nodeA:switchingService"> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:in" /> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_X:out"/> <nml:Port id="urn:ogf:network:example.net:2013:nodeA:port_Y:out"/> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#providesLink"> <nml:Link id="urn:ogf:network:example.net:2013:LinkA:XY"/> </nml:Relation> </nml:SwitchingService> </nml:Relation> </nml:Topology>
On Wed, 25 Sep 2013, Jeroen van der Ham wrote:
That's not really what I mean, consider the example of the SwitchingService in the original NML spec, adapted to the NSI context: [snip]
Ah. That should work just fine in OpenNSA AFAICT. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (4)
-
Henrik Thostrup Jensen -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley