Subject: [MEXT] Comment on DSMIP draft 7

From: <[email-masked]>
Date: Wed, 17 Dec 2008 12:05:36 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 18 Dec 2008 00:57:10 +1100

> agent has in its binding cache one entry per home address,

=> I think the words after "thus" are not really a consequence of the
sentence you quote. Those are two separate issues, one is about the BU
operation and another is about the number of entries for each home address.

> mobile node with that home address.

=> Yes but the BCE is a conceptual entity described in RFC 3775. How it gets
implemented is a different story. Following that conceptual entity's
description in 3775, DSMIPv6 describes how the same concepts can apply.

> may store an IPv4 home address as an additional piece of information.

=> There are two logical bindings, which can be implemented as two linked
entries, or one hierarchical entry, it's the same thing. As I said above,
the logical contruct is based on how 3775 decribes the binding cache.

>     one for each home address." (section 5.5)

=> We've discussed this before in the DT for many weeks. I think we
shouldn't change this now.

> should speak of one entry.

=> Why should it speak of one entry when there are two home addresses?
Please see above.

Hesham