|
Maybe rfc3775bisxxx need state the explicit
action of HA 'how to do when a mobility option is
(not) carried within the lifetime extension re-registration (BU)'.
Then, new MO in the subsequent draft could make consistent.
B.R.
Yungui
----- Original Message -----
Sent: Saturday, January 24, 2009 12:27
AM
Subject: Re: [MEXT] IPv4 home address
option in DSMIP
I agree with Hesham on this.
Gerardo
>
-----Original Message-----
> From: mext-bounces at ietf.org
[mailto:mext-bounces at ietf.org] On Behalf Of Hesham
> Soliman
>
Sent: Thursday, January 22, 2009 8:18 PM
> To: Shi Xiaoyan
> Cc:
mext at ietf.org
> Subject: Re: [MEXT]
IPv4 home address option in DSMIP
>
>
>
>
>
On 23/01/09 2:35 PM, "Shi Xiaoyan" <shi_xyan at huawei.com> wrote:
>
> > 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: mext-bounces at ietf.org
[mailto:mext-bounces at ietf.org] On
> >> Behalf Of Shi
Xiaoyan
> >> Sent: Tuesday, January 20, 2009 6:06 PM
>
>> To: 'Hesham Soliman'
> >> Cc: mext at ietf.org
> >> Subject: Re:
[MEXT] IPv4 home address option in DSMIP
> >>
>
>>
> >>
> >>> -----Original
Message-----
> >>> From: Hesham Soliman
[mailto:hesham at elevatemobile.com]
> >>> Sent: Monday, January
19, 2009 8:04 PM
> >>> To: Shi Xiaoyan
> >>> Cc:
mext at ietf.org
> >>> 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
> >> MEXT at ietf.org
>
>> https://www.ietf.org/mailman/listinfo/mext
>
>
>
>
>
_______________________________________________
> MEXT mailing
list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT
mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
|