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

jouni korhonen <jouni.nospam@gmail.com> Fri, 16 September 2011 11:14 UTC

Return-Path: <jouni.nospam@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 8741121F8B7E for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 04:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 dnWJr+KMWqRg for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 04:14:36 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8B21F8B7B for <netext@ietf.org>; Fri, 16 Sep 2011 04:14:36 -0700 (PDT)
Received: by bkaq10 with SMTP id q10so3698762bka.31 for <netext@ietf.org>; Fri, 16 Sep 2011 04:16:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Vdth850CC4tbpGtY8k4KQMxaiTb3MjbCYtChCKgFAKk=; b=RlIelAhIH+RJunq8eUfoe4D8MQiqNgtIpRFcXhthUhmVa0lDhQcKorRQbfK82Znvti HCY9Qa0qB4pXDcSqVNRxtyTMJMbSJ0ZCzUIHwpat8bFZXVg/27816K5fg3mXX8vUy1BP eWkqmREaHxb2CHi2941wW3TdNY7Cmn3WPwnEU=
Received: by 10.204.2.130 with SMTP id 2mr229226bkj.407.1316171810149; Fri, 16 Sep 2011 04:16:50 -0700 (PDT)
Received: from [192.168.2.88] (ip202-115.seclan.com. [81.19.115.202]) by mx.google.com with ESMTPS id m18sm6106742bkt.12.2011.09.16.04.16.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 04:16:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719A967D4@008-AM1MPN1-051.mgdnok.nokia.com>
Date: Fri, 16 Sep 2011 14:16:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <45130380-9459-45AC-A3E7-ED2B1AFF5DF8@gmail.com>
References: <CA8FFC68.108EC%basavaraj.patil@nokia.com>, <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com> <21E7D9BD69CC7241AAE00F4EA183B719A967D4@008-AM1MPN1-051.mgdnok.nokia.com>
To: <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com>
X-Mailer: Apple Mail (2.1084)
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: Fri, 16 Sep 2011 11:14:37 -0000

Raj,

On Sep 12, 2011, at 4:29 PM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@nokia.com> wrote:

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

Fair enough. How about:

4.1.  Redirect-Capability Mobility Option

   ...
   o  Reserved: This field is reserved for future use.  MUST be set to
      zero by the sender and ignored by the receiver.

   The Redirect-Capability option is used by the MAG to inform the LMA
   that is implements and has enabled the runtime LMA assignment 
   functionality.

4.2.  Redirect Mobility Option

   ...
   o  Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA.  This
      value is present when the corresponding PBU was sourced from an
      IPv4 address (for IPv4 transport, see [RFC5844]).

   The Redirect option is used by the LMA to inform the MAG that the
   runtime LMA assignment took place and the MAG has to update its
   Binding Update List Entry (BULE) for the mobility session.



I suppose I need to submit a new revision asap..?

- Jouni



- Jouni



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