Re: Design decisions made at the interim SHIM6 WG meeting

[Jari Arkko <jari.arkko@piuha.net>]

I don't recall the exact discussion. FWIW, I think that both the
exploration and other parts of the protocol have a similar
situation with explicit  listing of addresses vs. using indexes:
the former creates a need to be very sure that we have
synchronized lists at both ends in the correct way. IPv6
addresses are large, so there's a tradeoff in packet size
vs. simplicity. At the moment my opinion is that we should
err on the side of simplicity.

In addition, the exploration, reachability, initialization
and update parts have the added complication that if
we ever want to use these components of the protocol
for other purposes, then explicit addresses may be the
only way, given v4 NATs, v4-v6 translation mappings, etc.
may create different views about the addresses on the
two peers.

--Jari

Geoff Huston wrote:

> Erik,
>
> My notes were more definite on that point, and I recall the discussion 
> we had, and I thought we erred on the side of extreme caution / 
> conservatism in terms of explicit enumeration of locator sets within 
> control messages rather than assuming that the other end had a 
> synchronized ordered set of locators that of course agreed with the 
> local set.
>
> But if you are confident that this locator set synchronization is 
> maintained within the control message exchange, then this design 
> decision can be dropped and locators can be referred to by their index 
> value within a synchronized ordering of the locator set.
>
> regards,
>
> Geoff
>
>
>
> At 02:54 PM 20/10/2005, Erik Nordmark wrote:
>
> > Geoff Huston wrote:
> >
> > > 8.  Do not use locator ordering and index references in SHIM6 control
> > >     messages in the initial base spec
> >
> >
> > I'm not sure we really decided that at the Interim meeting. In the 
> > current proto draft the locator preferences are expressed by assuming 
> > that the locator list is ordered so that the relative position can be 
> > used in the locator preferences without having to include all the 
> > locators themselves in order to express the preferences.
> >
> > Jari did express that he didn't think this was necessary for the 
> > reachability part, but I haven't checked how that work is evolving yet.
> >
> > So I think it is premature to make the above decision.
> >
> >    Erik