[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-05.txt {1}



Hi Jari, all,
Thank you very much for your comments. :-)
Marcelo also provided a similar comments on this issue.
Please see my responses to your comments in Marcelo mail. :-)

Cheers,
Deguang

Jari Arkko schrieb:
If I understood this correctly, the request
was to provide a "diff" update as opposed
to "here's the new list" message that we
have now:

You are right, I agree with you. However, there still may be the case
where the shim6 host determines one of its locators is permanently
unusable. I think in this case it is better to remove the unusable
locator from the locator set. right? :-)

By the way, I would like to discuss the efficiency of using the Locator
List option for the addition/deletion of locator to/from the locator set
further.
Because this draft specifies that "ALL" the locators must be carried in
the Locator List option (see page42), I think it is not efficient to use
the Locator List option in the case where only one locator needs to be
add or removed while other locators keep unchanged. I think it is not
necessary to update those unchanged locators and repetitively perform
locator verification for those unchanged locators each time when only a
locator changes. As you said , it is expensive option. Right? :-)

If my above issue is reasonable, do you think it is possible to define
two new separate options (e.g. Locator Addtion option and Locator
Deletion option) for adding a new locator to the locator set on a SHIM6
context and for deleting a failured locator from the locator set on a
SHIM6 context.

From a functional standpoint we could use either
the diff or the complete list approach. However, as
this was discussed during the protocol design,
people felt that the latter was a better choice.
It is true that the diff approach can be more
efficient in some cases. However, the benefits
are offset by higher complexity and the risk
of synchronization failures. Finally, I believe
that in most cases where the node is truly
mobile, the number of locators is likely
relatively small, so the real-world savings
may not be that big.

--Jari