On Thu, May 27, 2010 at 6:55 PM, Dae Young KIM <[email protected]> wrote: > On Thu, May 27, 2010 at 11:38 PM, Christopher Morrow > <[email protected]> wrote: >> On Wed, May 26, 2010 at 9:09 PM, Dae Young KIM <[email protected]> wrote: >>> On Thu, May 27, 2010 at 9:52 AM, Tony Li <[email protected]> wrote: >>>> In today's world, the cannonical approach for that site is to use PI >>>> addressing. This is necessary since the existence of two sets of PA >>>> addresses would NOT give correspondent hosts a seamless failover >>>> experience. >>>> Instead, it would result in an unacceptable service interruption. Thus, >>>> sites argue for, and get PI addresses. >>> >>> Even in ILNP, the remote correspondent host would see two PA locators >>> for my host, not one. The the same failover problem would exist. Not >>> correct? >>> >>> If correct, then do you mean the failover would be seamless with ILNP >>> and not with the current Internet, even though both are involved with >>> the same number of multiple PA locators/addresses? >> >> like 8+8/GSE ILNP allows the hosts to separate their identifiers (PA >> addresses on interface(s)) from the L4 headers/conversation. The same >> sort of thing is proposed in MIP and SHIM6, you can rotate the >> underlying interface identifiers at will, as long as you communicate >> with the far end that you're identifier addressing has changed, >> independent of the ongoing TCP/UDP/ICMP conversations. > > You're talking about host mobility here, since you're concerned with
no, mobility is 'free' with ilnp/gse/8+8, it's just a class of multihoming with a higher rate of underlying change. I was specifically talking about multihoming. > TCP connections. I can understand this situation. And, if only for > mobility, there're a number of other proposals already out there > including HIP. which has gotten stellar adoption so far, right up there with SCTP... we're off topic some. I was talking about multihoming. The ability to have redundant/resilient/cost-effective paths to/from remote destinations, and (with ilnp/gse/8+8) the ability to do that without introducing lots of state in the global routing system. > Was the initial/primary goal in regard to mobility? I don't think so. > It was to multi-homing. > > With multi-homing situation, I don't think we're so much sensitively > concerned with breakage of TCP connections. Our primary concern here > is how our new scheme would significantly contribute to reduction of > DFZ routing table size, i.e., routing scalability. sure, DFZ has, in the most simple form, 1 route per 'ISP', folks can attach/detach from the best option for them at the time in question. They can do this without having to tell the whole of the routing world 'I moved'. > Would you please compare the performance quality of the current > Internet (assuming use of only PA addresses, not PI) against ILNP in > terms of routing scalability? assuming ONLY pa? the internet wouldn't be what it is today. If you could assume that there were ONLY PA addresses in use and thus no one wanted to 'multihome' then... it's the same as ILNP modulo some DNS hackery which ILNP requires. Note, you lose all redundancy, resiliency and convenience of having local identifiers which are stable. > >> >>> If the Internet architecture itself is to blame, because it cannot do >>> the 'seamless' failover as could be done with ILNP, then I could >>> understand why we ever started this whole RRG procedure. >> >> I don't think it's as simple as 'the internet architecture is to >> blame' but the addition of the L3 header info in L4 checksums is >> certainly part of the problem... the fact that host stacks also tie >> the connection to a block of ip/proto/port is another problem. ILNP >> tries to correct that (in the same basic way 8+8/gse did). > > I think your concern here also seems to be focused on mobility. Let's > take the example in view of multi-homing. it's not mobility, though mobility is just multihoming at a faster change rate. > And please be kind to elaborate more why ILNP would outperform the > current Internet > > - with ILNP hosts seamlessly transitioning/failover across multiple Locators > - 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. 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. 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...) -chris _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
