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

Michał Hoeft <michal.hoeft@gmail.com> Tue, 22 October 2013 06:41 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 CF35F11E8482 for <netext@ietfa.amsl.com>; Mon, 21 Oct 2013 23:41:09 -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 eCgM5zQor1gG for <netext@ietfa.amsl.com>; Mon, 21 Oct 2013 23:41:07 -0700 (PDT)
Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC911E847B for <netext@ietf.org>; Mon, 21 Oct 2013 23:40:22 -0700 (PDT)
Received: by mail-vb0-f46.google.com with SMTP id 10so3960097vbe.19 for <netext@ietf.org>; Mon, 21 Oct 2013 23:40:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppN+sQqm33Vv5mNfV1O0s34BcJSvCxN1qtTp/movI3c=; b=IKpZ6PzwlqemWgF2Yj+fdYRXyhuqxrOzaAMQXxXeF3o9DllMVAo4WdNj2Ygyo6tKud zUs/tjOxFjLjT/h+ZVbezMOErGDTNjQqBIOEVMbvCZnM94s6G50mAOSPrLL7VizfZZSz K6GdFTyFGgJvprkhsm6qDHh5t+7h+vEhTml41lHYBA5fWVSJOvywM3shM3bJQhQW0rbD tgDPHT6QyJFbJqEgLjwYFNX0PoPGALcOZVFv5VYIU6l9yhPmLsUnNjGfRksy/bItpOYk JTwk8OHXGhOENZvyLAAJWsql+S6t3XKc/22sdIDtM4ryu+0KA0bu62lGpAlfRxk6TtuV hBOg==
MIME-Version: 1.0
X-Received: by 10.52.34.109 with SMTP id y13mr12059512vdi.8.1382424022011; Mon, 21 Oct 2013 23:40:22 -0700 (PDT)
Received: by 10.52.160.9 with HTTP; Mon, 21 Oct 2013 23:40:21 -0700 (PDT)
In-Reply-To: <1382306830.4098.51.camel@acorde.it.uc3m.es>
References: <24C0F3E22276D9438D6F366EB89FAEA81DCB7BBA@xmb-aln-x03.cisco.com> <1382306830.4098.51.camel@acorde.it.uc3m.es>
Date: Tue, 22 Oct 2013 08:40:21 +0200
Message-ID: <CA+qxUdYn79_v6WfeKq+mwmeX=tV+uCu2+qXsrgqfkCUpXjBZpQ@mail.gmail.com>
From: =?ISO-8859-2?Q?Micha=B3_Hoeft?= <michal.hoeft@gmail.com>
To: cjbc@it.uc3m.es
Content-Type: multipart/alternative; boundary=20cf30780c5cc2f78a04e94eac98
Cc: "netext@ietf.org" <netext@ietf.org>
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: Tue, 22 Oct 2013 06:41:10 -0000

Hi Sri, Carlos

Thank you very much for answers and clarification. Now, I see your point of
view.
Best regards
Michal


2013/10/21 Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>

> Hi Sri, Michal,
>
> Thanks a lot Michar for your comments.
>
> Adding some additional comments inline below.
>
> On Fri, 2013-10-18 at 18:05 +0000, Sri Gundavelli (sgundave) wrote:
> > Hi Michal,
> >
> >
> > Thanks for the good review comments... some comments inline ..Carlos can
> > add/clarify more ...
> >
> >
> >
> >
> >
> >
> > From: Michał Hoeft <michal.hoeft@gmail.com>
> > Date: Friday, October 18, 2013 3:23 AM
> > To: "netext@ietf.org" <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 ?
> >
> [Carlos] Yes, agree. We'll add a note in -11.
> >
> > >  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.
> >
> >
> >
> [Carlos] Yes, I think it is better not to explicitly add that, so we
> avoid not covering some potential case. As long as what we have in the
> text is clear and allow for implementation of the spec, I think it is
> better not to add more text.
> >
> >
> > Please, consider also revision of following typos:
> >
> >
> > page 4:
> >
> > is enabled is for => is enabled for
>
> [Carlos] Fixed in -11, thanks.
> >
> > page 7,9:
> >
> > proxy binding acknowledgment => Proxy Binding Acknowledgment
> > proxy binding update => Proxy Binding Update
>
> [Carlos] I think the RFC Editor prefers these terms to be in lowercase,
> with the exception of the first time they appear and the acronym is
> introduced.
> >
> > page 9. Figure 2: Message 4):
> > PBU =>PBU(DMNP)
>
> [Carlos] Here the intention is to highlight that the prefix is delegated
> by the LMA and conveyed back in the PBA. Maybe we can explicitly show
> that the DMNP option is present but with an ALL_ZERO value.
> >
> > page 11:
> >
> > from the mobile router from registering => from the mobile router for
> > registering
> >
> [Carlos] Fixed in -11, thanks.
>
> >
> > If you need any additional detail on my comments, please, do not
> > hesitate to contact me.
>
> Again, thanks!
>
> Carlos
> >
> >
> > Best regards
> >
> > Michal Hoeft
> >
> >
> > _______________________________________________
> > netext mailing list
> > netext@ietf.org
> > https://www.ietf.org/mailman/listinfo/netext
>
>
>