Re: [MEXT] IPv4 home address option in DSMIP

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. 

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