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 TCP connections. I can understand this situation. And, if only for mobility, there're a number of other proposals already out there including HIP. 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. 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? > >> 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. 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. -- DY _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
