Subject: [MEXT] Comments on draft-ietf-monami6-multiplecoa-04.txt

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 21 Nov 2007 14:08:02 +0000

Hi all,

I reviewed draft-ietf-monami6-multiplecoa-04.txt so here are some comments:

1) BID name: Not sure if I am missing some history behind this but I am not
sure why BID does not simply mean "Binding ID" as opposed to "Binding Unique
ID". Could we drop the work "unique" from BID and the corresponding
sub-option?

2) BID uniqueness and scope: One needs to read almost the entire document
before he can figure out that the BID's scope of uniqueness is exactly. The
fact that a BID is unique to an HoA/CoA pair and the fact that the MN is
responsible for managing the BID number space should be made clear up front,
maybe as part of the BID definition in Section 2.

3) Bulk Registrations and CNs: It is not clear why bulk registrations are
not allowed for CNs. Is it so much more complex to handle bulk registrations
once that is defined for the HA and once the CNs handle MCoAs one at a time?

4) Deregistration/Returning_Home:These issues are described in Section 3
(protocol overview) and then more explicitly in other sections. I found the
text in Section 3 with respect to these issues confusing to say the least.
Maybe that text can be removed or re-written after the issues are resolved
sufficiently (see separate thread of discussion on that).

5) In the definition of Care of address (C) flag (section 4.2.1) a "must",
an "or", and a "MUST" are used in the same breath...please clean it up :-)

6) BID independence vs bulk registrations: It is hard to tell from the
current text to what extend BIDs are managed independently and how that is
affected by bulk registrations. In particular the discussion regarding
sequence numbers in Section 5.4 is confusing. According to 3775, Section
11.1, the MN is keeping just one entry in its Binding Update List for each
destination. If I understand correctly, with MCoAs, the MN needs to keep
multiple entries in that list, one per BID. It should be made clear whether
a separate sequence number space is required per BID or not. Separate space
per BID seems incompatible with the idea of sending bulk registrations, so I
would think that the same space should be used.

7) Interactions with DSMIPv6. I think at some point a new section needs to
be added to talk about interactions with DSMIPv6. Beyond the obvious issue
of whether MCoAs can include IPv4 CoAs etc the MCoA draft includes some
interactions with IKEv2 and imposes some requirements to the use of
alternate-CoA which may or may not conflict with DSMIPv6 (have not checked
that myself yet).

Regards
George
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 21 Nov 2007 15:25:35 -0800

George Tsirtsis wrote:

> 7) Interactions with DSMIPv6. I think at some point a new section needs 
> to be added to talk about interactions with DSMIPv6. Beyond the obvious 
> issue of whether MCoAs can include IPv4 CoAs etc the MCoA draft includes 
> some interactions with IKEv2 

I think the IKEv2 interactions are inline with what we decided for
DS-MIPv6 last week. Transport mode IPsec SA for the binding update,
and tunnel mode SAs updated either by MIPv6 (K flag) or running
IKEv2 again.

and imposes some requirements to the use of
> alternate-CoA which may or may not conflict with DSMIPv6 (have not 
> checked that myself yet).

In DS-MIPv6, the IPv4 CoA option is a new mobility option, not
related to the alt CoA option in RFC 3775.
draft-ietf-monami6-multiplecoa says the alt CoA option should not
be included whenever the CoA is carried in the BID mobility option.

The BID option as defined in the draft currently seems to allow
only for an IPv6 address. I think, we need to extend the BID option
to carry an IPv4 or an IPv6 address.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 25 Nov 2007 02:50:17 +0900

Hi George

thanks for your comments. Please find my reply inline.

On 2007/11/21, at 23:08, George Tsirtsis wrote:

> 1) BID name: Not sure if I am missing some history behind this but I  
> am not sure why BID does not simply mean "Binding ID" as opposed to  
> "Binding Unique ID". Could we drop the work "unique" from BID and  
> the corresponding sub-option?

I don't have much intention to the name.
We can change it if nobody complain :-)

> 2) BID uniqueness and scope: One needs to read almost the entire  
> document before he can figure out that the BID's scope of uniqueness  
> is exactly. The fact that a BID is unique to an HoA/CoA pair and the  
> fact that the MN is responsible for managing the BID number space  
> should be made clear up front, maybe as part of the BID definition  
> in Section 2.

OK

>
> 3) Bulk Registrations and CNs: It is not clear why bulk  
> registrations are not allowed for CNs. Is it so much more complex to  
> handle bulk registrations once that is defined for the HA and once  
> the CNs handle MCoAs one at a time?

This is just for simplicity. We had consensus for this.

> 4) Deregistration/Returning_Home:These issues are described in  
> Section 3 (protocol overview) and then more explicitly in other  
> sections. I found the text in Section 3 with respect to these issues  
> confusing to say the least. Maybe that text can be removed or re- 
> written after the issues are resolved sufficiently (see separate  
> thread of discussion on that).

We certainly have to update this part.
For this revision, I didn't update the returning home parts and  
waiting for consensus in WG.

> 5) In the definition of Care of address (C) flag (section 4.2.1) a  
> "must", an "or", and a "MUST" are used in the same breath...please  
> clean it up :-)
>
OK, I will fix this. thanks

> 6) BID independence vs bulk registrations: It is hard to tell from  
> the current text to what extend BIDs are managed independently and  
> how that is affected by bulk registrations. In particular the  
> discussion regarding sequence numbers in Section 5.4 is confusing.  
> According to 3775, Section 11.1, the MN is keeping just one entry in  
> its Binding Update List for each destination. If I understand  
> correctly, with MCoAs, the MN needs to keep multiple entries in that  
> list, one per BID.  It should be made clear whether a separate  
> sequence number space is required per BID or not. Separate space per  
> BID seems incompatible with the idea of sending bulk registrations,  
> so I would think that the same space should be used.

For bulk registration, the same space should be used, but not MUST.
This is because MN may switch to use bulk registration when the number  
of active CoAs gets larger.
In such case, MN should update the sequence number values of all the  
bindings to the reasonable number (which is the highest number of all  
the bindings within the sequence window).

thanks,
ryuji

>
> 7) Interactions with DSMIPv6. I think at some point a new section  
> needs to be added to talk about interactions with DSMIPv6. Beyond  
> the obvious issue of whether MCoAs can include IPv4 CoAs etc the  
> MCoA draft includes some interactions with IKEv2 and imposes some  
> requirements to the use of alternate-CoA which may or may not  
> conflict with DSMIPv6 (have not checked that myself yet).
>
> Regards
> George

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sun, 25 Nov 2007 02:53:02 +0900

Hi George and Vijay,

Question is whether we should support DSMIP in this document.
It seems reasonable to support DSMIP.
We can easily extend BID sub-option to cary both IPv4/IPv6 addresses.

regards,
ryuji

On 2007/11/22, at 8:25, Vijay Devarapalli wrote:

>> MCoA draft includes some interactions with IKEv2
>