Re: [MEXT] IPv4 home address option in DSMIP

[Hesham Soliman <[e-mail]>]

> Hi Hesham,
> 
> HA doesn't replace the BCE such as remove the old BCE and creat a new one
> when recieved BU.
> HA just update the option in BCE also included in BU and others option in
> BCE remain valid.
> 
> Such as draft-ietf-monami6-multiplecoa-11,  When multiple Binding Identifier
> mobility options are present in the Binding Update, it is treated as bulk
> registration. But not all BCE should be removed. Only when 'O' flag is set,
> HA remove all old BCE.

=> We've discussed this specific point for the MCoA draft and for flow
binding. Ryuji explicitly stated that they did modify the semantics of the
BU for that draft. Please review those exchanges to see the details.

I don't see the need for doing what you suggested below because it adds
ambiguity and the benfits are minimal. Given this late stage I'm not in
favour of making further optimisations. No one else seems to express
opinions on this so my preference is to leave it as it is.
 

Hesham

> 
> Regards,
> Xiaoyan
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Shi Xiaoyan
>> Sent: Tuesday, January 20, 2009 6:06 PM
>> To: 'Hesham Soliman'
>> Cc: [e-mail]
>> Subject: Re: [MEXT] IPv4 home address option in DSMIP
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Hesham Soliman [mailto:[e-mail]]
>>> Sent: Monday, January 19, 2009 8:04 PM
>>> To: Shi Xiaoyan
>>> Cc: [e-mail]
>>> Subject: Re: IPv4 home address option in DSMIP
>> 
>>>> 1. BU without IPv4 home address option works well for extending
>>>> lifetime. I can't understand what you said "how a BU
>>> works". Is there
>>>> any Specification to require that BU for exending
>> lifetime  must be
>>>> consistent with BU for first register? Is there any special
>>> effect? In
>>>> fact, with more and more extension for BU in future, the
>>> requirement
>>>> that BU for exending lifetime must be consistent with BU
>>> for first register will cause unnecessary load.
>>> 
>>> => Yes I know that will use more bandwidth but I don't
>> understand what 
>>> you're objecting to. Implementations copy the contents of
>> the new BU 
>>> into the BC to replace the old entry, as specified in 3775.
>> So a new 
>>> BU overwrites the old one unless you desgin a new option
>> per extension 
>>> that tells the receiver to only refresh.
>>> 
>> 
>> In my opinion, re-registration BU should not include the IPv4
>> HAO. Because re-registration BU with IPv4 HAO 1. Need more bandwidth.
>> 2. Cause extra load on HA. Because HA must verify if  the
>> address in IPv4 HAO match that in BCE in order to avoid MN
>> use a unauthorized IPv4 address.
>> 
>> In fact, since "the home agent MUST be able to find the IPv4
>> home address of a mobile node when given the IPv6 home
>> address", section 5.5, why IPv4 HAO must be include in
>> re-registration BU? I can't find any benefit.
>> 
>> I didn't find the description in 3775 for "a new BU
>> overwrites the old one".
>> It should be implementation issue.
>> It also could be done as that attributes in BCE also include
>> in re-registration BU should be overwriten and other
>> attribute not included in re-registration BU should remain valid.
>> 
>> De-registration for IPv4 HoA can be done by adding a bit in
>> IPv4 HAO option for indicating de-registration, or any other
>> ways. It is all ok.
>> I just think it is unnecessary that re-registration BU
>> include the IPv4 HAO.
>> :-)
>> 
>> 
>> 
>>>> 
>>>> 2. We can find many other ways to delete the IPv4 binding
>> if it is 
>>>> consensus that re-registration BU does not have to
>> include the IPv4
>>>> HAO. It could not be a resason for re-registration BU must
>>> including IPv4 HAO.
>>> 
>>> => Well, that's the reason now, if you have better ideas,
>> other than 
>>> designing a new option per extension please send them to the list.
>>> This is already a bit late given that I'm making the last
>> update for 
>>> IESG comments.
>>> 
>>> Hesham
>>> 
>>>> 
>>>>> 
>>>>> Hesham
>>>>> 
>>>>>>  
>>>>>> 
>>>>>> Regards,
>>>>>> Xiaoyan
>>>>> 
>>>> 
>>>> Regards,
>>>> Xiaoyan
>>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
> 


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext