[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] De-resgistering bindings in MCoA draft

Hi Hesham,

I agree we need to clarify better how lifetime and multiple bindings are handled, considering also the interactions with flow bindings.

It's right that based on RFC 3775 one BU replaces the previous one, but we need to understand how this applies to multiple bindings. Saying that every BU replaces the previous one in this context implies that the MN needs to include at any BU all the BIDs (and if flow bindings are supported all the FIDs). This is not acceptable as it makes bulk registration mandatory and increases the signaling overhead to an unacceptable value.

The current solution in the draft works but there may be cleaner solutions. 

One cleaner solution would be to treat every BID as logically separate with its own lifetime. In this case if the BID is present in the BU the lifetime of the BU itself is ignored. This approach would keep the principle "one BID replaces the previous one" alive. It is still true that if a BU does not include any BID, then it replaces the entire HoA BCE (i.e. removing or updating all the BIDs). 

Another possibility is that we assume all BIDs have the same lifetime, which is the lifetime in the BU. However to remove a BID the MN explicitly indicates that with a flag in the BID option. This changes a bit the nature of the MIPv6 signaling.

I think the first approach seems the cleanest one. What do you think?

Cheers
Gerardo

> -----Original Message-----
> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On Behalf Of Hesham
> Soliman
> Sent: Tuesday, December 16, 2008 5:44 AM
> To: mext at ietf.org
> Subject: [MEXT] De-resgistering bindings in MCoA draft
> 
> Hi,
> 
> I have a comment on this aspect of the spec. The removal of BIDs based on
> zero lifetime is completely inconsistent with the processing of the BU in
> MIPv6. The lifetime should be for the entire binding cache for the home
> address. BIDs should be removed by explicitly by requesting a removal
> operation in the BID fields (or by simply excluding them from the new BU),
> not by giving them separate lifetimes. I don't see any reason for
> complicating things this way. This is not how a binding update is supposed
> to work. The way it works is that one BU replaces the previous one.
> 
> Hesham
> 
> 
> _______________________________________________
> 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