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

jouni korhonen <> Mon, 12 September 2011 11:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B6A1021F8541 for <>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.821
X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id thfITjMGWKJm for <>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 24B8321F8560 for <>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
Received: by yxt33 with SMTP id 33so29096yxt.31 for <>; Mon, 12 Sep 2011 04:10:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=d4LaAv8C6X6c6TLZpMoxkKfPBgoSFSsWCWvFzkLsi/w=; b=fuXD8/rhcriu5oQGt8otARp3y9ui9u/ovomqKZaLrvfBpzDN/eSPzB55uE9Hslj4ip uvLmmQ9ryjYhGyhMvQg2MKnafHawD2VcZxP4pJvtIGqmP5Z+jqV/7TRpReewpmP0Ltlp Y8kmLsHs285pxIBJ3yOpSH40Yw7+zYT9CWq1s=
Received: by with SMTP id j4mr1107385ybm.339.1315825837066; Mon, 12 Sep 2011 04:10:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id u19sm1900878ybm.4.2011. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 04:10:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <>
In-Reply-To: <>
Date: Mon, 12 Sep 2011 14:10:28 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: <> <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [netext] Review of I-D: draft-ietf-netext-redirect-10
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Sep 2011 11:08:34 -0000


Thanks for the review. See my comments inline.

On Sep 10, 2011, at 1:24 AM, <> <> 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.


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


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


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


And thanks,

> -Raj
> _______________________________________________
> netext mailing list