Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

["Giaretta, Gerardo" <[e-mail]>]

Hi Ryuji,

one point related to Christian's comments is that we need a BID also for the interface which is on the home link. This is needed in order to associate FIDs to that interface. The rules to create/update/delete that BID should be the same as for any other binding

Gerardo

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Ryuji Wakikawa [[e-mail]]
Sent: Tuesday, December 16, 2008 10:27 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some    comments

Hi Christian,

thanks for comments.

At Thu, 11 Dec 2008 15:08:16 +0100,
<[e-mail]> wrote:
>
> Assume a mobile node with home address HoA has two interfaces,
> both attached to foreign links.  After exchange of binding update
> and binding acknowledgement, the home agent's binding cache (at
> least the snip of it related to HoA) will look like this
>
>     HoA, BID= 7, CoA1, other parameters like period of validity...
>     HoA, BID=10, CoA2, other parameters ...
>
> The draft uses HoA=2001:db8::EUI.
>
> Draft 10, section 5.1 states, that a BID value must be unique for a
> home address and care-of address pair.  This is satisfied above, but
> it means, that the mobile station is not allowed to change the
> second entry such that it also uses CoA1 as care-of address.
>
> Proposal:  I think it has merit to be able to allow more than
> one BID value per pair of home address and care-of address.  Consider
> flow bindings (defined in draft-ietf-mext-flow-binding) where
> a flow may refer to a BID, and thus there is a simple way to move
> flows between interfaces: only updating the binding cache.


Do you want these bindings?
     HoA, BID= 7, CoA1, other parameters like period of validity...
     HoA, BID=10, CoA1, other parameters ...

>From the protocol operational view, we don't have any issue to relax
the BID assignment for this purpose.

> Draft 10, section 4.2 (and other places) defines the H flag, which when
> set means the mobile node wants to use both its home link and one or
> more of its foreign links.  The H flag is really an instruction to the
> home agent, that in addition to all the bidings currently defined
> is shall have an extra binding where packets shall not be tunneled.
>
> Proposal:  The mobile node should be able to define a binding saying
>
>     HoA BID=0 HoA
>
> This is a kind of default binding to be used when any of the other HoA-
> bindings cannot be used.  I think the H flag is an indirect way of
> saying there is an extra binding, whereas the binding above is direct.
> It also avoids continuously setting the H flag when both home link
> and foreign links are active.

This was originally proposed by Keigo from Panasonic and has been discussed it.
You can check the discussion on ML archives.

>
> Other comments
>
>  o Figure 1: In general I think it simpler for human readers to have
>    the elements of the primary key to a database given first,
>    therefore I suggest
>
>        binding [2001:db8::EUI  BID1  care-of address1]
>
>    to be used allover.

OK, will fix this.

>
>  o Figure 4: looks as if position 6 is followed by position 17.

this is typo. i'll fix this.

>  o Section 4.2, O flag.  The O flag is carried in an Binding
>    Identification mobility option, but really it a kind of global
>    value to be understood by the receiver as "clean all HoA entries".
>    If it really is too much to introduce a new mobility option,
>    isn't it enough to set the O flag in the first Binding
>    Identification mobility option?

I'm updating the document after last call. the O flag is now defined
in the BU itself, since this is global value for all bindings as you pointedout.

>  o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2.
>    If the care-of address is omitted, the care-of address is to be
>    taken from the source address of the IPv6 header.
>    When the binding update arrives at the home agent, the
>    IPv6 header's source address is exactly the care-of
>    address used by the mobile node, but when the home agent is
>    actually able to understand the contents of the binding update,
>    then the IPv6 headers source address has been swapped with the
>    address found in the Destination Option extension header,
>    and thus the care-of address is now found in the Destination
>    Option extension header.

In section 6.1.7 of RFc3775, it said
  "The care-of address is specified either by the Source Address field
   in the IPv6 header or by the Alternate Care-of Address option, if
   present. "

So, I will fix this to

the care-of address is to be taken from the source address of the IPv6 header "of the Binding Update".


 >  o Section 5.6.2, bullet 2.  The term link-local address is used, but I
>    think this should be changed to be like in all the other places,
>    using link-layer address.

yes, thanks.

>  o Section 6.2, bullet 7, sub-bullet 1: I think the condition should
> read
>    "If one of the 'O' flags is set, then all of the 'O' flags must be
>    set, else [MCOA MALFORMED] is returned."  But as suggested above,
>    I don't think there is reason to enforce an all-or-none 'O' flags.

right, see above.

>  o Section 8.2, para 2.  The text says, that the IPv4 Address
>    Acknowledgement mobility option is included only if the mobile node
>    requested a home address.  When I read
> draft-ietf-mext-nemo-v4traversal,
>    section 4.2.1, the IPv4 Address Acknowledgement mobility option
>    is included always, indicating the home agent created a binding cache
>    entry for the IPv4 home address.

correct. I will check dsmip and update it.

thanks
ryuji


> Christian
>
>
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext