Re: [netext] Review: draft-ietf-netext-pd-pmip-10

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 18 October 2013 18:05 UTC

Return-Path: <sgundave@cisco.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 88C8011E8127 for <netext@ietfa.amsl.com>; Fri, 18 Oct 2013 11:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.298
X-Spam-Level:
X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 e-zftgbEmJAb for <netext@ietfa.amsl.com>; Fri, 18 Oct 2013 11:05:16 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 245C611E8297 for <netext@ietf.org>; Fri, 18 Oct 2013 11:05:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12788; q=dns/txt; s=iport; t=1382119513; x=1383329113; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=VkgzTHx37iXegTVYcI/1QYR8sKbhrh8uOGOcRfETsqc=; b=m4YQCnFaPj8LZslNJzfESo+U3PhyoyADpXCO5WLvEcWO8MdJW/BHQW6+ lYd9ZNsVz2OSRKpCwFDdassNBbS/FpZGn1uZ4d9Uoq2PsL5ZFw3g4FdQ5 qoD/fh9f8rDaO1Xbd9Obae977uDhpURvJw3pIYXgxVGaoV4qQ2YfC/WjH E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFADV3YVKtJV2c/2dsb2JhbABagkNEgQqDKrp6gSEWdIIlAQEBAwEEHARaDQEIEQMBAgsdBCQRFAkIAgQBEggTh1kDCQaucQyINA2Ja4xmgj8gGAaCZTSBCgOWHo47hTeDJIIp
X-IronPort-AV: E=Sophos; i="4.93,524,1378857600"; d="scan'208,217"; a="270881508"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 18 Oct 2013 18:05:12 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9II5CkT005158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 18:05:12 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.192]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 13:05:11 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Michał Hoeft <michal.hoeft@gmail.com>, "netext@ietf.org" <netext@ietf.org>
Thread-Topic: [netext] Review: draft-ietf-netext-pd-pmip-10
Thread-Index: AQHOzCyVbnDKzehEXkORxuqABrGyiw==
Date: Fri, 18 Oct 2013 18:05:10 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com>
In-Reply-To: <CA+qxUdYmH9yHPY=mPZrcNg2KgDSd0ZHawaW-7EGfRe68DYv4_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.211]
Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA81DCB7BBAxmbalnx03ciscoc_"
MIME-Version: 1.0
Subject: Re: [netext] Review: draft-ietf-netext-pd-pmip-10
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: Fri, 18 Oct 2013 18:05:22 -0000

Hi Michal,

Thanks for the good review comments… some comments inline ..Carlos can add/clarify more …



From: Michał Hoeft <michal.hoeft@gmail.com<mailto:michal.hoeft@gmail.com>>
Date: Friday, October 18, 2013 3:23 AM
To: "netext@ietf.org<mailto:netext@ietf.org>" <netext@ietf.org<mailto:netext@ietf.org>>
Subject: [netext] Review: draft-ietf-netext-pd-pmip-10

Hello

I am a researcher at Gdańsk University of Technology interested in mobility management protocols, especially in PMIPv6. I would be very thankful if authors of draft-ietf-netext-pd-pmip-10 could clarify my doubt.

I wonder, why Section 3 is not more general, why only three deployment models are described in the draft and titled after DR location.
It seams that, DR don't have to be co-located with LMA (Section 3.2.2). In this case, it can be run on an external server and it does not change message flow.
It is similar in Section 3.2.1, in which LMA provides to DR prefixes by means of DMNP option. It is very interesting protocol integrating solution.

[Sri] We covered the key deployment models.  DR function can be on the located in the home network and that is typically on the LMA. It can be certainly outside the LMA, but there is some interworking needed between the DR and the LMA and is out of scope for this spec. We did not explicitly cover that scenario, but a deployment can certainly make that work. But, that has no impact on the wire protocol between the LMA and MAG. We can add a note that this is certainly allowed. Carlos – Agree ?


>  However I'm a little confused considering implementation of DR co-located with MAG. I can imagine a deployment model, in that DR is co-located with MAG but obtains prefixes using more common methods e.g. Delegated-IPv6-Prefix AVP (RFC 4818). Especially, if it could be aggregated with other MAG-to-HAAA AVPs (RFC 5779).

[Sri] From protocol point of view, MAG can include the DMNP option, with ALL_ZERO or with a specific value. MAG can learn about those prefixes, via AAA (with DMNP AVP's), local config, DHCP interworking and request the same. MAG has the ability to populate the DMNP option with a specific prefix value, or a 0 to allow LMA to do the allocation. If you see the protocol section, which is more generic, you will see this.


In my opinion, titles of Sections 3.2.1-3.2.3 should be changed to be more accurate and to describe MAG-LMA interaction instead of DR co-location. For example:
3.2.1 DMNP provided during registration
3.2.2 Separated AR and DMNP registration
3.2.3 Aggregated AR and DMNP registration

[Sri] That is certainly one way to drafting and is fine. What is there in section 3.2.1 to 3.2.1 are more covered along the lines of popular deployment model, but the protocol section is more generic. The key point is that protocol semantic clearly allow the negotiation in  a flexible manner covering all these variations.


In accordance with RFC5213, PBU/PBA messages have few mandatory options (MNI,HNP,HI,AAT). Although some of them are easy to set (MNI with MNI of AR, HI with 5. Handoff state not changed, AAT depends on access technology - please correct me if I'm wrong), I see the problem with HNP in separate AD and DMNP registration scenario. In my opinion, it should be defined how to fill this option - either ALL_ZERO or HNP of AR.

[Sri] Carlos can add. But, the protocol is not requiring changes to the base options. In all the scenarios covered by 5213, 5844, this allows a MAG to request a additional prefix set, for delegation, as supposed to hosting them on the MN-AR link.



Please, consider also revision of following typos:
page 4:
is enabled is for => is enabled for
page 7,9:
proxy binding acknowledgment => Proxy Binding Acknowledgment
proxy binding update => Proxy Binding Update
page 9. Figure 2: Message 4):
PBU =>PBU(DMNP)
page 11:
from the mobile router from registering => from the mobile router for registering

If you need any additional detail on my comments, please, do not hesitate to contact me.

Best regards
Michal Hoeft