IETF Logo Mail Archive

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

jouni korhonen <jouni.nospam@gmail.com> Mon, 12 September 2011 11:08 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 B6A1021F8541 for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.821
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thfITjMGWKJm for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8321F8560 for <netext@ietf.org>; Mon, 12 Sep 2011 04:08:34 -0700 (PDT)
Received: by yxt33 with SMTP id 33so29096yxt.31 for <netext@ietf.org>; Mon, 12 Sep 2011 04:10:37 -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=d4LaAv8C6X6c6TLZpMoxkKfPBgoSFSsWCWvFzkLsi/w=; b=fuXD8/rhcriu5oQGt8otARp3y9ui9u/ovomqKZaLrvfBpzDN/eSPzB55uE9Hslj4ip uvLmmQ9ryjYhGyhMvQg2MKnafHawD2VcZxP4pJvtIGqmP5Z+jqV/7TRpReewpmP0Ltlp Y8kmLsHs285pxIBJ3yOpSH40Yw7+zYT9CWq1s=
Received: by 10.151.107.4 with SMTP id j4mr1107385ybm.339.1315825837066; Mon, 12 Sep 2011 04:10:37 -0700 (PDT)
Received: from [10.255.135.53] ([192.100.123.77]) by mx.google.com with ESMTPS id u19sm1900878ybm.4.2011.09.12.04.10.32 (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 <jouni.nospam@gmail.com>
In-Reply-To: <CA8FFC68.108EC%basavaraj.patil@nokia.com>
Date: Mon, 12 Sep 2011 14:10:28 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com>
References: <CA8FFC68.108EC%basavaraj.patil@nokia.com>
To: 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: Mon, 12 Sep 2011 11:08:34 -0000

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

v2.23.0 | Report a Bug | By Email