[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.221.58.212 with SMTP id wl20mr738305vcb.19.1382091822427; Fri, 18 Oct 2013 03:23:42 -0700 (PDT)
Received: by 10.52.160.9 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: Michał 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
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. 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 example: 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): 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
- [netext] Review: draft-ietf-netext-pd-pmip-10 Michał Hoeft
- Re: [netext] Review: draft-ietf-netext-pd-pmip-10 Sri Gundavelli (sgundave)
- Re: [netext] Review: draft-ietf-netext-pd-pmip-10 Carlos Jesús Bernardos Cano
- Re: [netext] Review: draft-ietf-netext-pd-pmip-10 Michał Hoeft