Subject: [netext] Comments on draft-zhou-netext-pd-pmip-01.txt

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 21 Jul 2011 20:14:16 +0900

Hi Carl and Zhou,

I think this is interesting work clarifying how to make the mobile
router work in PMIPv6 domain. I, however, have a couple of comments on
this I-D:

(1) In Section 3.3.1, at step 1, a PMIPv6 tunnel is established before
PBU/PBA at steps 3 and 4. On the other hand, after steps 3 and 4, no
PMIPv6 tunnel appears to be established. In this specification, two
PBU/PBA exchanges happen or only once?

(2) In Section 3.4.1,

  "In order to support this specification, the conceptual Binding Cache
   entry data structure needs to be extended..."

I think it's "Binding Update List entry" not "Binding Cache entry" here

(3) In Section 3.5.2, it is said,

     "In order to receive those packets, the
      mobile access gateway MUST advertise a connected route into the
      Routing Infrastructure for the mobile router's mobile network
      prefix(es)"

I think it's the local mobility anchor not the mobile access gateway to
do this in this context.

Hope my comments will help improve the document.

Regards,
-- 
Hidetoshi

---

From: [email-masked]
Date: Fri, 22 Jul 2011 10:45:50 +0800

Hi Hidetoshi,
Many thanks for your comments. Please see inline below.

> PBU/PBA exchanges happen or only once?
[Zhou]Actually this specification assumes that the DHCPv6 prefix 
delegation is running on the user plane of the PMIPv6. The PBU/PBA in step 
3 and 4 are what extension this spec does to PMIPv6. I will revise this 
Fig by keeping the PMIPv6 tunnel appearing in step 5, 6, 9 and 11 in the 
next version to avoid possible confusion as you mentioned.

> I think it's "Binding Update List entry" not "Binding Cache entry" here
[Zhou]The Binding Update List entry is for the MAG while the Binding Cache 
entry is for the LMA as defined in RFC5213.

> I think it's the local mobility anchor not the mobile access gateway to
[Zhou]Yes, you are right. I will correct it.

> Hope my comments will help improve the document.

Regards,
Joy Zhou
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 24 Jul 2011 09:06:08 +0900

Hi Zhou,

Thanks for your response. Please see inline:

(2011/07/22 11:45), [email-masked] wrote:
> delegation is running on the user plane of the PMIPv6. The PBU/PBA in 
> step 3 and 4 are what extension this spec does to PMIPv6. I will revise 
> this Fig by keeping the PMIPv6 tunnel appearing in step 5, 6, 9 and 11 
> in the next version to avoid possible confusion as you mentioned.

Ok. Basically, there are two PBU/PBA exchanges in this spec; one for the
PMIPv6 tunnel shown at step 1 and the other established by steps 3 and
4. When you add another PMIPv6 tunnel in the figure, you should make it
clear whether these two tunnels are the same one or different in the
description.

> [Zhou]The Binding Update List entry is for the MAG while the Binding 
> Cache entry is for the LMA as defined in RFC5213.

Yes, and Section 3.4 talks about the MAG, right? So, this should be the
Binding Update List, not the Binding Cache.

> [Zhou]Yes, you are right. I will correct it.

Ok.

Regards,
-- 
Hidetoshi

---

From: jouni korhonen <[email-masked]>
Date: Sun, 24 Jul 2011 18:14:51 +0300

Hidetoshi-san,

> clear whether these two tunnels are the same one or different in the

Actually the text should also handle the situation where the prefix delegation is done during the PMIPv6 tunnel creation. So essentially there are two cases: prefix delegation done during the tunnel establishment and prefix delegation done after the tunnel has been established (the current text in the draft). The latter is kind of "more vital" as it adds a new PBU/PBA exchange on demand after the address for the MN has already been assigned.

> Binding Update List, not the Binding Cache.

Right.

>> [Zhou]Yes, you are right. I will correct it.

- JOuni

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 26 Jul 2011 15:28:26 +0900

Hi Jouni,

> Actually the text should also handle the situation where the prefix delegation is done during the PMIPv6 tunnel creation. So essentially there are two cases: prefix delegation done during the tunne…

Thanks for your clarification. I understand that two cases exist. In any
case, an individual PMIP tunnel is created for the delegated prefix not
using the first PMIP tunnel. I recommend clarifying the tunnel endpoint
addresses on both sides of each tunnel in the document.

I also recommend referring to RFC6276 "DHCPv6 Prefix Delegation for
Network Mobility (NEMO)", which will become the basis of your draft.

Ok.

Regards,
-- 
Hidetoshi

---

From: jouni korhonen <[email-masked]>
Date: Tue, 26 Jul 2011 16:54:26 +0300

Hi Hidetoshi-san,

On Jul 26, 2011, at 9:28 AM, Hidetoshi Yokota wrote:

[snip]

> addresses on both sides of each tunnel in the document.

This is not always the case, see for example draft-ietf-dhc-pd-exclude-02. All prefixes including the delegated prefix and the HNP can be out of the same shorter prefix. Thus, one tunnel, one route entry, one policy rule etc.

But I agree, there is room for text enhancement here. We'll work towards it.

> Network Mobility (NEMO)", which will become the basis of your draft.

Hmm.. lets see. I really did not agree all stuff that went into that RFC during the IESG review phase ;) Besides, one of the use cases in our I-D is that the MN originates the DHCP-PD request, not the MR.

But, again, I agree there is room for text enhancements here.

- Jouni

[snap]

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 27 Jul 2011 08:32:50 +0900

Hi Jouni,

> This is not always the case, see for example draft-ietf-dhc-pd-exclude-02. All prefixes including the delegated prefix and the HNP can be out of the same shorter prefix. Thus, one tunnel, one route…

Actually, I prefer to use one tunnel for multiple prefixes (all ones if
possible), but I didn't figure out how this draft handles the use of
tunnels, which is why I asked for more clarification.

> But I agree, there is room for text enhancement here. We'll work towards it.

Thanks.

> Hmm.. lets see. I really did not agree all stuff that went into that RFC during the IESG review phase ;) Besides, one of the use cases in our I-D is that the MN originates the DHCP-PD request, not…

You don't need to take all the specs from RFC6276, but for example, in
this RFC, the DHCPv6 Relay Agent (DRA) is co-located in the MR, while
your draft says that the MAG MUST play the role of the DRA. I would like
to know if this MUST is really a MUST or other configurations is acceptable.

> But, again, I agree there is room for text enhancements here.

Hope my comment was of some help.

Regards,
-- 
Hidetoshi