February 2014 - Nsi-wg - lists.ogf.org

Minutes: GLIF NSI Implementation Group (Feb 5, 2014)
by John MacAuley 16 Feb '14

16 Feb '14

Here are the meeting minutes from our last task force meeting. I will be issuing an updated version of the NSA Discovery document today. Attendees (please let me know if I missed anyone): John MacAuley, ESnet Henrik Thostrup Jensen, NORDUnet Hans Trompert, SURFnet Chin Guok, ESnet Inder Monga, ESnet Freek Dijkstra, SURFsara Miroslav Živković, UvA Tomohiro Kudoh, AIST Kostas Stamos, GRnet Regrets: Guy Roberts, DANTE 1. Discussed meeting logistics for face-to-face meetings at GLIF: 1 hour - Update meeting for general GLIF community (introduction to NSI 2.0). 2 x 1.5 hours GLIF implementation task force on Thursday - John (NSA Discovery), John & Chin (Topology distribution). - Hans (User security), Chin (verification of topology information). Action: Inder to find rooms for additional OGF NSI Working Group meetings. 2. Discussed the NSA Discovery document schema. John described how he separated the Discovery Protocol from the NSA Discovery metadata so that the proposed discovery protocol could generically support any type of document, and therefore, making it a viable solution for topology document exchange as well. Action: John to incorporate the following changes and issue new version of document for formal review. - Include example of interface definition without a describedBy element. - Modify aggregator feature values to by type only. - Change peers element to peersWith. - Define the current protocol version strings supported and how they are used. - Add a section on who needs to implement discovery and who does not. Action: John to update schema and send ASAP to Henrik. 3. Discussed list items we need to work on in the task force and decided a prioritized list was needed. Action: John and Inder need to prioritize task force work items. Build list for discussion next meeting.

1 0

minutes from today's NSI standards conf call
by Guy Roberts 12 Feb '14

12 Feb '14

... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6574 Guy

1 0

Re: [Nsi-wg] [Nml-wg] Wednesday's NSI standards conf call
by Freek Dijkstra 12 Feb '14

12 Feb '14

Hi Jerry, I hope it's OK if I quote you on-list. Perhaps others share the same questions. (your full mail is quoted verbatim at the end). I'll try to answer some of them here. > STPs - An STP is service termination point. A concept. The STP > "Identifier" is the name for the STP. It is a 2-tuple > <networkid>:<localid>. These carry no routing information other than > the name of the network in which the STP resides. I'm not making any assumption about the syntax of the name/identifier in this presentation. So also not that the name starts with a networkid. (In general, an identifier MAY be hierarchical, and may start with the ID of the assigning organisation. This is how most identifiers, including ISBNs and URNs, work. NSI indeed makes the assumption that the ID of the assigning organisation is the name of the network. NML actually does not make this assumption.) > An STP is the object, An STP Identifier names the object. Indeed! You are right that I took a bit of a shortcut on slide 3, when it comes to "NSA" and "Intermediate STP/SDP". I perhaps should not have mentioned these two, but only mentioned "Endpoint STP" and "Topology". [...] > We do not need "intermediate" STPs ... this is meaningless in NSI [...] While we now have a clear vision what we need for "Endpoint STP" and "Topology" (identifier and address respectively), at least I am still uncertain about "NSA" and "Intermediate STP/SDP". Thanks for explaining your vision. You are going in the details about routing and path finding. We have not discussed that yet, so we don't have a solution there (yet). > b) Slide 5; Your assertion that addressing are used for routing, and the > notion that addresses are hierarchical. > I think this goes to the definition of an "address" as a string that can > be parsed to locate an endpoint in the infrastructure. It is interesting to see that in the late seventies, people apparently mixed the concepts of address and route. Not surprising, since a telephone number is both a number as well as a description of the route how to reach it. > b) NML..."NSI has a problem". > I don't understand this comment. This is self-critcism that at least I never clearly communicated the difference to the NSI group, and that we're now having this discussion. Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu | -------- Original Message -------- Subject: Re: [Nml-wg] [Nsi-wg] Wednesday's NSI standards conf call Date: Wed, 12 Feb 2014 00:25:35 -0500 From: Jerry Sobieski <jerry(a)nordu.net> Organisation: NORDUnet To: Freek Dijkstra <Freek.Dijkstra(a)surfsara.nl> Hi Freek- Interesting slides. Slide 2 says it all... But I have some issues that I think you mis-understand about NSI. So let me make some points: a) Slide 3: What do we need for NSI? *STPs* - An STP is service termination point. A concept. The STP "_/Identifier/_" is the name for the STP. It is a 2-tuple <networkid>:<localid>. These carry no routing information other than the name of the network in which the STP resides. So subtle difference: An STP is the object, An STP Identifier names the object. An STP n-tuple is the topological address of the object. *NSI Network* - Is a service domain bounded by STPs. An NSI Network Id names the domain. THe boundaries of that domain are defined by the STPs (since all STPs are at the edge of a NSI Netwokr service domain.) The Network identifier only needs to be unique within the use context of NSI Networks (i.e. we don't care if the same string is used in a different application for a different concept.) *SDP*s - These are data plane adjacencies, i.e. they describe a *relationships* between two STPs. SDPs are specified as a pair of /STP Identifiers/. They describe the adjacencies among networks. These three objects are necessary and sufficient for NSI path finding to functioning. These three objects represent the Ports, Nodes, and Links found in graph theory. This resource graph model that NSI originally supported (and still does) scales well and can actually be used recursively. THis topology model is specifically designed to address the needs of a connection service - ie a _/Service/_. It is not intended to describe plumbing. We do not need "intermediate" STPs ... this is meaningless in NSI (though I don't think everyone understands this.). STPs should properly only exist at the edge of a network - since by definition they define the edge of a switching domain. IMO, an STP should be unidirectional only(!) We can support STPs in an ERO in the Reserve() command but this should be indistinguishable from submitting each ero segment individually. b) Slide 5; Your assertion that addressing are used for routing, and the notion that addresses are hierarchical. I think this goes to the definition of an "address" as a string that can be parsed to locate an endpoint in the infrastructure. In this interpretation, our STP Identifier 2-tuple is partly address and partly name. The Network ID is the address part and it is public. The localid is a name for the local address n-tuple. If we looked at the local address it would be something like <switch id><blade Id> <port #><VLAN#> etc. So I have always asserted that the STP Identifier is a 2-tuple name. And that when the NRM provisions the path inside a domain, it must translate the name (the localid) to the n-tuple address. THis is in fact what OpenNSA does - it has a topology table that maps the localid to the n-tuple topological address. The n-tuple is then broken up and each component is used to perform path finding or provisioning. b) NML..."NSI has a problem". I don't understand this comment. NSI has always said the _/STP Identifier/_ (i.e. the 2-tuple <network>:<localid> ) was just a name for an end point. The STP identifiers did not contain any topological specification besides the Network Id in which the LocalID was to be found. And the NSI Network ID itself contains no routing or other topo information - it is simply a tag. Pathfinders essentially ignore the LocalID, and only look for the src and dest Network IDs in the topology. The PF only needs to determine the inter-domain path it wishes to use - and this only requires knowledge of the SDPs (i.e. the Network adjacencies). The PF needs no internal domain topological information, nor does it need any physical topological addressing to do this. So tell me do say NSI has a problem? It has always been the responsibility of the NRM (internal to a domain) to resolve the local Id into the topological addressing info that corresponds to the end point in the local physical infrastructure and then do the necessary internal path selection and configuration. This internal work is a local internal responsibility and NSI need not deal with it. (Indeed, NSI expects a domain to perform this internal pathfinding and configuration - it is that domain's responsibility... This internal topological address is the "n-tuple" representation of an STP containing: <switch element id> + <blade #> + <port #> + <vlan tag> + etc. Each network can use whatever addressing n-tuple they deem necessary depending on their hardware and internal provisioning model. Since this is an internal issue for the NRM, NSI does not care. NSI originally only recognized the 2-tuple. And the 2-tuple was the only aspect of STPs that needed to be carried in the NSI Reservation Request. And it was the NRM's job to translate the 2-tuple to an internal n-tuple address. THe 2-tuple hides all internal topological address structure and is easier to use, so it will be the most commonly used form in NSI. Some folks suggested that NSI should also recognize the "N-tuple" physical address. I did not think this was necessary, practical, or smart, but I was convinced by Tomohiro that if a requester somehow magically knew the physical n-tuple address of the desired end point, then why not allow the protocol to carry it along? It does not change the service model. So a Reservation could have either a) a 2-tuple STP Identifier, or b) and n-tuple STP physical topological address. How to tell the difference? Enough for now... Suffice it to say I think we should review the STP naming and reference aspects. I think there are ways we can retain key important features, and introduce the proper (simplifying) concepts. I do not think we should parse URNs. Indeed, I do not think we need or should use URNs in NSI. I think we need to rethink our specification syntx for end points . Late here...gotta sleep. Thanks for reading this. Jerry On 2/10/14 6:57 PM, Freek Dijkstra wrote: > On 10-02-2014 13:04, Guy Roberts wrote: > >> - Freek Dijkstra to present on the distinction between >> identifiers and addresses in NML. (20 minutes) > Attached you will find the slides I like to present. > > With kind regards, > Freek Dijkstra > > > _______________________________________________ > nml-wg mailing list > nml-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/nml-wg

1 0

Wednesday's NSI standards conf call
by Guy Roberts 10 Feb '14

10 Feb '14

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: - Huhnkuk Lim to present on NSI protection management - see slides here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6580 (30 minutes) - Freek Dijkstra to present on the distinction between identifiers and addresses in NML. (20 minutes) - Inder Monga to provide an update on the preparations for the next NSI-WG face-to-face meeting (5 minutes)

2 1

Slides for an NSI conference call talk
by 임헌국 09 Feb '14

09 Feb '14

Hi all, I'm Huhnkuk at KISTI/Caltech. I'm supposed to give a talk on the NSI canference call of Feb. 12. Attached is a file to be presented and an abstract is below. ===================================================================================================== In this talk, we attempt to outline design issues and challenges for cooperative protection management for guaranteed user-driven VC(Connection) services on NSI Extension. In addition to that, we investigate management information flow mechanisms required for per-domain and end-to-end protection service in a user-driven manner, in order to serve as a basis for the key challenge of how to monitor a global network and primary/backup VC data plane state transition and coordinate transport paths in component domains. ===================================================================================================== Hope that helps you to understand a seamless protection chain service in a user-driven manner on NSI extension. Thanks ! Cheers Huhnkuk

1 0

Identifiers versus Addresses
by Freek Dijkstra 09 Feb '14

09 Feb '14

Hi Guy, et al., Would it still be possible to give a short presentation at the upcoming NSI conference call (Wed 12 Feb)? At OGF40 some concerns regarding the URN identifier format have come up, and after some discussions with Diederik Vandevenne (SURFsara), Ralph Koning and Miroslav Živković (both University of Amsterdam), I've came to the conclusion that at least some of the issues stem from the different uses of URNs. Basically, as identifiers in NML and as addresses in NSI. We don't have a clear solution, but I thought it may be useful to explain the distinction between identifiers and addresses to those interested, and how this may applies to NSI. Is it still acceptable if I'll send some slides Monday later at the day? Thanks! Freek -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |

1 0

This week's NSI Implementation call
by John MacAuley 06 Feb '14

06 Feb '14

Peoples, I have been working diligently at preparing the revised discovery proposal. I will send out what I have available later today so that I can socialize my thoughts on the revised proposal on this Wednesday's call. Any feedback would be appreciated. Given the document will not be ready early enough for what we have defined as an "official" review, I will take any feedback available and incorporate it into what we will review during the next meeting. The following is dial-in information for Wednesday's NSI Implementation working group call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" We look forward to your participation on Wednesday, John and Inder

1 2

Revised minutes: GLIF NSI Implementation Group (Jan 22, 2014)
by John MacAuley 03 Feb '14

03 Feb '14

I missed a few on the attendees list the first time around. Attendees (please let me know if I missed anyone): John MacAuley, ESnet Henrik Thostrup Jensen, NORDUnet Radek Krzywania, Poznan Supercomputing and Networking Center Joe Mambretti, Northwestern Hans Trompert, SURFnet Alex Moura, RMP Freek Dijkstra, SURFsara Jerry Sobieski, NORDUnet Chin Guok, ESnet Inder Monga, ESnet Guy Roberts, DANTE Kostas Stamos, GRnet Tangui Coulouarn, GÉANT 1. John presented the attached slide package discussing the mandate of the group, how we would like to operate, and how we would like to interact with existing NSI related groups. Key point: Items will be discussed within the group only when a contribution has been made available 4 - 5 days before the meeting. We need focus to avoid wandering discussions. 2. Discussed a list of topics we need to address in the short term. a) Discovery Service - expand the existing discovery service proposal to cover new requirements from existing NSI implementations and changes in NS 2.0. Action: John and Henrik to work together to revise the existing discovery service contribution for review. Expecting prototype implementation to validate contribution. b) Ethernet Service - we are using VLAN labels in the A-GOLE topology that are yet to be specified in a formal schema with a defined namespace. We have agreed to capture the existing Ethernet parameters and formalize the definition. Action: John to capture existing parameters and define in a formal schema definition for review. c) Error handling - Expand existing NSI error set to include new errors values introduced through NSI 2.0 implementations. Define required error feedback for taking corrective action on the errors (especially for path finding). Action: John to write contribution as an initial proposal for discussion. d) AAI - Hans has a proposal for end user authentication and authorization that will be running in the European production network, and we hope on the A-GOLE. He will bring in a formal contribution for review. Action: Hans to write a contribution for review. e) Requirement for path finding - Formalization of topology requirements for pathfinding (both chain and tree). f) Topology discovery - We have two primary use cases for topology exchange; support of dissemination of information for full tree based path finding, and summary path vectors for chain based routing. Action: Chin to update his OGF contribution with input from Henrik, and review proposal. Expecting prototype implementation to validate contribution. 3. Jerry related concerns that standardization activities need to occur in the OGF NSI-WG and not the GLIF NSI Implementation group. Discussion occurred around providing implementation feedback on the standards into the GLIF NSI Implementation group so solutions can be vetted, and formal contributions defined for submission back into the OGF NSI WG. Action: Inder, John, and Jerry to discuss concerns and propose resolution. Please let me know if I have missed anything. Next Wednesday is the OGF NSI WG meeting, and back to the GLIF NSI Implementation group meeting in two weeks. Thank you, John

1 0