Re: [netext] draft-ietf-netext-redirect-10

<> Tue, 06 September 2011 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99C9921F8EC8 for <>; Tue, 6 Sep 2011 14:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.621
X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5mWpmzkD+VsG for <>; Tue, 6 Sep 2011 14:37:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C0EDC21F8EC4 for <>; Tue, 6 Sep 2011 14:37:29 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p86LdEGw016630; Wed, 7 Sep 2011 00:39:14 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 00:39:13 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 6 Sep 2011 23:39:13 +0200
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Tue, 6 Sep 2011 23:39:12 +0200
From: <>
To: <>, <>
Thread-Topic: [netext] draft-ietf-netext-redirect-10
Thread-Index: AQHMa5kIKyAHUqAFiEWVrh738FBPXZVAbkaA
Date: Tue, 6 Sep 2011 21:39:12 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Sep 2011 21:39:13.0172 (UTC) FILETIME=[6B5CD540:01CC6CDD]
X-Nokia-AV: Clean
Subject: Re: [netext] 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: Tue, 06 Sep 2011 21:37:30 -0000

Thanks Jouni for bringing these clarifications to the attention of the WG.
I have no specific comments or suggestions regarding the proposed changes.
Please note that there will not be any additional WG last call to this I-D
as a result of these changes.


On 9/5/11 1:56 AM, "ext jouni korhonen" <> wrote:

>Based on implementation experience we felt there really is a need to
>shape up few places in the draft-ietf-netext-redirect-09 and also fix
>some overlooked details. This is done with a knowledge of our AD. See
>recently posted draft-ietf-netext-redirect-10 for exact text
>First, a bunch of clarifications:
>o In section 1 the text is slightly modified to clarify that AAA/DNS
>  is not needed for the initial discovery & selection of the (rf)LMA. Once
>  the MAG learns a number of r2LMAs it does not actually need to contact
>  rfLMA every time thus bypassing the rfLMA as soon and often as possible.
>o In Section 1 we also clarified that all MAGs and LMAs that can do
>  "redirection" have to belong to the same PMIP6 domain.
>o In Section 4 we remind that all values and numbers are actually in
>  byte order.
>o in Section 4.2 it was clarified (or rephrased actually) that the
>  option in a PBA contains IPv6 address of the r2LMA when the
>  PBU source IP address was IPv6 address. And the same for IPv4 as well.
>o In multiple places we included a reference to RFC5844 just to remind
>  the solution is also applicable when IPv4-HoA and/or IPv4 transport is
>  used.
>o Figure 1 was modified so that MAG-rfLMA and rfLMA-r2LMA steps are
>  actually logically separate independent whether the rfLMA and r2LMA are
>  collocated or separate.
>o In Section 5.2 we emphasize that MAG must ignore unsolicited Redirect
>  option and continue PBA processing as described in RFC5213.
>o In Section 5.2 we added a mention of tunnel creation and a reference to
>  MAG tunnel creation procedures in RFC5213.
>o In Section 5.3.1 we added Figure 2 to show an example signaling in case
>  of 'collocated rfLMA and r2LMA'.
>o In Section 5.3.2 we added Figure 3 to show an example signaling in case
>  of 'separate rfLMA (proxy-MAG) and r2LMA'.
>o In Section 5.3.2 we clarify what addresses go into PBUs/PBAs.
>o Section 6 is renamed to "Handoff and Multi-Homing Considerations" as it
>  is about both, not just about multi-homing.
>o In Section 7 we state that for a rfLMA most of the RFC5213 configuration
>  objects do not apply when an LMA is in rfLMA role.
>Second, an enhancement to distribute load information around which helps
>MAGs and proxy-MAGs to select r2LMAs. This is to make the solution more
>standalone and not to mandate an introduction of some "load distribution"
>protocol as a part of the package:
>o Section 4.3 introduces a new Load Information mobility option that
>  contains basic key performance indicators of r2LMAs for MAGs to check
>  the load of the box and possibly prioritize them based on that
>  information. The use of option is optional.
>Third, fixes to flaws & found issues:
>o In Section 5.3.1 the reference to LMA tunnel creation procedures into
>  RFC5213 was actually pointing to MAG procedures.
>o Since -08 we do not have need for redirect related Status Values. Some
>  of those were left in the document due to sloppiness of the editor *g*
>  when doing -08. Thus 'Accepted_and_Redirected_with_Binding' is now also
>  removed. To find out whether a redirection took place, Redirect option
>  in a PBA is sufficient. This is also required to make the redirect
>  compliant with e.g. RFC5845.
>o Then a bigger one, which concerns the use of Alternate Care-of Address
>  in RFC5844 & IPv4 transport scope. There is actually no exact text
>  anywhere (in RFC5844 or RFC5555) what goes in that mobility option when
>  IPv4 transport is used. Our initial reaction (and actually was the
>  assumption of some authors) was that IPv4-mapped addresses are just
>  Anyway, as we cannot really be sure we felt that we really need to have
>  a new mobility option for Alternate IPv4 Care-of Address and define the
>  the exact behavior for it. In this way we can actually make sure a LMA
>  understood the Alternate IPv4 Care-of Address. Section 4.4 describes
>  the new option. We know this is late in document cycle and adds a new
>  MUST into Section 5.3.2 but it is more or less required.
>- Jouni
>netext mailing list