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

[Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

Hi George,

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

2009/3/14 George Tsirtsis <tsirtsis at googlemail.com>:
> 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

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).

> 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.

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.


> 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.

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


> 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.

OK, This is minor change.

> 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!

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

> 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,

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

> 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.

OK, this is minor change.


> 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.

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.

> 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?

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.

> 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.

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



> George
>
>
> 2009/3/6  <Internet-Drafts at ietf.org>:
>> 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
>> MEXT at ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
>>
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>