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

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

Hi Christian,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, December 11, 2008 6:08 AM
> To: [e-mail]
> Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 
> 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.
> 

I guess you mean only updating the CoA of the BCE/BID. I think this is a very valid point and it should be allowed. I did not realize this was not possible while reading the draft. I agree this is a necessary feature when coupling MCoA with flow bindings.

Thanks
Gerardo

> 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.
> 
> 
> 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.
> 
>  o Figure 4: looks as if position 6 is followed by position 17.
> 
>  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?
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
> 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