On Sun, 16 Oct 2005, Joe Maimon wrote:
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.
You are missing the point. Currently multihomed sites have multiple path entries in the routing table for a specific multihomed prefix. Instead of having multiple paths, you would have multiple location records in DNS. (Which are A records and any possible reordering by round robbin is not part of the actual path selection algorithm and which are associated with indentifiers though a standard to be designed as part of the new protocol.) The process of how you select which one to use (and what knobs you have for tuning) is a design decision, the same way it was with BGP and OSPF.
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.
BGP and OSPF have timeouts and select other paths. They give you the convergence you have now in the event of router failure. For example, a BGP session with a peer accross a public exchange has to time out, your interface is still up. Yes, you have to engineer the protocol for the convergence time you want. Define the goal and figure out the algorithm to achieve it.
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)
Perhaps a shim6 advocate will explain the differences. Does shim6 provide separate identifiers from locators? Does shim6 require new protocol stacks on the hosts at both ends of a session? (If not then the source is not making its own path selection decisions.)
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.
Um, this is equivalent to saying "it doesn't work because I say so". How doesn't it work? For example you could claim (and then try to defend your claim): * It can't possibly converge quick enough because the genius that went into BGP and OSPF was lost and can never be found again. * (ok seriously) It can't converge quick enough because the timeout would have to be X and based on a guestimate of network topology entropy that would result in Y percent more traffic as each host tries to reestablish locator sessions. (Well, then define what percentage of sessions you think get interruped and support your claim.) * You throw away real topology information and rely on latency (or whatever), and using latency doesn't work because it doesn't allow traffic engineering according to policy. (Who said you have to give everybody the same set of locators? Paul might say ewwww. FWIW, if you want the ability to tell different peers different answers like with BGP you will need the ability to give different answers with the new protocol.) Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+