Re: [netext] Review of I-D: draft-ietf-netext-redirect-10

<Basavaraj.Patil@nokia.com> Mon, 12 September 2011 13:27 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 93A6E21F85A8 for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 06:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.67
X-Spam-Level:
X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, 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 u0VywwboTIS9 for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 06:27:11 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF9721F85B5 for <netext@ietf.org>; Mon, 12 Sep 2011 06:27:10 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8CDT0Do005272; Mon, 12 Sep 2011 16:29:11 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 16:29:03 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Sep 2011 15:29:03 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Mon, 12 Sep 2011 15:29:02 +0200
From: <Basavaraj.Patil@nokia.com>
To: <jouni.nospam@gmail.com>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-redirect-10
Thread-Index: AQHMbz9K1OOVFC+yBEKKB/AJ5YQGcZVJeSIAgABHT3M=
Date: Mon, 12 Sep 2011 13:29:02 +0000
Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719A967D4@008-AM1MPN1-051.mgdnok.nokia.com>
References: <CA8FFC68.108EC%basavaraj.patil@nokia.com>, <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com>
In-Reply-To: <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.74.219.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Sep 2011 13:29:03.0689 (UTC) FILETIME=[F06C5B90:01CC714F]
X-Nokia-AV: Clean
Cc: netext@ietf.org, draft-ietf-netext-redirect@tools.ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-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: Mon, 12 Sep 2011 13:27:11 -0000

Hi Jouni,

Just one issue that still bothers me:

>> 4. In Section 4, it would be useful to explain (in brief) what is the
>>   functionality of a specific option. For example the
>>   'Redirect-Capability Mobility Option': The text has no explanation
>>   what this option is supposed to do in a message. You could add at
>>   least one sentence saying that it is used to indicate the redirect
>>   capability supported by the MAG, LMA entitied.

>I see your point. However, these texts were removed by discuss comments in IESG.

I disagree. I think that text explaining the decription of the option is useful and helps readability.
If you see Secs 6.2.4, .5 etc in RFC3775 as an example, these are also options for MIP6 and they
do provide a brief explanation. Having such text IMO would be useful in this I-D.

Thx.
-Raj

________________________________________
From: ext jouni korhonen [jouni.nospam@gmail.com]
Sent: Monday, September 12, 2011 6:10 AM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: netext@ietf.org; draft-ietf-netext-redirect@tools.ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-10

Raj,

Thanks for the review. See my comments inline.

On Sep 10, 2011, at 1:24 AM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:

>
> My WGLC review comments on Rev 10 of the I-D: draft-ietf-netext-redirect
>
> 1. Abstract can be improved. Rather than just mentioning the scope you
>   could describe briefly the feature specified in this I-D.

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6. The runtime Local Mobility Anchor assignment takes place during
   a Proxy Binding Update and a Proxy Binding Acknowledgement message
   exchange between a Mobile Access Gateway and a Local Mobility Anchor.
   The runtime Local Mobility Anchor assignment functionality defined in
   this specification can be used, for example, for load balancing purposes.

> 2. Would be useful to describe in the introduction how runtime LMA
>   assignment is different from the normal mode as specified in
>   RFC5213 (which you do in Sec 5.2 1st paragraph)

Hmm.. I think there is no reason to repeat that technical stuff in Introduction.

> 3. s/assumed to have required Security Associations (SA)already set up
>   in advance./assumed to have the required Security Associations (SA)
>   pre-established.

Ack.

> 4. In Section 4, it would be useful to explain (in brief) what is the
>   functionality of a specific option. For example the
>   'Redirect-Capability Mobility Option': The text has no explanation
>   what this option is supposed to do in a message. You could add at
>   least one sentence saying that it is used to indicate the redirect
>   capability supported by the MAG, LMA entitied.

I see your point. However, these texts were removed by discuss comments in IESG.

> 5. Missing the direction of the signaling flow message no 1 in fig 1.

Ack.

> 6. s/There is no need to resend a PBU to the r2LMA after a successful
>   runtime assignment./The MAG is not required to send a fresh PBU to
>   the r2LMA after a successful runtime assignment.

Ack.


> 7. s/The MAG MUST send subsequent binding refreshing PBUs and user
>   traffic to the new r2LMA address./
>   The MAG MUST send all user traffic to the r2LMA address. The MAG MUST
>   send subsequent binding refresh PBUs to the r2LMA address.

Ack.

And thanks,
        Jouni


>
> -Raj
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext