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

[jouni korhonen <[e-mail]>]

Hidetoshi-san,


On Jul 24, 2011, at 3:06 AM, Hidetoshi Yokota wrote:

> Hi Zhou,
> 
> Thanks for your response. Please see inline:
> 
> (2011/07/22 11:45), [e-mail] wrote:
>> 
>> Hi Hidetoshi,
>> Many thanks for your comments. Please see inline below.
>> 
>> [e-mail] 写于 2011-07-21 下午 07:14:16:
>> 
>>> 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?
>> [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.
> 
> 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.

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.

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

Right.

> 
>>> 
>>> (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.
>> [Zhou]Yes, you are right. I will correct it.
> 
> Ok.
> 
> Regards,
> -- 
> Hidetoshi



- JOuni