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

[marcelo bagnulo braun <[e-mail]>]

Hi Deguang,

sorry for the late reply...

El 12/10/2006, a las 22:59, Deguang Le escribió:

> 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? :-)
>
i am not sure what do you mean here...

two shim hosts would end up out of synch in the case where a host A has 
a locator set LsA but the host B thinks that A has a locator set LsA* 
which differs from LsA. In this case since A sends incremental updates, 
they will never get in sync again. In the atomic approach, eachg update 
contains all the locator set, so in the case this happens, it would be 
corrected upon the recepntion of the newest UPDATe message, so the out 
of sync problem is more easily dealt with

hope this helps.

regards, marcelo


> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
>