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

[Deguang Le <[e-mail]>]

marcelo bagnulo braun schrieb:
> 
> El 08/10/2006, a las 17:09, Deguang Le escribió:
> 
>>
>> 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 guess so...
> i mean, in the mobility scenario, the host learns a new address from the 
> visited network. This address can be used as a locator for established 
> contexts. The result is that there is a new locator available for the 
> shim context. If the host wants to use the new locator for the 
> estbalished communication, it must add it to the existent locator set 
> and in order to do that, it should use the Update message
> 
> But in any case, imho this falls in the general case where the host 
> learns a new locator and wants to use it in the established contexts 
> (similar to the case where a new prefix is added for a multihomed site)
> 
>>>>  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? :-)
>>
> 
> yes, this seems the most neat approach
> 
>> 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? :-)
>>
> 
> this issue was discussed during the design and there were two possible 
> approaches: the atomic approach, where each update message contains all 
> the locators and the diferential approach where each message contains 
> the diff from the existent locator set. As you mention the differential 
> approach is more efficient in terms of overhead. The problem with the 
> differential approach is that is more complex because both peers need to 
> be synchronized i.e. both ends need to have the same idea of what the 
> current locator set is. If a message is lost and the synchronization 
> between the peers is lost, then they will end up with different 
> perceptions of what the locator set is. This must be avoided. If we want 
> to avoid this we need to build a reliable mechanism for exchanging the 
> update message and its associated complexity, and also how to deal if 
> the peers end up out of sync. We decided that it was a reasonable 
> tradeoff to use the atomic approach and we have more overhead but less 
> complexity.

Thank you very much for your detailed explanations. And I find that the 
similar statements are presented in Page 113. However, I still can not 
understand well why we need the "synchronization". :-)

At first, I can not understand what the "synchronization" means exactly.
To my understanding of your statements. I guess that the
"synchronization" is a mechanism through which the communicating SHIM6
hosts can know what the current locator set is, because the 
communicating SHIM6 host don't know what the current locator set is. 
Right? :-)

If my understanding is correct, I however don't understand why both 
SHIM6 hosts don't have the same idea about what the current locator set is.
I think the current locator set is in the SHIM6 context, in other words, 
each SHIM6 context has (or keep) a current locator set. If the SHIM6 
context have been established, the SHIM6 host can obviously know what 
the current locator set is through the SHIM6 context, which is 
identified by the context tag, because both SHIM6 host can know the 
context tag. 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.
>>
> 
> see above...
> 
>>>> 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.
>>
> 
> absolutely, this is possible and a shim6 host can use it in the way you 
> propose
> 
>>
>>> 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.
> 
> 
> right, but this is a multihoming solution.... whether this can or not be 
> used for mobility is another issue and i think it is explicitly out of 
> the scope of the wg (see the charter)

Yes, you are right. I know SHIM6 is currently for multihoming solution, 
nor for mobility, and multihoming related issues are mainly discussed in 
SHIM wg. Since mobility and multihoming have some commen features, and 
mobility will be ubiquitous on the future Internet, we also need to 
investiages the possible applications in mobile environments (like the 
drafts: draft-bagnulo-shim6-mip-00 and draft-ietf-shim6-applicability-01 
), even the potential of mobility support. :-)

Cheers,
Deguang



> 
> However, the shim6 protocol can work with mobility protocolos like MIP 
> and their interaction is detailed in the applibility statement draft


> 
>>
>> 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?
>>
> 
> i think you could, but as i mention this is explicitly out of the scope 
> of the wg
> 
> Regards, marcelo
> 
> 
>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>