[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
To me, the MCoA draft is OK some of the places mentioned. See inline.
--- Den lør 14/3/09 skrev George Tsirtsis <tsirtsis at googlemail.com>:
> Fra: George Tsirtsis <tsirtsis at googlemail.com>
> Emne: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
> Til: "mext" <mext at ietf.org>, "Jari Arkko" <jari.arkko at piuha.net>
> 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