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

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


El 13/10/2006, a las 21:40, Deguang Le escribió:


Thank you very much!
I think I can understand the situation you described, namely SHIM6 works together with MIPv6 and the SHIM6 of the MN uses some HoA as the current locator no matter the MN is attaching the correspondent home network or not. Right? ^-^
no, it just means that the HoA is reachable even if the node is not located in the home network, because the HA will forward the messages to it.
Base on this situation, your statements are right. However, I think, on one hand, the your described reachability of HoA is achieved through MIP mechanism not SHIM6 itself, on the other hand, although the MIP is appled together with SHIM6, it is still possible that the HoA may be unusable due to the failure of home link or home agent. Therefore, we still could not ensure that the HoA is always reachable.
right, but this can also happen to the CoA so both the CoA and the HoA may not be reachable because of an outage 


In fact, my understanding about the criterion of choosing a HoA as the
current locator has some different to yours. I think the choice of
current locator for a shim6 host depends on if the locator (no matter
HoA or CoA) is currently associated with a interface of shim6 host and
is active. Only those active HoAs, which are associated with the shim6 host's interfaces, can be chosen for current locator. For example, if the SHIM6 host does not attach to a home network (link), then the SHIM6 protocol of this host should not choose the corresponding HoA as the current locator. This is the reason why I don't think the HoA is the more stable address. right? 

no
the CoA is only valid when the MN is located at the visited network. once the MN leaves the visted network, the CoA is no loger associated with it. The HoA is associated with the MN even if the MN is not located in the home netwrok. In this sense, it is expected that the HoA will be a more stable address than the CoA, meaning that the HoA will be a valid locator for a longer period than the CoA which validity period is determined by the time spent in the visited network. 

This is independently of how you select your preferred locator.

Regards, marcelo



:-)

Have a nice weekend!
Cheers,
Deguang
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? :-)


see above

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.
I am ok with addin additional text for the broken flag since there is no text describing it... i am willing to include additional text on the temporary flag, but not sure what to include there though... 
Regards, marcelo

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