On May 27, 2010, at 10:03 PM, Christopher Morrow wrote: > On Thu, May 27, 2010 at 11:04 PM, Dae Young KIM <[email protected]> wrote: >> On Fri, May 28, 2010 at 11:19 AM, Christopher Morrow >> <[email protected]> wrote: > >>> Note, you lose all redundancy, resiliency and convenience of having >>> local identifiers which are stable. >> >> This will be my private homework yet, if the local identifier(host IP >> address) would not point to the interface but to the node itself. > > this is how some (for instance) root servers today do anycast > services. Put the 'service' ip address on the loopback interface (or > similar alternate interface) then just route traffic over the other > locally connected interfaces ... This works fine, it's not something > an average user wants (or really can) manage though. It requires still > some knowledge, at least in the local network realm, that ip-X is down > one of several interfaces. Expanding this to 'down several providers' > means that the providers must know, and thus the world must know that > this /32 (ip-X) is globally reachable. This is done with PI space and > we all pay a penalty (we all dfz router operators and users of the > internet) for this 'feature'. > >> > ....... >>>> - against old hosts transitioning across multiple PA addresses. >>> >>> old-hosts don't do this, they have a locator. if that locator changes >>> (they renumber) then all their current connections stop, all reset and >>> all restart when all distant endpoints re-learn the new locators. >> >> Sad there's no mechanism (or inherently impossible) that a multi-home >> site and so all nodes inside deal with multiple PA addressed assigned >> to them in a seamless (not causing the breakages you describe above) >> manner. > > Oh you CAN do this, you don't WANT to, there are lots and lots of > dependencies and timelines to satisfy. All of which make the pain of > changing things far to costly and complex to implement 'quickly'. For > a simple case: 1 host, 2 providers 1 router. Here's a short list of > things to consider (no particular order) > > o access controls on the host (from which ip, to which ip) > o dns updates for changes > o publishing dns records for each identifier/address > o traffic engineering to assure that folks use the addresses being > advertised over DNS properly/fairly > o upstream uRPF checks (must send to the internet with the right > source-address, based on which outbound port is choosen) > > There are a few others I'm sure, never mind the case of a more complex > Enterprise network deployment.
Chris, I was reading this and wondered whether I should should be concerned about "you don't WANT to" in the above. Although ILNP stated it as an option to use a local prefix locally, I got this feeling that some people prefer the notion of propagating multiple PA prefixes into a site. >>> under ILNP you have the option to move locators 'at will' (gated by >>> how quickly you can tell the exisitng endpoints "and start talking to >>> me via this new locator, NOW.") When you change attachment points all >>> existing communications just keeps on going, without >>> loss/reset/restart/timeout. >> >> Of course with ILNP. > > this is one of the strengths of the ilnp/8+8/gse solutions, really. > Once/if the mapping-foo can be addressed in a sane/simple manner I > think this has some promise. It seems to me that ILNP's mapping is simple (through DNS or communicating ends can just inform each other), right? but one thing I dont fully understand yet is how to relate traffic engineering needs with such host-originated locator (hence paths) changes. Lixia _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
