[Nsi-wg] usage of STPs

Wed Apr 13 23:05:42 CDT 2011

Hi Jeff-

On 4/13/11 11:34 AM, Jeff W. Boote wrote:
> Why would this need to be part of a protocol? If a federating network 
> is abstracting a child network's topology, then wouldn't it completely 
> be an implementation issue for that federating entity to keep track of 
> the mapping between the topology it advertises as part of itself and 
> the 'real' topology that is really part of the child. What am I missing?
You are right.  Who could tell??   Externally, they appear to be normal 
endpoints of a normal NSA.   So we can't stop this - it is indeed a 
local issue (very astute observation!)     I think the discussion was 
really an exploration of how we would actually create a federation with 
existing protocol (or what tweeks we need to do so...)

But I do not like this remapping approach as a federation technique anyway.

Remapping means that external requesters can only reach the endpoints 
via the federating NSA, and therefore the federating NSA must have the 
federatedendname<->nativetuple mapping ready when a request shows up, 
which means the member networks will have to advertise *all their 
endpoints* to the fedNSA for remapping.    To date, we have no need to 
advertise endpoints themselves.  We currently only need to advertise 
networks in order to properly forward a request.  Expecting to advertise 
endpoints changes the topology distribution scaling significantly.   
This remapping means also that naming also become a task two networks 
must now manage.

Further, this remapping relies on naming to indicate routing... which is 
generally considered a bad idea.

The better way (IMO) to approach a federated environment is to retain 
the native network:endpoint  tuple, and have the federating NSA announce 
both reachability to the constituent networks and conventional 
[federation] edge adjacencies.  This will infer that remote NSAs should 
forward service requests to the fedNSA rather than directly to the 
constituent owner NSAs.

But even this relies on all RAs getting some sort of topology feed that 
describes the federation.   Most NSAs will only be ultimate RAs - just 
asking for a connection.  They will have the destination native endpoint 
tuple, but not know of the federation.

However, if a NSA is a voluntary member of a federation, and it then 
receives a qualifying federal service request, it can easily forward the 
request to the fedNSA to allow the fed the first stab at processing.  
The fedNSA processes the request normally, which may very likely entail 
forwarding the request right back to the constituent NSA.   But now, 
since the constituent NSA sees the request coming from the fedNSA, it 
knows it can go ahead and process the request normally.   From the 
consitutent's point of view, as a federation member, it passes all 
service requests meeting the federating criteria to the fedNSA.   This 
rule allows the fedNSA to insert itself in all federation business.
And its simple and local.

> And I think it is a non-starter to say network id's are specified with 
> no syntax. We need globally unique in this space, and if we are not 
> going to maintain some kind of registry that implies a specific syntax 
> to do that. URNs are already widely accepted. If we want to do 
> something different, we should have very good reasons for that.
The opaque string seems to have consensus (which is good IMO).  What 
constraints we put on that string is really a matter of how we expect it 
to be used.   The primary purpose of the Network name string is to 
identify an NSI Network domain - and generally (but not always) that is 
taken to be synonymous with the NSA associated with the network.  But, 
as stated in a related email, I think there will be times when 
one-to-one NSA to Network mapping does not work well.

We can allow the string to look like a URN.  As an opaque string, this 
should be fine.  But this does not guaranty the specific string instance 
uniquely maps to one object.   URN strings are not unique just because 
they are URNs.    You still need a registry to qualify the namespaces as 
unique within each scoping and then to register the networkname in the 
final namespace.  DNS names for instance are used far more widely than 
URNs and so are even more recognized than are URNs (URNs are more of a  
programmer's concept than what a user might choose.)    So I might call 
my NSI network...uh, say... "nordu.net", or "kth.edu.se" ..  how's that? 
(:-) and we are good to go.   Or "GN3.BoD" or "GN3.waves".   If you want 
to call your network "urn:ogf:glif:network:nsi:netnames:ION"  thats cool 
too.

(Its interesting to note that in the ION URN example above, the first 34 
characters of the "globally unique name" provide no uniqueness at all in 
terms of network names - these characters would all be present in all 
network names in the global nsi fabric if we were to require the network 
name be a valid URN.  This is klunky IMHO:-).

Plus, the OGF or GLIF namespaces may not be the best place to put 
network names that are intended to be used much more generally.

So
Opaque strings for NSI Network names.  Good.  (IMO)
Registry to insure unique Network names and secure Network & NSA 
binding.  Necessary
Allowing Network names to look like URNs.  Good.
Requiring Network names to look like URNs. Bad (IMO)
Allowing Network names to look like DNS names.  Good.
Allowing Network names to use Kanji. or Dingbats.  Good.
Allowing a single space as a Network name.  Bad (IMO)
Allowing War and Peace as a Network Name. Bad (IMO)
Distinguishing Network name and NSA_ID as different NSI objects.  Good (IMO)
A single indirection to find the corresponding NSA_ID from a Network 
name.   Good (IMO)
Requiring NSA_ID and Network name to be identical. Bad (IMO)
Allowing any NSAs to use globally unique NSA_IDs.  Good (IMO)
Requiring all NSAs to use globally unique NSA_IDs.  Bad (IMO)

best regards...
Jerry

> jeff
>
> On Apr 13, 2011, at 7:56 AM, Guy Roberts wrote:
>
>> Inder,
>> The idea behind the STP address swapping is to allow a federating NSA 
>> to re-advertise child NSA’s as its own resources.  This allows a 
>> federating NSA to hide the complexity of child Networks and present 
>> all resources as part of a single federating Network.
>> Guy
>> *From:*Inder Monga [mailto:imonga at es.net]
>> *Sent:*13 April 2011 14:51
>> *To:*Guy Roberts
>> *Cc:*nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>; 'Jerry Sobieski'
>> *Subject:*Re: [Nsi-wg] usage of STPs
>> Guy
>>
>> Just for discussion today - URN has been a representation of STPs 
>> that has had a lot of support on the mailing list. We should talk 
>> about that option as well.
>>
>> The federating NSA and swapping is a new idea - I am not sure that 
>> has been discussed before. Please elaborate on what the need for that is?
>>
>> Inder
>>
>>
>>
>> ------------------------------------------------------------------------
>> Guy Roberts <mailto:Guy.Roberts at dante.net>
>> April 13, 2011 2:20 AM
>>
>>
>> Hi Jerry,
>> Based on our discussion yesterday I will try and summarize the 
>> current thinking on STPs:
>> STP is a tuple which is formed as: Network_Id:Local_id
>>
>> where:
>>
>> Network_id is an string (unformatted - no syntax specified) which
>> identifies a group of resources available to a single service.  Each
>> Network has an associated NSA, i.e. there is a 1:1 relationship
>> between and NSA instance and a Network.  A single stage lookup is
>> required to find the address of the NSA from the Network_id.
>>
>> Local_id is a string (unformatted - no syntax specified) which
>> identifies a local resource (or endpoint).
>>
>>
>> A federating NSA has the option (not compulsory) of swapping the
>> Network and Local parts of the STP.  Both parts must be swapped (not
>> just the network part) this removes the need for Local_id to be
>> globally unique.  (this is like MLPS label swapping)
>> Does this align with your view?
>> Guy
>> _____________________________________________________________________
>>       **       Guy Roberts, PhD     Network Engineering & Planning
>>     *    *                          Tel:    +44 (0)1223 371300
>>    *      *    City House           Direct: +44 (0)1223 371316
>>    *           126-130 Hills Road   Fax:    +44 (0)1223 371371
>>   *            Cambridge
>>   *            CB2 1PQ              E-mail:guy.roberts at dante.net 
>> <mailto:guy.roberts at dante.org.uk>
>>   D A N T E    United Kingdom       WWW: http://www.dante.net
>> _____________________________________________________________________
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> --
>> Inder Monga
>> 510-486-6531
>> http://www.es.net
>> Follow us on Twitter:ESnetUpdates/Twitter <http://bit.ly/bisCAd>
>> Visit our blog:ESnetUpdatesBlog <http://bit.ly/9lSTO3>
>> Facebook:ESnetUpdates/Facebook <http://bit.ly/d2Olql>
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110414/040ca945/attachment-0001.html 