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'. > > I know a lot of people out there already know much about this > scenario, which they say will only be futile. > > I'm not convinced about this yet, and not to annoy other experts here, > I'll keep this to my private homework. Whether local addressing could > survive for routing scalability. can't. > >>> - 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. >> 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. >> Further to do something similar in today's internet you must announce >> new state into the global routing table, you keep your local >> 'identifier' (which is your ip address) unchanged and you move >> attachment points as you want. You make everyone else pay for the >> extra state management in the routing system though :( (nicely they >> make you pay for their extra state...) > > Not if there'd be a mechanism that you keep your local node address you can, it's PI (provider independent space). > and not to have to report your intra-site moving to change any state > in the global routing table... which, apparently, is already a > nonsense to most routing experts in this group. uhm, so my host has ip address A, it's got attachments to networks B, C, D. how does the world know that services on A are behind B, C, D except for bgp telling them? If you choose to tell them via DNS you're telling them "Find me at B" and their packets (today) get addressed to B, not A. This only works, today, if you tell them, in DNS, "A is me, send to A"... but then as we move from B, C, D we have to tell the world with BGP how to find us. -chris _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
