Re: [MEXT] IPv4 home address option in DSMIP

Gerardo

> -----Original Message-----
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham
> Soliman
> Sent: Thursday, January 22, 2009 8:18 PM
> To: Shi Xiaoyan
> Cc: mext@ietf.org
> Subject: Re: [MEXT] IPv4 home address option in DSMIP
> 
> 
> 
> 
> On 23/01/09 2:35 PM, "Shi Xiaoyan" <shi_xyan@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@ietf.org [mailto:mext-bounces@ietf.org] On
> >> Behalf Of Shi Xiaoyan
> >> Sent: Tuesday, January 20, 2009 6:06 PM
> >> To: 'Hesham Soliman'
> >> Cc: mext@ietf.org
> >> Subject: Re: [MEXT] IPv4 home address option in DSMIP
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Hesham Soliman [mailto:hesham@elevatemobile.com]
> >>> Sent: Monday, January 19, 2009 8:04 PM
> >>> To: Shi Xiaoyan
> >>> Cc: mext@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@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mext
> >
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext