Hi Inder - see reponses in line. (and thanks for your patience with me:-)

Jerry

On 3/13/11 1:43 AM, Inder Monga wrote:

The <network>:<endpoint> tuple is analogous to the global IP address with its <network>/<host> definition. So we can call the NSI tuple a symbolic global addressing scheme. I think this is an important feature for NSI. AS it turns out, this tuple is sufficient to route a request across the global NSI topology, but is independent of the physical topology. It is the leaf NSA's job to know how to translate an NSI EPR to the local NRM. Indeed, since the leaf NSA is just a PA frontend to the NRM, we can say that translating from NSI EPR to local NRM is the job of the NRM-PA. THis makes the translation to local topology a function of the NRM and out of scope for NSI.

Please do not use EPR as a sub for STPs - it is already a standardized term..could cause confusion. http://en.wikipedia.org/wiki/WS-Addressing :)

Fair enough...there are just so many external documents I can't seem to keep our terminology sorted out from terms allowed or disallowed by other groups.

We could allow a topological specification as well. But this has the drawback that every application globally referencing that end point will need to know the topological location. If that physical location changes for any reason, all applications need to be changed. Just as IP address *can* be used for URLs, DNS names are used in order to abstract the desired endpoint from the physical location it occupies at the moment. In addition, advertising endpoints by their topological specification allows internal topology to leak out globally.

I understand what you are saying - but to me what you are suggesting falls within best practices and you cannot mandate someone not to encode topological spec into their local string. for example

3 te-1-4-ur03.santaclara.ca.sfba.comcast.net (68.86.248.17) 17.047 ms 18.316 ms 33.941 ms

4 te-1-10-0-5-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.58) 62.206 ms 72.866 ms 52.751 ms

5 pos-1-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153) 52.351 ms 72.093 ms 32.664 ms

6 pos-0-0-0-0-pe01.529bryant.ca.ibone.comcast.net

I just want to be sure you are not referring to encoding like the above which can be done?

I agree. The local domain has the prerogative to name an endpoint as they see fit. This is as you say a best practice issue.

Likewise, since the local name is a local preference, then NSI as a standard should not expect or require the name to encode anything particular. i.e. From an NSI standpoint, the local name is just a string. NSI does not care what is encoded or not.

In the example above, what you see are *names*.   There is no expectation or requirement that all router interfaces will have such interface names or even that router interfaces will have names at all. Indeed, many don't even have IP addresses. Further, while these are "end points" in the formal sense, the ultimate user 'end points" rarely get named in this fashion (encoding interface information.) These names are fine as far as I am concerned because the automated agents are not relying on this infromation for anything.

Given that the NSI tuple only encodes a globaly unique network name that is only used to link to the appropriate NSA, there should be an explicit NSI function/service that a) takes the network name and returns the NSA information, and b) takes the local name and returns other associated [topological] information.   And vice versa.   This is important in order to provide location independence, but should also be a fairly simple directory or lookup service.   (This lookup service is how I expect local NRMs to convert a NSI reference to a local significance.)

I know Inder (and probably Tomohiro) have questions about how you select VLANs at a remote endpoint,

The question is how to specify aggregate end-points using this method of uninterpretable local strings. The number of these end-points when you consider virtual ones can be huge. So there is a benefit in having a specification that can aggregate those. The other question is how to show interconnectivity between two STPs - one in each domain.

Second point first: I think the interconnectivity of two STPs is indicated in the topology DB.   I.e
//ESnet/Peer101==//NORDUnet/USxconnect01    As I see it, both networks will have to indicate the equivalent STP in the other network.    This issue is a topology issue and a pathfinding issue, so it is an interesting and whorth while discussion, but I don't think it is something we need to resolve prior to V1.0.

First point: there is no primitive or notion formally in NSI that acts on an "aggregate end point"...What I think you mean is you want to specify that a connection can be terminated on any one VLAN in a specified set of VLANs. Right?

So why do you want this (generaly)? Are you assuming that a tagged frame will be carried natively end to end across all intervening ethernet switches?     The connection request primitive makes no such commitment.   The "connection" service provided is neccessarilly a function of the payload definition at the ingress and egress.   But this does not imply that the network must somehow provision VLANs natively in order to meet the service request.   The network could easily just build a tunnel end to end with any technology available and put the frames in that tunnel. ...   If the service carries the entire tagged frame as the payload, then any sane network provider would still tunnel it through another virtual connection to insulate itself from the effects of userville. The upshot is that the label set issues become just access framing issue - Its a local decision.   Thus the RA can choose a VLAN as easily as the PA and without all the end-to-end hoohah. If the service just carries the payload section of the tagged frame, it gets even easier.

If we change the primitive semantics of an "end point" to now be a "set of end points" we make things substantially more complex at this late stage for v1.0. We can perhaps find a means of specifying a label set (ala GMPLS), but for the standard, we need to think though how this is to function generally. Are we standardizing a special treatment for Ethernet VLANs? Or is this a more general treatment that will work for any subgroupings?? What are sub-groupings anyway?   And are they a CS protocol issue or a topology/pathfinding issue?       So - is this something the primitive needs to deal with? or something the pathfinder should deal with? If either case, is this something that needs to be specified as something other than the tuple?   (i.e. does the grouping need to be incorporated in the syntax of the reference, or is it a more substantial issue that should be reflected in the topology?

There are probably several ways to accomplish this, but all have implications that are non-trivial...which makes me want to say push the discussion to post-V1.0 since user specified VLAN STPs will work, and we have little time to work through yet another change to the primitives, and get it all written up.

I think we leave the semantics of the local name to the pathfinder as it will be the function that needs to map the name to local topological constructs.   -->If a localname STP is mapped to a topological construct that represents a set of endpoints (e.g. an tagged port), then the pathfinder can recognize this and do the Right Thing. And the tuple reference is still sufficient to do this. The pathfinder is not our concern at this time.

Further, I think these label set problems avoids the real issue: Flat VLANs suck horribly as an interdomain switching technology. So do raw wavelengths. These are not globally scalable (which is why QinQ was introduced and why PBB is now in vogue, and why MPLS works so well.)   IMO, The primitives should [for now] require the RA specify the specific access tag STP at each end, and let the network PF decide how to drill tunnels and flip labels to deliver the payload. We should keep in mind also what the actual payload is: Is it the entire as-is ethernet frame? or is it the payload of the tagged frames? If it is the former, does that imply that we cannot tunnel it? If the latter, then changing VLANs inside the transport fraimg, is perfectly fine.

We should consistently define the connection primitives to work in accordance with the NSI architectural concept of a "Connection" - not try to create a standardized workaround for limitations in certain possible transport technologies.   Let the implementations (NRMs) deal with technology specific issues (e.g. mappng VLANs across the switches on the ground.), keep the standard to the high level model of a "Connection from A to B"

We break our architectural abstractions whenever we address one particular technology specifically. I also believe we undermine the overall work if we try to stuff lots of Rube-Goldberg-esque mechanisms into the standard in order to make amends for fundamental limitations of a technology - particularly when we know these issues are likely to be resolved in the near future. (flat VLAN space is a perfect example).

but I view this as a pathfinding issue within each domain - not a global issue. While this is related to topology and visibility, if we stay within the confines/context of the NSI-CS protcol I do not think we need to address this in the standard. At least not immediately.

So whether we use a "urn:blah <domain>:<endpoint>" or just a raw tuple "//<domainname>/<endpointname>" is not a big issue with me. As long as we support the tuple and agree on *one* convention that all NSAs must recognize.

I prefer the urn representation (even though we could define our own string delimiter and format) and I imagine that OGF urn will be registered with IANA (http://tools.ietf.org/html/draft-dijkstra-urn-ogf-01 and http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml)

Inder

I reiterate my support for OGF GID- the <networkname>:<localname> tuple for STP identification. Preferably without a URN prefix.

If you to require that an endpoint identifier must be specified as a URN prefix, you are implying that the <networkname>:<localname> tuple is not sufficient to differentiate STPs for NSI purposes. What NSI requirement is not met by the simple tuple?

These are good discussions to have - all of them. But I think we need to focus on the functionality we have and get that written and out as a spec.

Best regards!
Jerry