[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-05.txt {2}
Hi marcelo, all,
Please see comments inline...
marcelo bagnulo braun schrieb:
Hi again,
below...
El 06/10/2006, a las 10:43, Deguang Le escribió:
Hi all,
A slight comments on draft-ietf-shim6-proto-05.txt
-Page45
When the Element length equals one, then the element consists of only
a one octet flags field. The currently defined set of flags are:
BROKEN: 0x01
TEMPORARY: 0x02
The intent of TEMPORARY is to allow the distinction between more
stable addresses and less stable addresses when shim6 is combined
with IP mobility, when we might have more stable home locators, and
less stable care-of-locators.
In above statement and context in this draft, no detailed explanation
for "BROKEN" and its usage.
I think it is better if there is some accurate explanations for
BROKEN and how it is used in this Locator Preference option.
agree
basically the usage of the BROKEN flag is intended for when the host
knows thanks to local information that a locator is temporarily
unavailbale/unreachable, so it can mark it as such, so that the peer
doesn't use it for communicating.
I agree with you, it is a good way to deal with the temporary failure of
locator using the BROKEN flag.
However, if the locator is permanently unavailbale/unreachable say due
to mobility or rehoming, I think it is not necessary to keep the
unavailable locator in the locator set. Right?
As mentioned in the other email, another option would be to remove from
the locator set using a Update message, but i guess this option is
cheaper in terms of processing (cheaper security checks)
As for security check, I am not familiar with security issue, so I don't
know why the Locator Preference option need not verification check. ^-^
Does anyone provide some explanations about it? Thank in advance.
Besides, the above explanation for "TEMPORARY" is still not clear for
me. What are the more stable addresses and what are the less stable
addresses?
the goal here is that if the host knows that there are some addresses
that may change rapidly, it can mark them as such, so that the peer use
more aggresive failure detection mechanisms on that address.
I think it is an interesting usage although it is not easy to determine
which addresses belong to more stable or less stable. :-)
In the case of MIP a HoA is a more stable address and a CoA is a less
stable address
In my own veiw, I don't think the HoA is the more stable address and the
CoA is the less stable address because the mobile node may stay at any
place including the home network or foreign network at any time.
For example, a mobile node may access to the Internet through some
foreign network, then it may moves between the foreign networks, which
are far from the home network. In this case, the HoA may never be usable
during the whole communication period. Therefore, we could not regard
the HoA as the more stable address. Right?
I think it is better if this draft could provides some special
situations about them. Morever, I also can not understand how the
TEMPORARY can be used to distinguish them.
The usage would be that it will include the Temporary flag when
conveying CoA information in the locator set.
As my above statements, I think it is not suitable to tag the CoA as
Temporary. Right? :-)
Do you think that additional text is required to explain this?
Yes, I think these flags are very important in order to put the Locator
Preference option in real use, we need to formulate these flags'
functions and their usage (e.g. applied situations) more clearly.
With best regards,
Deguang
Regards, marcelo
Cheers,
Deguang
Geoff Huston schrieb:
Hi,
This note starts the WG Last Call for comments on the three "base"
Shim6 documents:
draft-ietf-shim6-proto-05.txt "Level 3 multihoming shim
protocol"
draft-ietf-shim6-hba-01 "Hash Based Addresses (HBA)"
draft-ietf-shim6-failure-detection-06 "Failure Detection and
Locator Pair Exploration
Protocol for IPv6
Multihoming"
They can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-
detection-06.txt
Please review the documents carefully, and send your feedback to
the SHIM6 list. Please also indicate whether or not you believe
that these documents
are ready to go to the IESG for publication as a set of Proposed
Standards.
This Working Group Last Call will end in two weeks, on the 12th
October 2006 at 0800, UTC+10
Thanks,
Geoff & Kurtis