[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
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 <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
>
>