On 17 Jun 2010, at 06:21 , [email protected] wrote: > I always thought you would come up with some > hierarchical location value space when ILNP > will be processed.
IP routing prefixes already are heirarchical, at least since CIDR was widely deployed (which almost 20 years ago at this point). For IPv6 specifically, please see [RFC-4291, Section 2.5] and elsewhere. So I'm confused by your statement above. > Now I realize, you will (re)use IPv6-prefixes (restricted to 64 bits) IPv6 routing prefixes are already restricted to 64-bits, with the low-order 64-bits being an *interface* identifier. [RFC-4291, Section 2.5.1 & elsewhere] > that are uniquely assigned to so-called point of attachments > of any particular ISP's subnetwork, right? They might or might not be "any particular ISP's subnetwork", depending a great deal on how one defines "ISP". Purely as an example, the US Defense Information Systems Agency (DISA) <http://www.disa.mil> has direct allocations of both IPv4 and IPv6 address blocks. Different people have different opinions about whether DISA is an "ISP". On the one hand, DISA is a government agency, and its users (i.e. other US DoD activities) are required to use DISA for IP connectivity. So some view DISA as analogous to the IT group for a very large enterprise. On the other hand, DISA bills other DoD organisations for their IP connectivity, and it provides transit services for its users, so other folks view DISA as an ISP. > BTW, why prefix ? why not address of precisely 64 bits? Hmm. ILNP does not have addresses at all. An "address" is an object that has mixed ("overloaded") semantics. An "address" is sometimes used for location (e.g. with IP routing) and other times is used for identity (e.g. in the TCP or UDP pseudo-header checksum). The entire concept of an "address" is deprecated with ILNP, in favour of separate Locator and Identifier objects, each having distinct and very crisp semantics. > Hosts communicate via DNS their point-of-attachments' prefix > (whereby multiple hosts may share the same such prefix). I find the sentence above confusing. I think the above might be trying to say that an ILNP node advertises its Locator value(s) via the DNS, which is precisely true, but incomplete. An ILNP node will also use the ICMP Locator Update message to advertise changes to its working set of Locators to existing correspondents, for example. > All these point-of-attachment routers communicate > to the outside that they have reachability to such a prefix. > This is the same as what a BGP router is doing. > I.e. this doesn't reduce the number of prefixes. Ah. I am not sure, but I think the question is how ILNP enables the number of DFZ RIB/FIB prefixes to be reduced. The shortest answer is by aggregation of routing prefixes. Today it is nearly impossible to aggregate much, simply because upper-layer protocols, notably TCP and UDP, use the IP address -- including the upstream routing prefix -- for identity. ILNP eliminates this semantic overloading inherent in today's IP address, permitting high-availability multi-homing to different upstream providers while also permitting significantly more prefix aggregation than is possible today. This was answered recently by several other folks, notably Chris Morrow, who has extensive ISP experience. I'll point to some of his previous notes here: <http://www.ietf.org/mail-archive/web/rrg/current/msg06762.html> <http://www.ietf.org/mail-archive/web/rrg/current/msg06783.html> <http://www.ietf.org/mail-archive/web/rrg/current/msg06824.html> <http://www.ietf.org/mail-archive/web/rrg/current/msg06754.html> Several other folks, including tli, fred, and Joel Halpern (all of whom have EXTENSIVE experience with Internet routing) have also addressed this issue in the past. I don't want to cite every prior note to the RRG list explaining this, but as another example, this note from fred is quite clear: <http://www.ietf.org/mail-archive/web/rrg/current/msg06755.html> > By assuming that today's network administrator do a good job while trying > to come up with reasonable prefixes, I cannot see what is the ILNP's > reduction of prefixes to be spread all over. I am sure I do not understand what the above is trying to say. > A different syntactical point: > You camouflage your design by using the term locator although you do not > intend that to be a denotion of location. Incorrect on two counts. 1) I am killing myself trying to be clear, which is rather the opposite of "camoflage". (One might argue that your note indicates I am not fully succeeding in being as clear as I'd like, but I'm certainly not 'camoflaging' anything.) 2) The Locator absolutely does denote location, and never identity. > Granted, you just continue with this bad habit which indeed comes from the > "loc/id"-split discussion, where also at no point in time "loc" > expressed anything like location. The ILNP Locator precisely specifies a subnetwork, so it is precisely specifying a location. > You hereby play foul to those who want location-based routing, because you > educate people to understand something else than a locator ought to mean. Au contraire. My usage is both quite clear, and is also the long-standing usage in the Internet community. JNC has observed on this list in the past that the general usage of "locator", which is the same as with ILNP, goes back over 10 years now -- including to published RFCs from some years back. JNC has written several notes about this. Purely as an example, consider this note from him: <http://www.ietf.org/mail-archive/web/rrg/current/msg06842.html> > And you pave the ground such that people would get confused when someone > uses the word locator in its true meaning. I have no idea what that is trying to say. I will note that my usage is entirely consistent with the common usage within the Internet community. > I am convinced that you would say NO if a straw poll statement states: "A > node's locator" denotes the location of that node". Your crystal ball appears to be broken. [Aside: The Terminology Straw Poll (interim) results are public, so folks can see my views about the terminology statements that are on the table for the poll.] > You provide (via DNS) a different way to learn about the mentioned prefix, > but that's it. I accredit to you that you won't worsen the stretch-of-path > behavior. > You still do the same, only slightly changed. But you also won't improve > routing capabilities (extending to numer of alternative detours, > selecting the right alternative based on actual traffic sizes). I don't understand those words either, terribly sorry. Yours, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
