Re: [MEXT] IPv4 home address option in DSMIP

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 ----- 
  From: Giaretta, Gerardo 
  To: Hesham Soliman ; Shi Xiaoyan 
  Cc: mext@ietf.org 
  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@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