On Wed, Nov 12, 2008 at 5:31 PM, Scott Brim <[EMAIL PROTECTED]> wrote: > On 11/11/08 6:29 PM, William Herrin allegedly wrote: >> On Tue, Nov 11, 2008 at 4:38 PM, Scott Brim <[EMAIL PROTECTED]> wrote: >>> On 11/11/08 3:39 PM, William Herrin allegedly wrote: >>>> http://bill.herrin.us/network/rrgarchitectures.html >>> Since you start by talking about the root cause of the routing scaling >>> problem, I'll start by saying that it isn't _just_ conflation of locator >>> and identifier. Even if identifiers and locators were completely >>> separate, if routing stayed the way it is today you would still have >>> problems because sites will still want PI prefixes if only to avoid site >>> renumbering problems, and will still inject prefixes for traffic >>> "engineering" and to prevent hijacking. >> >> Thanks Scott. >> >> Isn't the renumbering hassle tied to the fact that the addresses >> identify the servers? > > As far as renumbering goes, external access to servers can get sorted > out through DNS TTLs,
Hi Scott, Operational experience says no lifeline with DNS TTLs I'm afraid. DNS TTLs only work right with applications which pay attention to DNS TTLs. This works out to something south of 10% of deployed apps: most interface with DNS via the gethostbyname call. Some undetermined and indefinite time later, the other 90% are restarted or encounter some other event that causes them to look up the DNS entry again. > but I'm told there are also problems because > changes are required in internal routing and forwarding configuration, > and in configuration of external sites you have special relationships > with. I'm not sure that makes sense in context. Given a protocol in which the GUID, SID and LOC are separate, why would you ever statically assign the LOC to anything? Borrowing the MAC address example again, I can count on the fingers of one hand the situations in which they get statically assigned, especially across multiple routing domains. >> Would you expand on translation? How does translation reduce the >> number of entries in the routing table? > > Consider Six/One Router or NAT66 or LISP's "NAT". If you translate a PI > prefix into one or more provider-aggregatable prefixes, you've > eliminated the PI prefix from global routing. If I understand Six/One router (and please correct me if I'm wrong), it alters the the IPv6 source and destination addresses entering the core by replacing the edge PI prefixes with provider-assigned prefixes. The edge PI prefixes are fed (via the mapping system) to the router where the packet exits the core. When exiting the core at the other side, the edge PI prefixes are restored. I'm not sure I'd call that translation. It seems like Strategy A variant A1c where the "provider-assigned prefixes" are RLOCs. Instead of adding space in the packet for the RLOC, a portion of the GUID is mapped out to make room for the RLOC on entering the core and then mapped back in on exiting the core. The extra map-in-on-exit is the price paid for maintaining compatibility with the existing IPv6 protocol. Maybe that's an engineering compatibility difference like the gyrations for PMTU in map-encap rather than an architectural difference? What do you think? How do NAT66 and LISP's NAT differ from Six/One Router? Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
