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

<Basavaraj.Patil@nokia.com> Tue, 06 September 2011 21:37 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 99C9921F8EC8 for <netext@ietfa.amsl.com>; Tue, 6 Sep 2011 14:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.621
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mWpmzkD+VsG for <netext@ietfa.amsl.com>; Tue, 6 Sep 2011 14:37:29 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C0EDC21F8EC4 for <netext@ietf.org>; Tue, 6 Sep 2011 14:37:29 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p86LdEGw016630; Wed, 7 Sep 2011 00:39:14 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 00:39:13 +0300
Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 6 Sep 2011 23:39:13 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Tue, 6 Sep 2011 23:39:12 +0200
From: <Basavaraj.Patil@nokia.com>
To: <jouni.nospam@gmail.com>, <netext@ietf.org>
Thread-Topic: [netext] draft-ietf-netext-redirect-10
Thread-Index: AQHMa5kIKyAHUqAFiEWVrh738FBPXZVAbkaA
Date: Tue, 6 Sep 2011 21:39:12 +0000
Message-ID: <CA8BFCD4.10280%basavaraj.patil@nokia.com>
In-Reply-To: <0CF4086F-75C1-453C-A524-509472EA0765@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
x-originating-ip: [172.19.59.27]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <495DA24BA1688F4CAAF343CDA0973DC5@nokia.com>
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-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: 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.

-Raj

On 9/5/11 1:56 AM, "ext jouni korhonen" <jouni.nospam@gmail.com> wrote:

>Folks, 
>
>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
>changes/modifications.
>
>First, a bunch of clarifications:
>
>o In section 1 the text is slightly modified to clarify that AAA/DNS
>support
>  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
>the
>  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
>network
>  byte order.
>
>o in Section 4.2 it was clarified (or rephrased actually) that the
>Redirect
>  option in a PBA contains IPv6 address of the r2LMA when the
>corresponding
>  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
>that
>  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
>fine.
>
>  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.
>
>Phew..
>
>- Jouni
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext