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

[Ryuji Wakikawa <[e-mail]>]

Hi

At Wed, 17 Dec 2008 09:42:10 +1100,
Hesham Soliman wrote:
> 
> 
> 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. 

If you use the bulk registration, you only have one lifetime for every bindings.
in section 5.3
   "To use bulk registration, the mobile node includes a Binding
   Identifier Mobility option for each BID and Care-of address pair it
   wants to register in the same Binding Update message.  This is shown
   in Figure 7.  The rest of the fields and options in the Binding
   Update such as Lifetime, Sequence Number, and the flags in the
   Binding Update are common across all care-of addresses."


regards,
ryuji



> 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
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext