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

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

Hi Marcelo, all,
Thank you very much for your response.
Please see my comments inline...


marcelo bagnulo braun schrieb:


Hi Deguang,

Thank you for the comments.

see my comments below...

El 05/10/2006, a las 12:07, Deguang Le escribió:


Hi all,
A slight comments on draft-ietf-shim6-proto-05.txt

-Page74
10.1.  Sending Update Request messages
   When a host has a change in the locator set, then it can communicate
   this to the peer by sending an Update Request.
To my understanding, the above stentence state the Update Request message (with Locator List Option, right?) 


yes


 is sent when (or if) the locator at the SHIM6 host is changed.
Right?



yes
But It is not clear for me about the "locator change", because the situation "locator change" is too general. 


i am not sure i am following.
This is used whenever there is a change in the loccator set, in order to inform the peer about the changes in the locator set. So while i agree that there are many reasons why the locator set can change, i think that all of them are valid reasons to use the Update message. I mean, do you see any situation where we could have a locator change and the usage of the Update message wouldn't apply? 

I don't mean that there are any situation where we could have a locator
change and the usage of the Update message wouldn't apply. ^-^
I mean: could the usage of the Update message apply in the mobility
situation where we could have a locator change? :-)
I think it would be better if this draft could provide some examples (cases) about the locator change in real applications. For examples, I would like to know if the follwoing cases belong to the "locator change" situation described in this draft: -A SHIM6 host is assigned a new usable locator at some interface of the SHIM6 host.
We can add in the draft that a locator change is either to add new locators to the locator set or to remove locators from it. 


-A SHIM6 host finds one of its locators is unusable or failure.
Please note that when a host finds that one of its locators is temporarily unusable e.g. it is unreachable, or there is a local failure, it can use the Update message to inform about the situation or it can simply convey Locator Preference infromation. This lasst option is a cheaper option in terms of processing because of the security checks 

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.
If the above two examples belong to the "locator change" situation, then I would like to know if a SHIM6 host must (or can or need to) send the Locator Request message with Locator List option to its peers when the SHIM6 host is assigned a new usable locator at some interface of the SHIM6 host or when the SHIM6 host finds one of its locators is unusable or failure.
but this would be up to the host to decide based in its local policy rather than a protocol issue imho 
You are right, and I know what you mean. But, I'd only like to know,
from the functionality point of view, if the Update Request message with
Locator List option "CAN" be used for this purpose when the above two
situations occur. :-)
From the your following explanations, I think you agree the Update
Request message with Locator List option "CAN" do this.
I mean if a host has a new locator it can either add it to all of its established contexts, or to some of them or none of them depending of local considerations. Moreover, a host does not need to add all its locator to all its shim contexts. for instance a host could have a set of locators tha it uses for certain communications (e.g. communications within its own site) and some other set of locators that it uses for other communications (e.g. intersite communications) All these cases are perfectly ok and the spec supports any behaviour that the host decides to choose A similar consideration applies to the case where the host looses on locator. Depending on the situation it can either rmove from the locator set using an Update message or it can mark it as broken using the preference option or it can even do nothing and the peer will determine that the locator pairs contianing this locator are unreachable and will not use them. All these approaches are possibel and they are supported in the spec.
So, i am not sure we need to add additional constraints on how ths needs to be used, what do you think? 

Thank you again, I think your answer confirms my understanding.

This draft specifies the messages, which are used for multihoming, but
it does not clearly present (or explain) if these specifications could
be appled for mobilty usage.

So, the reasion why I ask these questions and make these comments is
that I am not sure if SHIM6 can be used in the mobile environments where
a host may change its attachment/location to Internet, namely change the
locator (including locator additon and locator deletion).

In fact, the above two examples I described are exactly the situations
that appear in the mobile environments. To my understanding, the
specified locator update messages also can be used for mobility
scenario. Now your answer confirms my understanding. Right?




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