[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design decisions made at the interim SHIM6 WG meeting
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
Geoff Huston wrote:
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
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.
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.