Subject: Re: [Monami6] (Issue-1 MCoA) Changing Semantics of Bulk Registration

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 4 Dec 2006 23:33:38 +0900

Hello Romain

On 2006/11/29, at 13:15, Romain KUNTZ wrote:

> Hi Ryuji,
>
> The proposition is still quite unclear for me, comments below.
>
> RYUJI WAKIKAWA wrote:
>> - (Propose)
>>    Bulk Registration
>>       A mobile node can register all the active bindings at a time by
>>       sending a binding update.  All the active care-of addresses  
>> must
>>       be stored in a Binding Update.  The bulk registration is
>>       supported only for home registration.  Note that a mobile node
>>       should not try to perform bulk registration with Correspondent
>>       Nodes.  The receiver of this binding update, it replaces all  
>> the
>>       bindings to the received bindings.
>
> I guess this means that bindings not updated by the BU must be  
> removed? It should be explicitely said in the text:

Yes, if BU is for bulk registration mode.

>
> "The receiver of the bulk registration BU must replace all the  
> bindings for the HoA and BID specified in the BU to the received  
> bindings, and remove all the other ones that are not updated by the  
> BU for this specific HoA."

right.

>>     * NO need to store removed CoAs with the removable flag in a BU,
>>       but always store all the active CoAs.
> >
>> * pros & cons
>> When a mobile node reboots and forgets the BIDs it had, it has to  
>> send
>> a legacy BU first to make sure all binding entries are deleted.
>> Otherwise, the garbage bindings may be left on the HA.  Ideally, the
>> MN should verify whether the HA keeps garbage bindings or not, by
>> sending a legacy BU. This may be redundant operation in the most of
>> scenarios.
>> With the proposed semantics, the MN sends only a BU in the bulk
>> registration mode, though the MN MUST always use the bulk  
>> registration
>> for its first registration to its HA.
>
> This "MUST use the bulk registration" should appear in the text  
> above. But if the multihomed MN wants to register only one CoA/BID  
> at startup (because another interfaces are not ready yet), what  
> should be its behaviour? Use the Bulk BU with bulk reg. flag, but  
> only with one CoA in it?

Yes.

>> On the other hand, there is undesirable scenario that MN wants to
>> update only two CoA when ten CoAs are available.  The 8 CoAs are
>> redundant for MN and HA.  It consumes bits on the air and causes
>> additional processing overhead to MN and HA.  Therefore, Jari propose
>> "Add-on Flag" for bulk registration.  If this Add-on flag is set, HA
>> adds the received CoAs in HA's binding cache database.  This flag
>> isn't so important since MN can send two non-bulk BUs for the two new
>> CoAs. There is also similar scenario when two binding needs to be
>> deleted when 10 bindings are active.  In this case, 8 active CoAs are
>> redundant.  Thus, tMN can sends two non-bulk de-registration BUs for
>> the two CoAs instead of using the bulk registration.
>
> But the text above states that "The bulk registration is supported  
> only for home registration", so when the MN wants to update/delete  
> two CoAs over 10, it has to use legacy BUs, right?

yes. MN must sends two regular BUs with MCoA sub-option.

> Another observation: when I usually use a MN/MR with multiple  
> interfaces, all the interfaces are never configured and ready-to- 
> use at the same time at the booting time. And introducing some  
> mechanisms in the implementation to wait for all the interfaces to  
> be up and configured is too complex and useless IMHO. So I would  
> personally implement a MN that sends a BU with a single CoA/BID  
> each time an interface is ready to be registered.

This is one way to implement.

>
> To summarize my point, is Bulk BU at booting time really useful? I  
> think BULK BU may be more interesting when the MN wants to update  
> several CoAs, after the booting time (to refresh the lifetime for  
> example, or de-registrate several CoAs at the same time, for  
> example when the MN returns home). But this is forbidden by your  
> proposal ("The bulk registration is supported only for home  
> registration"

The purpose of BULK BU at booting time is to make sure that HA does  
not have any old invalid bindings.

>> * Conclusion. (PENDING)
>> 1. (REJECTED) Keep the current semantics and Removable flag
>> 2. (ACCEPTED) Change the semantics, but  no add-on flag
>> 3. (ACCEPTED) Change the semantics and define add-on flag, too.
>> 4. !?
>
> 4. rejected and new proposal:
>
> [sorry if it has already been discussed before, looks like I missed  
> the discussion]:
>
> - either do not use bulk registration and keep the draft as it was  
> initially (ie always use usual BU). If the point is the garbage  
> bindings on the HA on reboot, then we can certainly do something  
> with the home registration flag when the HA receives a new home  
> registration BU from a MN.

I think there were enough voice to support BULK registration only for  
home registration.

> - or use bulk registration for home registration and/or to update/ 
> delete CoAs, but with no obligations, and only CoAs in the bulk-bu  
> are treated, other CoAs (the one not in the BU) not being touched  
> nor deleted.

OK, it means the option-1.

> Regards,
>
> -- 
> Romain KUNTZ
> [email-masked]
>
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 14 Dec 2006 23:16:48 +0900

Hi Ryuji,

RYUJI WAKIKAWA wrote:
>> - or use bulk registration for home registration and/or to 
>> update/delete CoAs, but with no obligations, and only CoAs in the 
>> bulk-bu are treated, other CoAs (the one not in the BU) not being 
>> touched nor deleted.
> 

Not exactly. If I have to choose strictly among option 1/2/3, and if
Bulk reg. cannot be used for other purpose than Home Registration, I
would then choose option 2:

regards,

-- 
Romain KUNTZ
[email-masked]

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 14 Dec 2006 23:16:48 +0900

Hi Ryuji,

regards,

-- 
Romain KUNTZ
[email-masked]