[MEXT] Comment on DSMIP draft 7

[<[e-mail]>]

Hi Hesham

In another mail (commenting on the home binding as specified in
MCoA draft) you have the sentence: "The way it [a binding update]
works is that one BU replaces the previous one."  Thus the home
agent has in its binding cache one entry per home address,
more specifically per IPv6 home address, and that entry is to be
updated in toto when receiving a new binding update sent from the
mobile node with that home address.  

This is certainly how the binding updates of DSMIP are supposed to
work.  When describing this way of working, I'll suggest the 
following wording from the DSMIP draft 7 edited.  
The quotes give the impression that the home
agent handles two bindings, one for the IPv6 home address and another
for the IPv4 home address, but really there is just one binding
using the IPv6 home address as the key to entry, and that entry
may store an IPv4 home address as an additional piece of information.

 * "create a binding cache entry for each address" (section 3.3)

 * "the home agent creates two binding cache entries, one
    for the mobile node's IPv4 home address, and another
    for the mobile node's IPv6 care-of address" (section 3.3.1)

 * "both entries will point to the" (section 3.3.1)

 * "creating the corresponding binding cache entries" (section 3.3.1)

 * "If an IPv4 home address option were included, the home agent
    MUST create another entry for that address." (section 3.3.2.1)

 * "All entries MUST point to the mobile node's IPv4 care-of address."
   (section 3.3.2.1 and 3.3.2.2)

 * "After accepting the binding updates and creating the corresponding
    entries" (section 3.3.2.2)

 * "Upon receiving this binding update, the home agent will replace the
    existing cache entries with the content of the new message"
    (section 5.4.2.1)

 * "If the binding update is accepted for both IPv4 and IPv6 home
    addresses, the home agent creates separate binding cache entries,
    one for each home address." (section 5.5)

Also, the binding cache is a logical entity which can be implemented
any way consistent with external behavior, so in practice in 
an implementation there could be two entries, but the specification
should speak of one entry.

It may be considered, whether also the binding update list 
really is best thought of as having one entry, for example the
following quote

 * "If the mobility header includes an IPv4 address acknowledgement
    option indicating success, the mobile node should create two
    entries in its binding update list, one for the IPv6 home address
    and another for the IPv4 home address" (section 5.4.2)

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