Bill, On 2008-11-25 02:03, William Herrin wrote: > On Sun, Nov 23, 2008 at 8:25 PM, Brian E Carpenter > <[EMAIL PROTECTED]> wrote: >>> The third draft is now available at >>> http://bill.herrin.us/network/rrgarchitectures.html . >> Looking at Strategy B, I have two comments. >> >> One is that >> "Assign multiple LOCs to each host such that in the network >> topography hosts appear as stubs in multiple locations..." >> appears to me to be quite clearly the *standard* model for >> IPv6, a.k.a. Plan A, so I would suggest inverting the names >> of Strategy A and Strategy B. > > Hi Brian, > > Neither strategy A nor strategy B are reflected within the standard > model for IPv6. > > Some specific differences between standard and strategy B: > > 1. In strategy B, communication sessions survive the loss of any of > the locators. This is a new requirement on layer 4.
It was introduced (as a goal) by the MULTI6 WG in RFC 3582. I don't see it as new. > Neither TCP nor > any of the common UDP protocols handle this. The dynamic map updates > serve two purposes: first to let the remote endpoints know that a new > set of locators is available to reach you and second as a lightweight > authentication mechanism so that the remote endpoint knows which > locators are valid as sources in the packet. That's a very good brief description of SHIM6, which does not need a global dynamic map as it works purely end to end. It also hides the dynamics from the transport layer, so TCP and UDP are unaffected. Soa global dynamic map, and changes to the transport layer, are not necessary properties of strategy B. > > 2. In strategy B, locator assignment is dynamic. Why is that a necessary property? If that *is* a necessary property of strategy B, then you have a missing strategy which is essentially B with administratively assigned locators (which is, I believe, the current IPv6 standard strategy, and always has been). My suggested changes were to include this as a variant withing your strategy B. In any case, I believe it needs to be covered in the solution space. > Not just automatic > and not just on the LAN. It starts at the first service provider in > the core and dynamically propagates hierarchically down to you with > each router receiving the block of addresses from an "upstream" > router, assigning subblocks "downstream" and swapping peer routes > laterally. That can work either administratively or dynamically, too. > > As a result, ** the network often adjusts to a edge-network link > failure by propagating a new set of locators (layer-3 addresses) > downstream and expiring the old ones, ** an approach that retains the > hierarchic aggregation of the locators regardless of the current > network topology. Note that this requires the impacted hosts to > dynamically update their respective map entries. Not to mention DNS. But once again, it will work whether the locators are assigned dynamically or administratively. (Incidentally, if they're assigned dynamically, there will still need to be an underlying invariant administrative handle that is used for the assignment process to work.) > > Also as a result, hosts require layer-4 protocols capable of dealing > with multiple layer-3 addresses (locators) in each communication > stream. As noted, a shim can solve that problem. > > > 3. In strategy B, a route has to match both the source and > destination. This enforces the hierarchy. A route source and > destination can't both be 0/0. Announced coreward, 0/0->Dest/long. > Announced hostward, Dest/long->0/0. Announced laterally, > Source/long->Dest/Long. Thus your packet automatically goes out the > correct service provider for the selected source locator. > > While this is possible with a number of IPv6 implementations it is not > a standard part of the architecture and not a requirement. Whether that works or not gets quite complicated. draft-ietf-6man-addr-select-sol-01.txt draft-baker-6man-multiprefix-default-route-00 > > > > > Would you suggest changes to the strategy B description that make this > more clear? Well, either include the multiple administratively assigned LOC case or add a new strategy which is actually the original IPv6 strategy. > > > >> 1. There's no problem with transport protocols as long as the >> IP stack conceals the address dynamics from the upper layer. > > Yeah, there is. Sessions don't survive the loss of a layer-3 address > and start slow when one of the addresses isn't available. As a result, > simple multihoming still has to be carried in the core. SHIM6 and SCTP > try to tackle the problem and one or the other may be a viable > connection-oriented layer-4 protocol in a strategy B network. I > personally think that with the right selection of layer-3 semantics we > can do better. Regardless, we'll also need to address the problem for > connectionless (UDP-based) protocols. I don't understand why you think there's an unsolved problem, given that SCTP solves it explicitly and SHIM6 solves it for UDP and TCP (and, I think, DCCP). That applies to administratively assigned LOCs (which can be found in the DNS). I agree that there may be a harder problem for dynamically assigned LOCs - as noted above, that will require an administratively assigned handle to exist, and that will have to be used as the key to find the current LOCs. But once you have done that, the SCTP or shim solution works. Brian _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
