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

<Basavaraj.Patil@nokia.com> Mon, 07 November 2011 20:17 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
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 5550511E80C1 for <netext@ietfa.amsl.com>; Mon, 7 Nov 2011 12:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.12
X-Spam-Level:
X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Jkhlk+-G8G+8 for <netext@ietfa.amsl.com>; Mon, 7 Nov 2011 12:17:57 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A379311E80C0 for <netext@ietf.org>; Mon, 7 Nov 2011 12:17:57 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA7KHsng004524; Mon, 7 Nov 2011 22:17:55 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 22:17:54 +0200
Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0339.002; Mon, 7 Nov 2011 21:17:53 +0100
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Review of I-D: draft-ietf-netext-pd-pmip-01
Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIQ==
Date: Mon, 7 Nov 2011 20:17:52 +0000
Message-ID: <CADD9916.1535F%basavaraj.patil@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [172.19.59.33]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <541C80BA34419143AEBCE7BEBA0D6FA3@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Nov 2011 20:17:54.0086 (UTC) FILETIME=[54CFE460:01CC9D8A]
X-Nokia-AV: Clean
Cc: draft-ietf-netext-pd-pmip@tools.ietf.org
Subject: [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: Mon, 07 Nov 2011 20:17:58 -0000

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.

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?

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?

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.

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.

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.

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.

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????

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.


-Raj