Re: [MEXT] Comment on DSMIP draft 7

On 17/12/08 10:05 PM, "Christian.Kaas-Petersen@tieto.com"
<Christian.Kaas-Petersen@tieto.com> wrote:

> 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,

=> 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.

> 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.

=> 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.

> 
> 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.

=> 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.

> 
>  * "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)

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

> 
> 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.

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

Hesham

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext