Subject: [MEXT] De-registration Re: Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt

From: George Tsirtsis <[email-masked]>
Date: Mon, 23 Mar 2009 18:40:56 -0700

Are you saying that there are 6(!) ways of performing a
de-registration according to the draft?
And why would you include "flow binding specific" ways of doing this?

George

On Mon, Mar 23, 2009 at 4:35 AM, Ryuji Wakikawa
<[email-masked]> wrote:
> Hi George, Christian, Benjamin, and all,
>
> Let me first reply you the confusion of the binding de-registration operation.
>
> In the MCoA doc, there are several scenarios of binding de-registrations.
> I tried to summarize how MCoA document expects to be in each scenario.
> Hope this clarify your concerns.
>
> The mobile node is away, and has the three registrations in the home
> agent's binding cache
>   v6HoA BID1 -> v6CoA1
>   v6HoA BID2 -> v6CoA2
>   v6HoA BID3 -> v6CoA3
>
> 1. Removing a binding from a foreign link
> MN removes a binding (BID2) from the foreign link
> + sending de-registration BU from the foreign link
>   - lifetime=0
>   - BID-option: BID2, No-flag (no care-of address should be given)
>
> 2. Returning home completely. (Same as RFC3775)
> MN uses the interface attached to the home link only.
> + sending de-registration BU from the home link
>   The de-registration BU is same as RFC3775's one.
>   - lifetime = 0
>   - No BID-options (no care-of address should be given)
>
> 3. Use the simultaneous home and foreign link (Normal MCoA behavior)
> MN returns home with the interface (BID2) and continues using both interfaces.
> + sending de-registration BU from the home link
>   - lifetime = 0
>   - BID-option: BID2, H-bit=1 (no care-of address should be given)
>   - the Mobility Header Link-layer Address Option
>
> 4. Use the simultaneous home and foreign link (Flow binding specific behavior)
> Two approaches to create a home binding.
>
> (1) sending BU from the home link
>     - lifetime > 0
>     - BID-option: BID2, H-bit=1 (no care-of address should be given)
> or
> (2) sending bulk-BU from the foreign link
>     - lifetime > 0
>     - BID-option:
>       BID1, H-bit=1,  (CoA is given)
>       BID2, H-bit=1,  (HoA is given as a CoA)
>       BID3, H-bit=1,  (CoA is given)
>
> 5. Removing multiple bindings at once (Replacements)
> MN removes multiple binding  (BID2,3) registered for the home address
> with the new ones (ex. BID1).
> + sending registration BU from foreign link
>   - lifetime > 0
>   - BID-option:  BID1, O-bit=1,  (CoA is given)
> # Note1: O-bit is originally introduced for bootstrapping operation,
> # but it can be used for multiple binding de-registrations.
> # Note2: Bulk-BU has similar feature, but it only does add-on.
> # Bulk-BU cannot be used for replacement or multiple binding removal.
>
> 6. Giving up using MCoA
> MN wants to use the RFC-3775 binding instead of MCoA binding.
> + sending registration BU from foreign link
>   - lifetime > 0
>   - No BID-option
> #Note1:  if MN sends BU (lifetime > 0, BID-option: BID1, O-flag, CoA),
> #HA creates one binding but with the BID assignment.
> #Note2: if MN wants to switch from RFC-3775 binding to MCoA binding,
> # it MUST de-register RFC-3775 binding first and then start
> registering MCOA bindings.
>
> regards,
> ryuji
>
>
>
>
>
> 2009/3/18 Benjamin Lim <[email-masked]>:
>> Hi Christian,
>>
>> You are right.  I forgot to consider the case where HA is not the
>> default router.  The HA would be the one to decide to do ND-proxy or not
>> based on the topology.
>>
>> Regards,
>> Benjamin Lim
>>
>> Christian Kaas-Petersen wrote:
>>> The H-bit=1 is not used to turn off neighbor discovery at HA.
>>>
>>> The H-bit=1 is used by the mobile node to tell the home agent
>>> it has simultaneous connectivity on home link and one or more
>>> foreign links.  Then the home agent decides who should do neighbor
>>> discovery on the home link (depending on whether
>>> the home agent is the only router on the home link, ie topology a
>>> of Figure 3, or there are other routers on the home link, ie topology b
>>> of Figure 3), and the home agent reports its decision in the status
>>> value of the binding acknowledgement.  In topology a the mobile node
>>> will do neighbor discovery; in topology b the home agent will continue
>>> doing neighbor discovery.
>>>
>>> Christian
>>>
>>> --- Den ons 18/3/09 skrev Benjamin Lim <[email-masked]>:
>>>
>>>> Fra: Benjamin Lim <[email-masked]>
>>>> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
>>>> Til: "Christian Kaas-Petersen" <[email-masked]>
>>>> Cc: "George Tsirtsis" <[email-masked]>, "mext" <[email-masked]>
>>>> Dato: onsdag 18. marts 2009 08.17
>>>> Hi Christian, all,
>>>>
>>>> Pls see inline for some of my comments.
>>>>
>>>> Christian Kaas-Petersen wrote:
>>>>> The packets I proposed I get from draft 12, section
>>>> 5.4 second paragraph
>>>>> (which details a de-registration with lifetime=0 and
>>>> absence of
>>>>> care-of address) and section 5.6.3 bullets number 1
>>>> and 2 (which detail
>>>>> the presence of the H-bit and the absence of the
>>>> care-of address).
>>>>> To me, there is no need to register a binding where
>>>> CoA=HoA (use of
>>>>> home link), unless flow binding is used.
>>>> [Ben] Agree, being simultaneous connected on a home link
>>>> and foreign
>>>> link does not imply that flow binding must be used.
>>>>
>>>> For example, MN wants to receive packets from devices on
>>>> MN's home link
>>>> through MN's home attached interface.  Rather than
>>>> having those devices
>>>> send the packet to HA who will then forward it to MN's
>>>> foreign attached
>>>> interface, MN uses the 'H' flag to turn off ND-proxy at HA
>>>> and advertise
>>>> MN's home attached interface.  This way, devices in
>>>> the home link will
>>>> send packets to MN's home attached interface.  On the
>>>> other hand, any
>>>> packets not from the home link (e.g. from the global
>>>> Internet) will
>>>> arrive at HA, who in turn forward it to MN's foreign
>>>> attached interface.
>>>>
>>>
>>>
>>>
>>>       Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm
>>>
>>>
>>
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 23 Mar 2009 19:00:04 -0700

Hi George,

> de-registration according to the draft?

We only have one way in general to complete binding de-registration.
The basic semantics of de-registration is setting lifetime to zero.  
This is default behavior of MCoA. (scenario 1. 2. 3.).
The simultaneous home/foreign scenario with flow binding support is  
optional (special) behavior of MCoA. (senario4)
Other two ways (5 and 6) are not binding deregistration, but it can  
delete bindings as a result of operations.

> And why would you include "flow binding specific" ways of doing this?

This was asked by WG.

regards,
ryuji

>>>> --- Den ons 18/3/09 skrev Benjamin Lim <[email-masked] 
>>>> >:
>>>>
>>>>> Cc: "George Tsirtsis" <[email-masked]>, "mext" <[email-masked] 
>>>>> >