November 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 11 Jan '14

11 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

NML requirements for NSI
by Freek Dijkstra 05 Dec '13

05 Dec '13

Dear members of the NML and NSI group, The NSI group has expressed desire for NML features behind the current state, and also is discussing which subset of NML is applicable for NSI. Immediately after after publication of the base draft, some members of the NML group (iincluding myself) seem to have suffered from a little standardisation-fatigue, but I see renewed interest at the moment. To get this effort going, I propose the following: 1. Assess what needs to be done on the mailing list 2. Schedule a conference call to decide which activities have priority and who is interested 3. Decide the best structure to get this going, which groups and which people are responsible (I know that Martin Swany and myself have not been very active lately, so I'm open for suggestions). For the conference call date, please fill in http://doodle.com/gsunb8iiycnimh4r (please check the time-zone in the top right corner, I picked 7:00 and 15:00 UCT, so it is equally horrible in Tokyo, London, Amsterdam and San Francisco time zones) Thanks! Freek -- SURFsara has a new telephone number: + 31 20 800 1300. Freek Dijkstra | Group Leader | Network Innovation & Support | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 20 800 1320 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Thu | Fri |

1 1

NSI topology representation using NML
by John MacAuley 04 Dec '13

04 Dec '13

Peoples, I have taken another look over Jeroen's document "Network Service Interface Topology Representation" given the discussion we had today on the call. I must say that we are totally out of synch with the definition of an STP Identifier in Jeroen's document and what we have in the NSI CS (no specific fault on Jeroen). Specifically, if we look at section 2.2 and 2.3 the STP identifier is defined as follows: STP ID = urn:ogf:network:example.net:2013:A2?vlan=1781 urn:ogf:network: - describes that it is a network identifier. example.net:2013 - DNS name and a (at least) year to make a globally unique prefix creating the network identifier. A2?vlan=1781 - The local component identifying the STP in the context of the network identifier. The root STP ID "urn:ogf:network:example.net:2013:A2" would be an under specified STP referring to the bundle of STP enumerated by vlan. I believe, although not specifically stated, that "urn:ogf:network:example.net:2013:A2?vlan=1780-1790" would also allow me to under specify a range of vlan. This definition for an STP Identifier is in line with the Baton Rouge discussions. This is also how I build an internal STP identifier within my path finder implementation so I can refer to an STP using a single string. So there is a gap in definition between what we have defined as an STP identifier, and what is defined in the nsi-ext specification. We have taken multiple fields from NML objects and composed a complex STP Identifier: NSI CS STP Identifier = { networkId = NML Topology Identifier; localId = NML BidirectionalPort Identifier choice { label = NML Unidirectional Port Label; labelGroup = NML Unidirectional PortGroup LabelGroup; } } To compare the content of the two, here is an example of an STP from the Netherlight topology: <sourceStp> <networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId> <localId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1</localId> <label type="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1781</label> </sourceStp> versus something like this: urn:ogf:network:netherlight.net:2013:a-gole:testbed:port:uva:1?vlan=1781 where "urn:ogf:network:netherlight.net:2013:a-gole:testbed:" is the network portion, and "port:uva:1?vlan=1781" is the local portion. I must admit I am questioning the value of our complex STP definition. I understand the value of the being able to route on networkId, and the issue with URN opaqueness, but if we are constructing the URN following a specific set of rules, could we also not parse it similarly? John

4 7

Adaptation
by John MacAuley 28 Nov '13

28 Nov '13

All, I had an action item to determine the NML mappings for the Service Domain and Adaptation objects. For the Service Domain object I would recommend proceeding as we were with the Transfer Function and use the NML SwitchingService to model the capability. It allows Ports and PortGroups to be specified which is what we need. We will need to work out if the service type gets specified in the SwitchingService or the individual Port/PortGroups. <nml:SwitchingService id="urn:ogf:network:example.net:2012:nodeA:switchingService"> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasInboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:in" /> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:in" /> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasOutboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:out"/> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:out"/> </nml:Relation> </nml:SwitchingService> Unfortunately, we have a slight issue with the Adaptation. The NML AdaptationService object supports references to Ports and PortGroups, however, it does not support references to SwitchingServices. This is due to the fact that Adaptation is built around the concept of adapting between ports. As you can see below, we have a port with an associated AdaptationService. The AdaptationService references the target port of the adaptation. <nml:Port id="urn:ogf:network:example.net:2012:port_X:in"> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasService"> <nml:AdaptationService id="urn:ogf:network:example.net:2012:port_X:in:adaptationService"/> </nml:Relation> </nml:Port> <nml:AdaptationService id="urn:ogf:network:example.net:2012:port_X:in:adaptationService"> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#providesPort"> <nml:Port id="urn:ogf:network:example.net:2012:port_X.1501:in"/> </nml:Relation> </nml:AdaptationService> <nml:Port id="urn:ogf:network:example.net:2012:port_X.1501:in"> <nml:Label labeltype="http://schemas.ogf.org/nml/2013/03/ethernet#vlan">1501</nml:Label> </nml:Port> For this to work we will need to create a port in each Service Domain participating in the adaptation which can then be linked through the AdaptationService. Since this will not form an SDP due to the differing service types, a path finder will not accidentally chose the STP in a path, unless it has specifically understood the adaptation and created the transitional SDP. I am happy with this solution. Comments? Johnnsi

1 0

minutes from today's NSI conf call
by Guy Roberts 28 Nov '13

28 Nov '13

... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6529 _____________________________________________________________________ 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<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://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. _____________________________________________________________________

1 0

Resending the Notification, Error, Response, and Failed proposal.
by John MacAuley 27 Nov '13

27 Nov '13

Current changes discussed on slide 14 - 20. John

1 0

Topology slides for discussion
by John MacAuley 27 Nov '13

27 Nov '13

Work in progress. John

1 0

Schema changes
by John MacAuley 27 Nov '13

27 Nov '13

Summary of schema changes.

1 0

minutes of NSI discussion at SC13...
by Guy Roberts 27 Nov '13

27 Nov '13

Hello All, The minutes of the NSI discussion at SC13 can be found here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6570 Guy _____________________________________________________________________ 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<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://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. _____________________________________________________________________

1 0