On Thu, Nov 19, 2009 at 1:48 PM, Noel Chiappa <[email protected]>wrote:
> > From: Dae Young KIM <[email protected]> > > Locator was meant to an address that IP would use in routing as it > uses > > IPv4 or IPv6 as routing locator. > > Some people think that internetwork 'location names' should name just the > physical network, and that the interface 'address' is a separate name; the > reason they give is that they are conceptually separate concepts, and the > names that result are from separate namespaces. (I must confess I don't > really understand this view, so I can't explain it perfectly - perhaps > someone else can?) > > I view things somewhat differently, and in a way that's similar to the one > you give above. To me, what is important about a namespace is i) what is > being named, and ii) what the characteristics of the name are; which to me > need to be driven by what the main use/uses of the name will be. > > For i), I would like to be able to name interfaces - because it is to an > interface that the system of routers needs to deliver a packet. However, > that > covers a large variety of names (e.g. a globally unique ID could name > intefaces), Not everything has to be named. For the interface, all we need is an identifier which more specifically is called locator. Again, in this picture, I assume a host can have multiple interfaces, and so multiple locators. And there's only one 'host identifier(ID)'. Host better be named. Since in most applications, number is not very human friendly, and we'd like to use a name like 'mercury.lcs.mit.edu.' But as soon as it is injected into the application, the application would consult the DNS to find a number(host ID) for the name, like, 168.188.48.120.(Sorry not your real number...). > so I need to think also about ii) to pick a kind of name for > interfaces. For ii), I would like to see a structured name, which can be > used > to select/compute a path to the destination in a very large network. > So, apparently, you're looking for names for locators, for you want to use it for routing. For this purpose, you don't really need names, and all what you need is (interface) identifier, which in my picture, is the very locator(IP address). > > I suppose one could say that those names are concatenations of a) a > structured name for the physical network, and b) the name of an interface > (as > I started by mentioning), but I don't see a lot of value in separating the > two in a way which is globally visible - it is only when one gets to the > destination physical network that one needs to be able to separate the two > parts. > This is exactly what current routing is doing. Between the 'physical' networks, BGP only use network prefixes. Once the packet arrives the target network, then the locator is used inside the 'physical network' which constitutes one separate AS. > > > > I would use locator (IPv4 or IPv6 address) for intra-domain routing, > > but not for inter-domain routing. > > My view is that the strict separation between just 'intra-domain' routing > and > 'inter-domain' routing is a simplistic one, and one that I do not think > will > last. I hink that what we really need is the ability to have multiple > levels, > and not just two - and I think those should be within a unified overall > routing system. > Great. We agree here. So, if you have another look at my summary of the idea, AS (aks domain) can recurs inwards and outwards. Domains are not just one tier. There can be multiple tiers or levels. Good point. > > > In this sense, my idea and LISP's meet. Both uses ASN for inter-domain > > routing. > > LISP does not use ASN for any forwarding decision; it uses IPvN addresses > (from the RLOC namespace). > I see. Then I'd diverge here also from LISP. I don't need any extra name space for this. Use of current AS numbers is enough for me. > > Not that LISP really has a routing component at the moment anyway - it > depends entirely on the existing routing for packet carriage. > Here lies the fundamental difference in starting point between LISP and the mission of this RRG. The RRG's mission is to solve the routing problem, or more specifically, the inter-domain routing problem. There can be many approaches, but one approach seemingly getting wider support is to take separation of ID(host) and Locator(for routing) as the basis. Then, we're to further figure out what the best arrangement of those would be to in regard to host, interface, gateways.. is the task of this RRG, as I understand. In the endeavor, this RRG might possibly come up with a again different picture than what HIT and LISP drew. This should be no wonder, for the initiating problem space of HIT and LISP was mainly hosts, whereas that of this RRG is mainly routing/routers. Builing a house from bottom to top might deliver a different house than that would be generated by building one from top to bottom. No wonder at all. -- Regards, DY http://cnu.kr/~dykim
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
