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? I don't hear of a lot of renumbering issues > arising from failed ethernet cards where the new card has a different > MAC address. If the ID always stayed the same and a locator change was > no more involved than every machine getting a new MAC address and > sending out a gratuitous ARP, would there still be a renumbering > issue?
As far as renumbering goes, external access to servers can get sorted out through DNS TTLs, 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. >> Also there are three different identification issues that are themselves >> conflated much of the time: >> >> (1) AAA identifiers used to check in with a home agent and/or source >> of funds and access a network at all. >> >> (2) Persistent identifiers that can be used for location discovery. >> They could even be DNS names, SIP URIs, HIP HIs, GSE ESIDs, >> whatever. >> >> (3) Potentially ephemeral identifiers for session control. >> >> Some of the schemes we've been discussing separate #2 from IP addresses. >> Others separate #3. Others don't separate them at all (leaving that up >> to something else) but still solve routing scaling anyway. > > An excellent point. > > When I talked about ID in the paper, I meant the second and third > elements. In the next draft I'll use GUID (for #2) and SID (for #3) > and drop the term "ID" altogether. Good? Let's try it. > Do we want to consider AAA in this context at all or is AAA adequately > served with protocols that sit at a higher level than routing? Does > the IPv4 or IPv6 address currently carry AAA information in a reliably > usable form? Right, I just mentioned it because I had a conversationa few days ago where we had to separate it out. >> It looks like Strategy A includes both what UCLA calls "separation" and >> translation, and that Strategy B is "elimination" with the assumption of >> rewriting at the edge. > > In truth, I didn't consider translation at all. In strategy A, I > expected that the encoders would either fill in header space reserved > for the RLOC or encapsulate the packet in a new one containing the > RLOC. The difference to me seems to be an engineering distinction. > > 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. This does nothing about prefixes injected for TE or anti-hijacking. > If translation is like Strategy A except that you replace the > destination address with an RLOC from the destination's aggregated set > of RLOCs (A1c) (and possibly replace the source address with one of > the source's RLOCs), what criteria identifies situations in which > translation would be preferable to retaining the destination address > and adding an RLOC? Some people point out that translation is less complicated, but I don't know what the side effects will be. I'm uncomfortable breaking e2e integrity at the IP layer, which encapsulation preserves. Translation is also (obviously) useful for interworking. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
