September 2013 - Nsi-wg - lists.ogf.org

Issue 113 in ogf-nsi-project: Change provisionState machine to be mandatory.
by ogf-nsi-project＠googlecode.com 14 Jan '14

14 Jan '14

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 113 by jmacauley: Change provisionState machine to be mandatory. http://code.google.com/p/ogf-nsi-project/issues/detail?id=113 Decision was made to instantiate the provisionState when the first reserve request is received for a reservation. This makes it consistent with the other state machines. However, it should be noted that a provision request cannot be received until the first version of the reservation has been successful committed. If a provision request is received before the first version of a reserve has been created, then it must be rejected with an error. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

3 4

Issue 109 in ogf-nsi-project: Align STP Label definition closer to similar types within NML.
by ogf-nsi-project＠googlecode.com 10 Jan '14

10 Jan '14

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 109 by jmacauley: Align STP Label definition closer to similar types within NML. http://code.google.com/p/ogf-nsi-project/issues/detail?id=109 The NSI STP definition was originally intended to be a generic attribute type/value pair mechanism but morphed into a Label type definition. At the moment it is too complex for the role it is performing. In addition it is not in alignment with the NML definition for LabelType. These definitions need to be normalized. Also, NML has separate definitions for LabelType (a single label) and LabelGroupType (a range of labels). Both are applicable to the STP definition and should be incorporated. For example, using an STP to specify a SONET service would require the specification of a set of timeslots associated with the service on the STP. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 3

Issue 104 in ogf-nsi-project: What version number set in case of failure of initial request attempt
by ogf-nsi-project＠googlecode.com 23 Oct '13

23 Oct '13

Status: Accepted Owner: tkudoh...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 104 by guy.robe...(a)gmail.com: What version number set in case of failure of initial request attempt http://code.google.com/p/ogf-nsi-project/issues/detail?id=104 Description of Issue: When an initial reservation request attempt fails, or held initial reservation is aborted, RSM is in the RESERVE_START. What version number should be set in this case? What should be returned to a query in this case? Discussion of Issue: GR: it is proposed that there will be no version number returned as the criteria element is not included in the reply. Resolution of Issue: -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

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