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

[Hesham Soliman <[e-mail]>]

Hi Gerardo,

> 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.

=> That's why the FIDs are not included in full for refreshes or deletes. We
only send the index. I understand your reasoning, but I think in practice
there will rarely be a case where you have more than 2, or max 3 BIDs. So,
it's hardly going to be overloading the LTE links. Anyway, assuming that
this is an issue, please see my suggestion below.

> 
> 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.

=> Not sure how the second approach works to avoid sending all BIDs.
There is a simple way to address this I think. All BIDs have the BU's
lifetime (which is how it should work).
You send a list of BIDs that need to be refreshed in each BU. Just the
numbers for the BIDs themselves. If a number is not in the list then it is
effectively removed.
The list is essentially a compression mechanism for the BID option. You only
need to send the full option if you're changing some of the option's
attributes. 


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

=> I don't like having different lifetimes for the same HoA bindings. It
makes life unnecessarily complex. I can't find any scenario where the MN
will want to explicitly have different lifetimes for different flow bindings
or CoA bindings. 

Hesham


> 
> Cheers
> Gerardo
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Hesham
>> Soliman
>> Sent: Tuesday, December 16, 2008 5:44 AM
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext