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@es.net] *Sent:*13 April 2011 14:51 *To:*Guy Roberts *Cc:*nsi-wg@ogf.org <mailto:nsi-wg@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@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@dante.net <mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________ _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@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@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg