[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
On Mon, Mar 16, 2009 at 7:10 AM, Christian Kaas-Petersen
<kaaspetersen at yahoo.dk> wrote:
>
> 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.
> --- 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)
>
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?
> 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.
>
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.
>
>> 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.
>
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?
> Christian
>
>
>
>
> Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm
>