[Nsi-wg] NSI endpoint references

[Jerry Sobieski]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110314/771ac169/attachment-0001.html