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

[Hidetoshi Yokota <[e-mail]>]

Hi Jouni,

(2011/07/26 22:54), jouni korhonen wrote:
> Hi Hidetoshi-san,
> 
> 
> On Jul 26, 2011, at 9:28 AM, Hidetoshi Yokota wrote:
> 
> 
> [snip]
> 
>>>> 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.
>>
>> 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.
> 
> 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.

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.

>> I also recommend referring to RFC6276 "DHCPv6 Prefix Delegation for
>> 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.

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


> - Jouni
> 
> [snap]
> 
>