Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01

zhou.xingyue@zte.com.cn Thu, 10 November 2011 12:36 UTC

Return-Path: <zhou.xingyue@zte.com.cn>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1C21F8B1F; Thu, 10 Nov 2011 04:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.635
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8mDU-k-xY+r; Thu, 10 Nov 2011 04:36:20 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0725321F8B1D; Thu, 10 Nov 2011 04:36:19 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566903502467742; Thu, 10 Nov 2011 20:25:44 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.7534587262; Thu, 10 Nov 2011 20:31:21 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAACVFWf016539; Thu, 10 Nov 2011 20:31:15 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn)
In-Reply-To: <CADD9916.1535F%basavaraj.patil@nokia.com>
To: <Basavaraj.Patil@nokia.com>
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: <OF69C8640F.9EAA66B4-ON48257944.003FA1B5-48257944.0044C676@zte.com.cn>
From: zhou.xingyue@zte.com.cn
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: mse02.zte.com.cn pAACVFWf016539
Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2011 12:36:21 -0000

Hi Raj,
Thanks for your comments. Please see below inline.

netext-bounces@ietf.org 写于 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? 
[Joy]Yes.
> 
> 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?
[Joy]Yes.
>    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.

Joy
> 
> 
> -Raj
> 
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>