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

Michał Hoeft <michal.hoeft@gmail.com> Fri, 18 October 2013 10:24 UTC

Return-Path: <michal.hoeft@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D746511E81BC for <netext@ietfa.amsl.com>; Fri, 18 Oct 2013 03:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iKrU0l4WK9GI for <netext@ietfa.amsl.com>; Fri, 18 Oct 2013 03:23:59 -0700 (PDT)
Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4611E81D5 for <netext@ietf.org>; Fri, 18 Oct 2013 03:23:51 -0700 (PDT)
Received: by mail-vb0-f47.google.com with SMTP id h10so1776701vbh.34 for <netext@ietf.org>; Fri, 18 Oct 2013 03:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FVP5pBMnnC4Q7+5Rc1kI8Cf3tuaxuftOOqBtdRvhdqg=; b=xg3duACwZ3zCChBWEsTJl94Awo2SKHikIXB/vgEMNlLHHW2BrALnTh1F/ciiiOym9n JMToo06JCSZat0Q3R/g+Mq8e/QTU01qDDbpZ3NHHlLml3uQJRqErzzu1AfJUQcorrvy8 Tw5Wu6xPhe+zgCKxjI3AdhaGNXoX5JxxQEDnCRVelJSGQdGb7EGIBKqZUn45w4C0+7kc 397GWb3mzYu59GJEwtYC18xtyRfncSEbwekTwXXQrInLQgGObTQn0k9KxgbAP/XcOPBP GwOcdCirEEJL6Khu8eroRxYUBNGTCjdsleUvwaGKvg3DlsQIsuLEbvvOm1MlnjiW1BGx E4HA==
MIME-Version: 1.0
X-Received: by with SMTP id wl20mr738305vcb.19.1382091822427; Fri, 18 Oct 2013 03:23:42 -0700 (PDT)
Received: by with HTTP; Fri, 18 Oct 2013 03:23:42 -0700 (PDT)
Date: Fri, 18 Oct 2013 12:23:42 +0200
Message-ID: <CA+qxUdYmH9yHPY=mPZrcNg2KgDSd0ZHawaW-7EGfRe68DYv4_Q@mail.gmail.com>
From: =?ISO-8859-2?Q?Micha=B3_Hoeft?= <michal.hoeft@gmail.com>
To: "netext@ietf.org" <netext@ietf.org>
Content-Type: multipart/alternative; boundary=001a11335e5c1f810204e90154eb
Subject: [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 10:24:01 -0000


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.
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).

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
3.2.1 DMNP provided during registration
3.2.2 Separated AR and DMNP registration
3.2.3 Aggregated AR and DMNP registration

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.

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):
page 11:
from the mobile router from registering => from the mobile router for

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

Best regards
Michal Hoeft