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

From: Christian Kaas-Petersen <[email-masked]>
Date: Mon, 16 Mar 2009 11:10:11 +0000 (GMT)

To me, the MCoA draft is OK some of the places mentioned.  See inline.

--- Den lør 14/3/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
> Til: "mext" <[email-masked]>, "Jari Arkko" <[email-masked]>
> Dato: lørdag 14. marts 2009 16.42
> I was reading the document again in
> order to review the Flow Bindings
> draft but I found that the MCoA draft is confusing and
> incomplete in a
> number of places.
> 
> The following are issues that came up after a review of
> sections 1- 6.
> I have not yet reviewed sections 7 to 11.
> 
> 1) Binding De-registrations
> I think the descriptions of 5.4, 5.5., 5.6., are terribly
> confused,
> WRT what a normal MCoA registration is, vs what a home
> binding MCoA
> registration is, and how they relate to
> 3775-de-registration.
> a) I think we have to make clear that Binding
> De-registrations as
> described in RFC3775 are still valid and have exactly the
> same effect
> when MCoA is used i.e., removes all bindings from the HA
> and all
> packets flow to the MN via the home link
> b) If the MN wants to use simultaneous home and foreign
> links it MUST
> NOT send an RFC3775 style  deregistration. Instead it
> SHOULD send an
> MCoA registration with:
>  - A non-zero lifetime
>  - a Binding Identifier mobility option, including
>         *  'H' flag set to "1",
>         *  BID field set to a
> value used for the home link,
>         * CoA field set to the home
> address
> - any other Binding Identifier mobility options registering
> CoAs on
> foreign links
> 

Example: The mobile node is away, and has the two registrations in
the home agent's binding cache

    v6HoA BID1 -> v6CoA1
    v6HoA BID2 -> v6CoA2

The interface known as BID2 attaches to the home link, and the mobile node
wants to continue using both interfaces.  The mobile node could send
a binding update

    BU
        lifetime = 0
        BID-option: BID2, H-bit=1 (no care-of address should be given)

When flow binding in not used, it is not required to know the
BID-value found on the home link.  When at a later time the mobile node
refreshes the binding cache, it will send

    BU
        lifetime > 0
        BID-option: BID1, H-bit=1, v6CoA1

> 2) Use of 'O' and 'H' flag
> Section 5.2 indicates what happens when 'O' is set. This is
> then IMO
> redundantly repeated in many other places, but I can not
> find anywhere
> what happens when 'O' is not set.

To me, the MCoA draft describes how binding updates manipulate
individual BID-entries in the binding cache.  Thus the normal
way of operation is O-bit=0.  The O-bit=1 is used, when the
individual manipulations are more efficiently described by a
"clear all, insert what is sent here".  So to me the O-bit=0 is
the default way of working.  Thus only the O-bit=1 should be
explained as far as how it differs from the default way.

> 8) in section 6.2:
> "  o  If the 'O' flag is set in the
> de-registering Binding Update, it is
>       ignored.  If the 'H' flag is set,
> the home agent stores a home
>       address in the Care-of Address field
> of the binding cache entry.
>       The home agent MUST follow the
> descriptions described in
>       Section 5.6."
> 
> The O flag is described also in another bullets further
> down. The O
> flag description in this own is out of place and the text
> should be
> moved with the other two bullets.
> 
> One of these two bullets about "O" flag say:
>       *  If the 'O' flag is unset in
> the Binding Update and the receiver
>          has a regular
> binding which does not have BID for the mobile
>          node, it must not
> process the Binding Update.  The receiver
>          should sent a
> Binding Acknowledgement with status set to [MCOA
>          BID CONFLICT]."
> 
> This does not even make ;logical sense. When O is not set
> then then
> whatever bindings included in the BU must be added to the
> existing
> ones. This is not stated anywhere as far as I can tell by
> the way.

I do think it makes logical sense.  The context is, that the
"receiveer has a regular binding" in the style of RFC3775, 
for example

    v6HoA -> v6CoA

and the home agent now receives a binding update 

    BU
        lifetime > 0
        O-bit=0
        BID-option: BID2, v6CoA2

Because O-bit=0 this is to be treated as an addition.  But as
no BID-value is associated with the existing entry, the addition
is not of the same format as the existing entry, therefore the
rejection in the binding acknowledgement.  In general, either
the binding cache has one entry like

    v6HoA -> v6CoA

or a number of entries in the format

    v6HoA, BID-value -> v6CoA

but not a mix of the two.

Christian

      Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 16 Mar 2009 10:46:52 -0400

> To me, the MCoA draft is OK some of the places mentioned.  See inline.

GT> So on the issues you did not comment on below, you agree with me?
See some answers below.

>        BID-option: BID2, H-bit=1 (no care-of address should be given)

GT> It is not exactly clear to me what you disagree on exactly from my
comment above. I am not sure where the draft allows the above though
(maybe I am missing something?). A BU with Lifetime=0 is a
de-registration BU and it simply removes BID2 from the binding list.
According to the current draft the MN also needs to register CoA=HoA
in another BID i.e.:
BU
  lifetime >0
  O=0
 BID-option: BID3, CoA field=v6HoA, and H=1

What is not so clear is whether both of the above can be done at the
same time:e.g.,

BU
  lifetime >0
  O=1
 BID-option: BID3, CoA field=v6HoA, and H=1
 BID-option: BID1, CoA field=v6CoA, and H=1

Does H flag matter in this case?

> explained as far as how it differs from the default way.

GT> Not sure what you mean. There is nothing "normal" about the
operation with O=0. Since O flag is a new flag defined in MCoA, its
operation when set to 0 and 1 must be fully defined.

> but not a mix of the two.

GT> I agree. But I am not understanding that from the original text.
Where is the statement that says that once MCoA extensions are used
ALL BCEs MUST include a BID, and this is why in this case the BU must
be rejected?. Why does the text have to be that cryptic?

---

From: Benjamin Lim <[email-masked]>
Date: Tue, 17 Mar 2009 10:19:13 +0800

Hi George, Christian,

Pls see inline for my comment/question.
>>        BID-option: BID2, H-bit=1 (no care-of address should be given)
[Ben] If you send a BU this way, what would be the lifetime of the home
binding?

>  BID-option: BID3, CoA field=v6HoA, and H=1
[Ben] I think it also possible to treat such home registration as an
update of an address in the HA's BCE and hence use back BID2.  Pls see
below for example.

HA's BCE

HoA -> BID1 -> CoA1 (this is MN's IF1)
HoA -> BID2 -> CoA2 (this is MN's IF2)

When MN's IF2 returns home, MN can send a BU1 from IF2 to register the
home binding

BU1 from MN's IF2 when return home
Scr     : HoA
Lifetime: >0
BID Opt : BID2, H=1

The reason why I left out the CoA field in the BID is that from what I
understand, if the CoA field is empty, the HA would take the address
from the source address of the BU for registration.  This is mention in
Section 4.3 under the CoA field.

"...If no address is specified in this field, a care-of address is taken
from the source address field of the IPv6 header of the Binding Update..."

Regards,
Benjamin Lim

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext