On Wed, May 26, 2010 at 9:09 PM, Dae Young KIM <dy...@cnu.kr> wrote: > On Thu, May 27, 2010 at 9:52 AM, Tony Li <tony...@tony.li> 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. > 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). -chris _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
