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@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@nordu.net> Organisation: NORDUnet To: Freek Dijkstra <Freek.Dijkstra@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@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg