Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01
<Basavaraj.Patil@nokia.com> Mon, 14 November 2011 01:38 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 39F7811E8083 for <netext@ietfa.amsl.com>; Sun, 13 Nov 2011 17:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7wG2nXxBYBxy for <netext@ietfa.amsl.com>; Sun, 13 Nov 2011 17:38:29 -0800 (PST)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0916421F8783 for <netext@ietf.org>; Sun, 13 Nov 2011 17:38:28 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAE1cN0S007779; Mon, 14 Nov 2011 03:38:24 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 03:38:08 +0200
Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Mon, 14 Nov 2011 02:38:07 +0100
From: Basavaraj.Patil@nokia.com
To: sarikaya@ieee.org
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01
Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIZWmqVIAgAVtDwA=
Date: Mon, 14 Nov 2011 01:38:06 +0000
Message-ID: <CAE691D0.159C9%basavaraj.patil@nokia.com>
In-Reply-To: <CAC8QAceKDtSbdz+F3rnVwQbsAGUT6Gzp_M+20vrnP-B+14R9RA@mail.gmail.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: [130.129.17.117]
Content-Type: multipart/alternative; boundary="_000_CAE691D0159C9basavarajpatilnokiacom_"
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Nov 2011 01:38:08.0354 (UTC) FILETIME=[0FE30420:01CCA26E]
X-Nokia-AV: Clean
Cc: netext@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: Mon, 14 Nov 2011 01:38:30 -0000
Behect, I believe you answered your own question in the email. So yes, you are correct. The answer is No. -Basavaraj From: ext Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> Reply-To: Behcet Sarikaya <sarikaya@ieee.org<mailto:sarikaya@ieee.org>> Date: Thu, 10 Nov 2011 16:46:28 -0600 To: Basavaraj Patil <basavaraj.patil@nokia.com<mailto:basavaraj.patil@nokia.com>> Cc: Netext <netext@ietf.org<mailto:netext@ietf.org>>, <draft-ietf-netext-pd-pmip@tools.ietf.org<mailto:draft-ietf-netext-pd-pmip@tools.ietf.org>> Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Hi Basavaraj, I have a question: Can we at Netext work on specs that require modifying MN? Reading the charter: The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). It seems to me the answer is no? Regards, Behcet On Mon, Nov 7, 2011 at 2:17 PM, <Basavaraj.Patil@nokia.com<mailto:Basavaraj.Patil@nokia.com>> wrote: 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 _______________________________________________ netext mailing list netext@ietf.org<mailto:netext@ietf.org> https://www.ietf.org/mailman/listinfo/netext
- [netext] Review of I-D: draft-ietf-netext-pd-pmip… Basavaraj.Patil
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… zhou.xingyue
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… jouni korhonen
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Basavaraj.Patil
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Sri Gundavelli
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Basavaraj.Patil
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Behcet Sarikaya
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Basavaraj.Patil
- Re: [netext] Review of I-D: draft-ietf-netext-pd-… Alexandru Petrescu