Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Thu, 10 November 2011 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6F1C21F8B1F; Thu, 10 Nov 2011 04:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -97.635
X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H8mDU-k-xY+r; Thu, 10 Nov 2011 04:36:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0725321F8B1D; Thu, 10 Nov 2011 04:36:19 -0800 (PST)
Received: from [] by with surfront esmtp id 566903502467742; Thu, 10 Nov 2011 20:25:44 +0800 (CST)
Received: from [] by [] with StormMail ESMTP id 20387.7534587262; Thu, 10 Nov 2011 20:31:21 +0800 (CST)
Received: from ([]) by with ESMTP id pAACVFWf016539; Thu, 10 Nov 2011 20:31:15 +0800 (GMT-8) (envelope-from
In-Reply-To: <>
To: <>
MIME-Version: 1.0
X-KeepSent: 69C8640F:9EAA66B4-48257944:003FA1B5; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <>
Date: Thu, 10 Nov 2011 20:30:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-10 20:31:18, Serialize complete at 2011-11-10 20:31:18
Content-Type: multipart/alternative; boundary="=_alternative 0044C66D48257944_="
X-MAIL: pAACVFWf016539
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Nov 2011 12:36:21 -0000

Hi Raj,
Thanks for your comments. Please see below inline. 写于 2011-11-08 上午 04:17:52:

> A few quick comments:
> 1. Abstract should have no references. And the description can be
>    improved. It really is hard to understand what this I-D is trying
>    to accomplish. 
> 2. The introduction section can be improved. Maybe you should include
>    a problem statement section to indicate what is lacking in PMIP6 as
>    per RFC5213.
[Joy]Rewording will be done for 1&2 in next version.
> 3. In Sec 3.1 it states:
> "
>    o  The MR (as a RR) MUST either obtain the Home Network Prefix (HNP)
>       before initiating the DHCPv6-PD procedure or in case of stateful
>       address configuration simultaneously while configuring the Mobile
>       Node Home Address (MN-HoA).
> "
>    So does this imply that the MR (PMIP6 MN) obtains an HNP as per
>    RFC5213 for its own use prior to the MR requesting via DHCPv6
>    another set of prefixes to be used for delegating to downstream
>    nodes? 
> 4. If the prefixes (delegated) are provided by a DHCP server (and not
>    the LMA), how does the LMA get informed about these? In the PBU?
>    How do you ensure that
>    "All the mobile network prefixes managed in the DR MUST be
>    reachable via local mobility anchor (LMA)" when they are not
>    assigned by the LMA?
[Joy]Here it assumes that the LMA can interact with the DHCPv6 Server 
within some other mechanisms e.g. Radius.
> 5. Sec 3.1 also states:
>    "The delegating router (DR) can be located either at LMA or some
>       other device in the PMIPv6 domain"
>     What is this some other device?
[Joy]Here we just study these two kinds of deployments which are common in 
current network.
> 6.  In Sec 3.2 the I-D states that the profile needs to indicate
>     whether an MN can be assigned prefixes for delegation. Does the
>     profile indicate whether the host is a mobile router? Is this
>     needed? Any MN should be able to act as an MR.
[Joy]MN is able to act as an MR does not mean it can obtain mobile network 
prefix. Usually whether the mobile network prefix is allowed depends on 
the profile.
> 7. In Fig 1, you have a DR shown there. How does the DR indicate the
>    assigned prefixes to the LMA?
>    - Step 5 seems disconnected from the rest of the process. Maybe it
>    is better to split that aspect and show it in another figure.
[Joy]As I say in Q4. I am not sure what you mention of the step 5. It is 
just relayed by the MAG.
> 8. Does the lifetime of the delegated prefix (assigned by a DR) the
>    same as the lifetime assigned by the LMA?
>    Why not have Sec 3.3.3 to describe how a prefix is revoked or
>    deleted? Text is currently in 3.3.2.
[Joy]This is a good proposal.
> 9. In sec 3.4.2:
>    "Other considerations from Section 6.10.5 or [RFC5213]"
>    Sec 6.10.5 of this I-D? There is none.
[Joy]It does exist "6.10.5.  Forwarding Rules"
> 10. Sec 3.5.2 states:
>     "In order to receive
>       those packets, the LMA MUST advertise a connected route into the
>       routing infrastructure for the MR's MNP(s)."
>     - Is it enough from a specification standpoint to state that the
>       routes need to be injected into the routing infra?
>       Handwaving????
[Joy]From the routing perspective, I am not sure what else needs to be 
specified. Can you give another proposal?
> 11. Are there any new threats or security issues that arise from
>     assigning prefixes to be delegated downstream in the case of
>     PMIP6? Security section seems pretty light.
[Joy]We will search for possible text for this in the future discussion.

> -Raj
> _______________________________________________
> netext mailing list