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

[Ryuji Wakikawa <[e-mail]>]

Hi Gerardo,

At Thu, 11 Dec 2008 09:05:21 -0800,
Giaretta, Gerardo wrote:
> 
> 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.

it is allowed, though this is not clear from the current spec. 
Christian's point is whether we allow multiple bindings (BID) which HoA and CoA are same. 

regards,
ryuji


> 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
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext