On Thu, Nov 19, 2009 at 11:42 PM, Noel Chiappa <j...@mercury.lcs.mit.edu>wrote:
> > From: Dae Young KIM <dy...@cnu.kr> > > Dave Clark's NewArch project talked about this at some length. The design > they produced was a lot more radical than I think (alas) is feasible in the > Internet, because there are 'deployed base' issues which make such a > radical > revision hard/impossible. It did not have globally-unique endpoint names. > Good work they did. > > We never finshed the locator part, but I argued to them that there are > fundamental reasons (which I explain below) why those do have to be > globally > 'meaningful' (to pick a slightly less rigorous word than 'unique'); > although > they essentially need to be 'unique' too, because if two different > locations > have the same globally meaningful locator, you cannot distinguish between > them, which seems.... problematic. > I'll try to repeat below, but in my picture again, it looks like: o locator can be local (no need to be globally unique). o the remote locator would be retrieved (from a cache or a server) at the arrival of a packet there. On inter-AS links, AS# is enough to reach the other side. Since then, the combination of AS (available already on the inter-domain link) and locator (to be available at the arrival of the packet) should provide us a 'meaningful' locator in effect. Would it? > > (To me, naming a thing with a name of local scope, and naming the scope > with a globally-unique > name, so that you can refer to the thing with a two-part name which is > globally unique, is effectively giving it a globally unique name.) > Yes, exactly. Why don't you take this two-step approach? > > So many systems which attempt an evolutionary path which turns the existing > IPvN addresses into EIDs need them to be globally unique, since they will > be > trying to process packets which contain only an EID, and need to look the > EID > up. > Using IPvN addr as EID has the advantage. Although EID need not be globally unique from architectural sense, the current IPvN infrastructure already provides us the global uniqueness. Why then shall we abandon this already acquired asset(free lunch?) without good reason? Having EID global provides us with an additional advantage, as you pointed out. A compromise with the 'deployed-base', but a rewarding compromise. > > As to locators, the argument for their need to be globally 'meaningful' > (and > hence unique, as shown above) is simple: to compute paths across a fabric, > you need names which are unique across the fabric. I.e. when you give a > locator for some place on the far side of the network to the path-selection > (i.e. routing), that name has to be 'meaningful' to the path-selection. In > other words, that name has to uniquely identify, out of all the possible > 'places' in the network, the place you are trying to get to. > Well, here, let's break the name in two pieces. The AS part is globally unique, and it will ensure the delivery of the packet to the destination AS. The local locator will then be retrieved/appended in injecting the packet into the target AS. Wouldn't this two-step approach yet provide us with the effectively 'meaningful' global uniqueness sufficient for routing? > > Sometimes people aay 'oh, but you can have a source route which is a list > of > local-scope names, so therefore you don't need global-scope locators'. The > first part is true, but the second part is not: how was that source route > computed to begin with? Unless there is some way to create that source > route, > some way to compute the path (which I claim requires globally significant > names), the fact that a source route can be composed of local-scope names > is inteesting but not really relevant. > I won't be enthusiastic at all with this source routing idea. -- Regards, DY http://cnu.kr/~dykim
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
