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