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

From: George Tsirtsis <[email-masked]>
Date: Sat, 14 Mar 2009 15:42:11 +0000

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

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.
Section 5.6.3 kind of indicates what happens when 'H' is set but in an
almost icoherent manner. Information about it is then spread in
various places but in the end I have no clue when I should and should
not set this flag.

3) Relation with Flow Bindings draft
I think you should drop all references to Flow Bindings draft. The
only ones I can see are in section 5.6.3 amd 5.6.5. They both relate
to home registrations and I think the current text unnecessarily
implies that the only reason to have simultaneous home and foreign
link connectivity is because you are using Flow Bindings. IMO the
reasons to do that, are exactly the same with having multiple foreign
links, and since we do not require Flow Bindings for multiple
foreign links, we should not do so for home/foreign links either.

4) Section 5.2
"   For the multiple Care-of Addresses registration, the mobile node MUST
   include a Binding Identifier mobility option(s) in the Binding Update
   as shown in Figure 6.  The BID is copied from a corresponding binding
   update List entry to the BID field of the Binding Identifier mobility
   option."
This implies that the binding update list entry exists prior to
sending the BU. This is implementation issue and nothing to do with
the spec. So, the BID, does not have to be "copied" from anywhere in
particular. Please rephrase.

5) Section 5.2. and 5.3
The separate section on Bulk Registration is confusing. It implies
that this is some other procedure separate from normal registration.
In fact all it means is that the MN can include more than one Binding
Identifier option in the same BU. Figure 7 BTW, fails to illustrate
this, while the security description on 5.3 is a copy/paste from 5.2
and totaly pointless.
I would merge the two section or reduce 5.3 in a couple of sentences max!

6) Home registrations
This has been blown out of proportions in the draft. It is described
over 6-7 pages in section 5.5 and 5.6, which include multiple
subsections each. If you actually read all this you will realise it
says very little and repeats things often,

7) Treatment of AltCoAoption
In Section 5.2 it says: "
However, in this specification,
   the care-of address MUST be carried in the Care-of Address field of
   the Binding Identifier mobility option.  In order to save bits of the
   Binding Update, the alternate care-of address option MUST NOT be
   included."

Then in section 6.2:
"If the care-of address is present in both the alternate care-of
      address mobility option and the Binding Identifier mobility option
      at the same time, the home agent MUST ignore the alternate care-of
      address mobility option and continue processing the Binding Update
      with the care-of address from the Binding Identifier mobility
      option."

These are NOT compatible statements. If the MN MUST NOT send the
AltCoA option then it is not possible for the HA to just ignore it
when it is illegally present. I would change section 5.2 to a SHOULD
NOT.

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.

9) Binding Identifier Option without CoA field
It should be clearer when this is allowed and why. At the moment the
treatment of the CoA field is spread between section 4.2, 5.3. 5.6.4
and who knows where else.
I do not understand why section 4.2 allows the MCoA registration to
either use the CoA in the option or the CoA in the BU. Why having two
ways of doing things?
Instead it should be clear that in a BU the Binding Identifer option
without a CoA can only be sent in a BU refresh existing bindings. it
should also be clear whether one can mix binding identifier options
with and without CoAs in the same BU. The it should be clear that in
BAs the binding identifiers MUST NOT include CoAs.

George

2009/3/6  <[email-masked]>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.
>
>
>        Title           : Multiple Care-of Addresses Registration
>        Author(s)       : R. Wakikawa, et al.
>        Filename        : draft-ietf-monami6-multiplecoa-12.txt
>        Pages           : 46
>        Date            : 2009-03-06
>
> According to the current Mobile IPv6 specification, a mobile node may
> have several care-of addresses, but only one, called the primary
> care-of address, that can be registered with its home agent and the
> correspondent nodes.  However, for matters of cost, bandwidth, delay,
> etc, it is useful for the mobile node to get Internet access through
> multiple accesses simultaneously, in which case the mobile node would
> be configured with multiple active IPv6 care-of addresses.  This
> document proposes extensions to the Mobile IPv6 protocol to register
> and use multiple care-of addresses.  The extensions proposed in this
> document can be used by Mobile Routers using the NEMO (Network
> Mobility) Basic Support protocol as well.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-12.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

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

Hi George,

apologize my late response.
I am now in SF and can talk this during this week.

> - any other Binding Identifier mobility options registering CoAs on

Section 5.4 talks about general binding de-registration.
MN can removes a binding from either home or foreign link.

Section 5.5 is specific to "returning home" (i.e. removal from the home link).

> various places but in the end I have no clue when I should and should

If a MN sends a binding update including many BIDs which O bit is unset,
it is bulk registration's BU.
Alternatively, If a MN sends a binding update including a BID which O
bit is unset,
it is individual registration's BU.

> foreign links, we should not do so for home/foreign links either.

hmm, we tried to specify multiple CoA registration in general purpose
and avoid tying to any flow management scheme.

> particular. Please rephrase.

OK, This is minor change.

> I would merge the two section or reduce 5.3 in a couple of sentences max!

This is editorial changes. If there is no other comments, we can handle this.

> says very little and repeats things often,

There might be some overlapped, but each section talks about different
scenarios.
see my last sent email.

> when it is illegally present. I would change section 5.2 to a SHOULD

OK, this is minor change.

> ones. This is not stated anywhere as far as I can tell by the way.

We support MN switching from the MCoA binding mode to the RFC3775 binding mode.
Not the other way, from RFC-3775 to MCoA.

see my last sent email.

> either use the CoA in the option or the CoA in the BU. Why having two

CoA in the BU? DO you mean CoA in the IPv6 header of BU?

It's because we have two binding registration mode(separate or bulk).
In the separate BU registration, the COA field is just redundant,
since the COA is already there in the source address field.

> BAs the binding identifiers MUST NOT include CoAs.

In the bulk registaration, even for refreshment, CoA must be included
in CoA field of BID-option.

CoA can be omitted only in two cases.
- separate binding registration
- binding de-registration

regards,
ryuji