Mike Leber wrote:
On Sun, 16 Oct 2005, Joe Maimon wrote:
For example, if your goal was to have TCP-like sessions between identifiers survive network events without globally propagating full network topology information about your site (the gripe against classic IPv4 BGP) you could have multiple locators associated with any single identifier sort of like the same way you can have multiple A records for a domain name.
Real world shows that that doesnt work very well. Multiple A records is not usuable practicaly speaking for anything other than load balancing, today.
If the location layer session times out then it would try the other locators listed (pick a method of selection) and if it suceeded would resume the session transparent to the identifier layer. Design the timeout and retransmit algorithm and parameters to achieve the convergence times of your choice.
DNS is a good example of something that was designed that way, but few people rely on common implementations actualy performing it properly.
You would need a new protocol stack on the hosts at both ends of connections. By common convention classic TCP hosts could be told to use one of the locators (a transition hack, or just run the protocols in parallel). No change would be required to the network, and existing TCP could continue to be supported (no flag day).
Appears to me thats what shim6 is (cursory reading + nanog discussions)
Of course support of this new protocol would be limited to the clients and servers that chose to implement it, however this is no less than the change required for IPv6 which some hoped would solve the multihoming problem (possibly defined as scalably supporting network topology change without sessions being interrupted).
Long story short, seperating endpoint/locator does nothing to allow multiple paths to a single IP6 address/prefix to scale.