Re: [rrg] Summary of architectural solution space

["William Herrin" <[e-mail]>]

On Mon, Nov 24, 2008 at 3:21 PM, Brian E Carpenter
<[e-mail]> wrote:
>> 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.

Hi Brian,

Some of the best new ideas are old ones whose time has finally come.


>> 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.

You say Shim6 doesn't need a global map. I say it can't make effective
use of one.

A shim6-enabled host has trouble initiating connections to hosts where
the first chosen address is inaccessible. It also runs into a number
of corner cases where its behavior is either broken or ambiguous. For
example, what happens if:

1.2.3.4 starts talking to 5.6.7.8 which is also 8.7.6.5.
5.6.7.8 dies. 1.2.3.4 starts talking to 8.7.6.5 instead. The app still
thinks its talking to 5.6.7.8.
5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5.
The app at 1.2.3.4 asks for a new connection to 5.6.7.8.

Does 1.2.3.4 connect to the new 5.6.7.8 or does it connect to 8.7.6.5?



With a map, the answer is straightforward:

1.2.3.4 starts talking to example.com (currently 5.6.7.8 and 8.7.6.5)
5.6.7.8 dies. 1.2.3.4 keeps talking to example.com, now at 8.7.6.5.
5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5.
The app at 1.2.3.4 asks for a new connection to example.com (currently 8.7.6.5).


That having been said, ubiquitous deployment of Shim6+DNS combined
with the kind of dynamic address assignment I described could
reasonably form a strategy-B protocol. I don't think it forms a
particularly good one, but I doubt I could do better under Shim6's
mapless design constraint. With a map I can do better. Much better.



>> 2. In strategy B, locator assignment is dynamic.
>
> Why is that a necessary property?

Because we want to optimize the network for hierarchical aggregation
in the instant topography with whichever link sets are currently
working. We've already learned that administratively optimizing a
static "best case" view of the network for hierarchic aggregation is
burdensome and dysfunctional because the network state isn't static.

And we want the addresses to change regularly enough that no one makes
the mistake of writing software which assumes otherwise. We won't
achieve either goal with administrative assignment.


> Whether that works or not gets quite complicated.
> draft-ietf-6man-addr-select-sol-01.txt
> draft-baker-6man-multiprefix-default-route-00

Thanks for the refs!


>> 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.

The original IPv6 strategy was:

Make everybody attach to only one ISP using IPv6 and a subset of the
ISP's single set of PA addresses.

That may not have been the original hope, but that's what popped out
of the process.



Okay, maybe I see your point. Let me repeat it in my words to make
sure before I commit it to the document.

I think what you're saying is that if we make sure that the layer-4
protocols properly continue the communication session as layer-3
addresses are added and removed and we deprecate and remove variants
of the layer-4 protocols which don't achieve this, we should be able
to use multiple statically (aka administratively) assigned subnets
with IPv6's layer 3 to achieve an acceptable reduction of the routing
table size. Theoretically, IPv6's deployment is meager enough that
deprecating the non-compliant variants of the layer-4 protocols now
wouldn't be too painful.

How close did I get?


Regards,
Bill Herrin


-- 
William D. Herrin ................ [e-mail]  [e-mail]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/rrg