- Nsi-wg - lists.ogf.org

Topology update
by Jeroen van der Ham 01 Oct '13

01 Oct '13

Hi all, We found a small problem in the topology generation in OpenNSA. This bug has been fixed, but requires an update of the OpenNSA servers. UvALight and AMPATH have been updated, hopefully others will follow soon. I believe that once these are updated this will solve a lot of "island" problems in the topologies, and we will have a fairly complete topology. Jeroen.

3 3

Some topology stuff for Glif
by Henrik Thostrup Jensen 30 Sep '13

30 Sep '13

Hi Some notes from implementing NML, and some input for the topology discussion at Glif. There is no bandwdith/capacity attribute in NML. This means we cannot do capacity matching in pathfinding Is this something we need? (insert usual disclaimer about advertised bandwidth being different from avaible) NML does not have anything to denote available service definitions - per network or port. This again, makes pathfinding rather tricky and full of assumptions. While one can match labels with labels used in a service definition, there might be certain semantics which is not supported. Is this something we need to add? The NML model is quite different from the original network+port model of NSI. The role of a topology corresponds roughly to a network, but this is a restriction/policy that we have made (which I am perfectly fine with, but we just need to be explicit about this). This also means the way NML and NSI reference ports are different. In NSI we use a network id (which maps to a topology in NML) and a local id which maps to a fully qualified port name in NML, like this: <sourceSTP> <networkId>urn:ogf:network:aruba.net</networkId> <localId>urn:ogf:network:aruba.net:ps</localId> </sourceSTP> In NML, one can reference ports directly, like this: <nml:PortGroup id="urn:ogf:network:bonaire.net:bonaire.net:arb-in" /> There is something to be said for both models, but not really about having both at the same. The network id in NSI is really redundant. I talked to to John about this in Madrid, and while he agreed he just couldn't get himself to remove (and I agree with this, the whole thing just feels so goddamn clumsy). Right now we essentially have 1½ topology model. There are some ways Then there are some security aspects. How do I control that no one injects services / topologies / servies into the topology? In OpenNSA, I do the following in the configuration: peers=example.org@http://example.org:9080/NSI/topology/example.org.xml This enables me to check/filter for identifiers in the retrieved topology. A basic way could be to match the hostname of the base identifier (like nordu.net:2013) against a certificate (can the the one of the TLS session or via a signed topology). However AFAICT, there is no way to establish exactly what the base identifier is. Furthermore the certificate is not likely to match the base identifier, e.g. nordu.net:2013 vs nsi.nordu.net. The NML year model also falls somewhat apart here, as someone announcing with a certain year would need to have a valid certificate for that year, however certificates where the current time is not within the valid period are by default invalid (and with good reason). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 2

State of topology
by John MacAuley 29 Sep '13

29 Sep '13

I have attached two images. One is of the current gole connectivity as defined in the topology files, and the other is a representation of the available SDP as computed from the topology. We still have some islands that need to be connected. If you are an island could up please get the proper connectivity modelled? Thank you, John.

1 0

Strict enforcement of service specific elements
by John MacAuley 27 Sep '13

27 Sep '13

Peoples, We will need to lock down the behaviour in the NSI 2.0 documentation, so i thought I would start the discussion. The service definition describes the service specific elements that must and may be present in the reserve/modify request. It is my current view that this list needs to be strictly enforced, and any elements found not part of the service definition results in an invalid request. If we do not perform strict checking then we will need to define the behaviour when an element is discovered that is not part of the service definition. Comments? John

2 2

Topology versions
by John MacAuley 27 Sep '13

27 Sep '13

Peoples, I have noticed some of the NSA that support dynamic topology retrieval are updating the "version" attribute of the NSA element every time a retrieval occurs. This has the unwanted side effect of appearing to be a new topology each time it is retrieved. If possible, could you only update the "version" attribute after an NSA restart, or when you have had an actual topology change. This will help to reduce the churn in recomputing topology when polling for updates. Thank you, John

2 2

Service type vs serviceElement tag name
by Henrik Thostrup Jensen 27 Sep '13

27 Sep '13

Hi Right now we have a construction in the reserve request (and confirmations), like hits: <serviceType>http://services.ogf.org/nsi/2013/07/descriptions/EVTS.A-GOLE</serviceType> <p2psrv:evts> <capacity>200</capacity> <directionality>Bidirectional</directionality> <sourceSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:ps</localId> </sourceSTP> <destSTP> <networkId>urn:ogf:network:nordu.net:2013</networkId> <localId>urn:ogf:network:nordu.net:2013:uvalight</localId> </destSTP> <mtu>1500</mtu> <burstsize>5000000</burstsize> <sourceVLAN>1780</sourceVLAN> <destVLAN>1780</destVLAN> </p2psrv:evts> AFAICT the serviceType and element name of the service (<p2psrv:evts>) has the exact same purpose: To tell the NSA which type of service is requested. Having serviceType specific to A-GOLE seems a bit weird. It is still an EVTS service. For getting endpoints in the A-GOLE one should just select the right STPs. AFAICT the serviceType field is completely redundant. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 3

Ports relations
by Jeroen van der Ham 27 Sep '13

27 Sep '13

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.

4 14

Bidirectional path finding
by John MacAuley 27 Sep '13

27 Sep '13

People, I have a behavioural question with respect to the way we have defined the current point2point service. Please correct me if I am wrong and have missed something fundamental... In a bidirectional service request (directionality == Bidirectional) I specify a pair of bidirectional STP I would like connected. Is there an assumption that I can only satisfy this service request by interconnecting bidirectional STP in the topology, or can the aggregating NSA segment this into component unidirectional ports and route using independent unidirectional STP (with any symmetricPath restrictions)? Using bidirectional topology greatly simplifies path finding, however, the symmetricPath parameter only applies to the intra-domain connections done by the uPA. I assume the answer to my question is "it is up to you". John

2 1

nordunet and am path VLAN issue
by John MacAuley 27 Sep '13

27 Sep '13

I also discovered that these two topology files are using the vlan identifier: http://schemas.ogf.org/nml/2013/05/ethernet#vlan instead of: http://schemas.ogf.org/nml/2012/10/ethernet#vlan John

2 5

Fwd: Issues with icair topology
by John MacAuley 25 Sep '13

25 Sep '13

I have too many e-mail addresses… Begin forwarded message: > From: John MacAuley <john(a)macauley.com> > Subject: Issues with icair topology > Date: 25 September, 2013 2:36:41 PM EDT > To: "nsi-wg(a)ogf.org Group" <nsi-wg(a)ogf.org>, "<autogole(a)glif.is> List" <autogole(a)glif.is> > > The isAlias references are messed up in their topology. For example, > > urn:ogf:network:netherlight.net:a-gole:testbed:starlight:1:in > > should be > > urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:starlight:1:in > > and I have no clue where this one should be pointing... > > urn:ogf:network:es-startap:es-startap-in > > Thanks, > John

1 0