From internet-drafts@ietf.org  Sun Sep  4 23:44:45 2011
Return-Path: <internet-drafts@ietf.org>
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 BE61C21F8AD6; Sun,  4 Sep 2011 23:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 y89VC6olpVH5; Sun,  4 Sep 2011 23:44:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6556F21F855F; Sun,  4 Sep 2011 23:44:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110905064444.25959.93248.idtracker@ietfa.amsl.com>
Date: Sun, 04 Sep 2011 23:44:44 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-redirect-10.txt
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, 05 Sep 2011 06:44:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Runtime LMA Assignment Support for Proxy Mobile IPv6
	Author(s)       : Jouni Korhonen
                          Sri Gundavelli
                          Hidetoshi Yokota
                          Xiangsong Cui
	Filename        : draft-ietf-netext-redirect-10.txt
	Pages           : 21
	Date            : 2011-09-04

   This document describes a runtime Local Mobility Anchor assignment
   functionality and corresponding mobility options for Proxy Mobile
   IPv6.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-redirect-10.txt

From jouni.nospam@gmail.com  Sun Sep  4 23:54:53 2011
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 6553521F85B1; Sun,  4 Sep 2011 23:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.575
X-Spam-Level: 
X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024,  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 Dm8ChXz3hfE9; Sun,  4 Sep 2011 23:54:52 -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 0EB7721F855D; Sun,  4 Sep 2011 23:54:51 -0700 (PDT)
Received: by bkar4 with SMTP id r4so5137893bka.31 for <multiple recipients>; Sun, 04 Sep 2011 23:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=V9Ucl2/7q82W3ntzJY+ipU24yJj3reNzvbnUsTdDBS8=; b=DEKmjCPGJcPHDdhSHMmm3kshiVhJqejjHKA4Ly1sOvUlDLyR1hbXaIneGD9NpOK/Xu xVfUR9kY1+3q6OU4YthLBgjUE/EuGMc/Lz+3z2oxa5ZHIQXCrhZrWquhXqPuCO7a/lKA OW3FNReDFapkWEOwwlRkw9YGL5Y74k2mn+g8o=
Received: by 10.204.143.77 with SMTP id t13mr2022901bku.120.1315205792709; Sun, 04 Sep 2011 23:56:32 -0700 (PDT)
Received: from a88-114-66-207.elisa-laajakaista.fi (a88-114-66-207.elisa-laajakaista.fi [88.114.66.207]) by mx.google.com with ESMTPS id z7sm3081295bkt.5.2011.09.04.23.56.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Sep 2011 23:56:31 -0700 (PDT)
From: jouni korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Sep 2011 09:56:29 +0300
Message-Id: <0CF4086F-75C1-453C-A524-509472EA0765@gmail.com>
To: netext@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: "iesg@ietf.org IESG" <iesg@ietf.org>, netext-chairs@tools.ietf.org
Subject: [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: Mon, 05 Sep 2011 06:54:53 -0000

Folks,=20

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

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

  MUST into Section 5.3.2 but it is more or less required.

Phew..

- Jouni

From internet-drafts@ietf.org  Mon Sep  5 09:15:11 2011
Return-Path: <internet-drafts@ietf.org>
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 261A221F8B8E; Mon,  5 Sep 2011 09:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level: 
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 FAaAckJuIRUa; Mon,  5 Sep 2011 09:15:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489B21F8B4C; Mon,  5 Sep 2011 09:15:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110905161510.5234.57634.idtracker@ietfa.amsl.com>
Date: Mon, 05 Sep 2011 09:15:10 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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, 05 Sep 2011 16:15:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Logical Interface Support for multi-mode IP Hosts
	Author(s)       : Telemaco Melia
                          Sri Gundavelli
	Filename        : draft-ietf-netext-logical-interface-support-03.txt
	Pages           : 26
	Date            : 2011-09-05

   A Logical Interface is a software semantic internal to the host
   operating system.  This semantic is available in all popular
   operating systems and is used in various protocol implementations.
   The Logical Interface support is required on the mobile node
   operating in a Proxy Mobile IPv6 domain, for leveraging various
   network-based mobility management features such as inter-technology
   handoffs, multihoming and flow mobility support.  This document
   explains the operational details of Logical Interface construct and
   the specifics on how the link-layer implementations hide the physical
   interfaces from the IP stack and from the network nodes on the
   attached access networks.  Furthermore, this document identifies the
   applicability of this approach to various link-layer technologies and
   analyzes the issues around it when used in context with various
   mobility management features.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-sup=
port-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-supp=
ort-03.txt

From internet-drafts@ietf.org  Tue Sep  6 06:30:02 2011
Return-Path: <internet-drafts@ietf.org>
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 2632721F8804; Tue,  6 Sep 2011 06:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 bwz8kRdAyYer; Tue,  6 Sep 2011 06:30:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F3F21F8770; Tue,  6 Sep 2011 06:30:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110906133001.28960.5382.idtracker@ietfa.amsl.com>
Date: Tue, 06 Sep 2011 06:30:01 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-00.txt
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 13:30:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Proxy Mobile IPv6 Extensions to Support Flow Mobility
	Author(s)       : Carlos J. Bernardos
	Filename        : draft-ietf-netext-pmipv6-flowmob-00.txt
	Pages           : 19
	Date            : 2011-09-06

   Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
   management protocol that enables mobile devices to connect to a
   PMIPv6 domain and roam across gateways without changing their IP
   addresses.  The PMIPv6 basic specification also provides limited
   multi-homing support to multi-mode mobile devices.  The ability of
   movement of selected flows from one access technology to another is
   missing in the basic PMIPv6.  This document describes enhancements to
   the Proxy Mobile IPv6 protocol that are required to support flow
   mobility over multiple physical interfaces.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.txt

From brian.haley@hp.com  Tue Sep  6 06:34:36 2011
Return-Path: <brian.haley@hp.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 5BE5321F886A for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 06:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.307
X-Spam-Level: 
X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 hJvqLgtoMROA for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 06:34:35 -0700 (PDT)
Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id BD81521F87D3 for <netext@ietf.org>; Tue,  6 Sep 2011 06:34:35 -0700 (PDT)
Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0186.atlanta.hp.com (Postfix) with ESMTP id 1E6D72C031; Tue,  6 Sep 2011 13:36:22 +0000 (UTC)
Received: from [16.1.1.40] (squirrel.fc.hp.com [15.11.146.57]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 9CC6B14154; Tue,  6 Sep 2011 13:36:21 +0000 (UTC)
Message-ID: <4E6621D4.4020407@hp.com>
Date: Tue, 06 Sep 2011 09:36:20 -0400
From: Brian Haley <brian.haley@hp.com>
Organization: HP Cloud Services
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12
MIME-Version: 1.0
References: <20110905161510.5234.57634.idtracker@ietfa.amsl.com>
In-Reply-To: <20110905161510.5234.57634.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 06 Sep 2011 06:39:11 -0700
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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 13:34:36 -0000

Hi Sri,

On 09/05/2011 12:15 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.
> 
> 	Title           : Logical Interface Support for multi-mode IP Hosts
> 	Author(s)       : Telemaco Melia
>                           Sri Gundavelli
> 	Filename        : draft-ietf-netext-logical-interface-support-03.txt
> 	Pages           : 26
> 	Date            : 2011-09-05

I read this draft and had a comment on Section 6.5:

6.5.  ND Considerations for Logical Interface

   The following are the Neighbor Discovery related considerations for
   the logical interface.

   o  Any Neighbor Discovery messages, such as Router Solicitation,
      Neighbor Solicitation messages that the host sends to a multicast
      destination address of link-local scope such as, all-nodes, all-
      routers, solicited-node multicast group addresses, using either an
      unspecified (::) source address, or a link-local address
      configured on the logical interface will be replicated and
      forwarded on each of the sub-interfaces under that logical
      interface.  However, if the destination address is a unicast
      address and if that target is known to exist on a specific sub-
      interface, the message will be forwarded only on that specific
      sub-interface.

I'm not sure about other OSes, but since you mentioned the Linux bonding driver
as an example of a Logical interface I can respond regarding that.  There are
configurations where you do NOT want to replicate a packet and forward it on all
the underlying physical interfaces.  Doing so can cause DAD failures if any of
the other interfaces see those packets sent to the all-nodes multicast address.
 We noticed and fixed that back in 2008.

BTW, I'm not subscribed to net-next, so haven't seen any previous discussion on
the draft.

-Brian

From Basavaraj.Patil@nokia.com  Tue Sep  6 14:32:46 2011
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 0BE2621F8E62 for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 14:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.109
X-Spam-Level: 
X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 FdXntjFXoUQi for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 14:32:45 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6721F8E61 for <netext@ietf.org>; Tue,  6 Sep 2011 14:32:44 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p86LYTju024285; Wed, 7 Sep 2011 00:34:31 +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:34:21 +0300
Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) 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:34:21 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Tue, 6 Sep 2011 23:34:20 +0200
From: <Basavaraj.Patil@nokia.com>
To: <draft-ietf-netext-radius-pmip6@tools.ietf.org>
Thread-Topic: Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
Thread-Index: AQHMbNy8PJKafFxS906ekAVZzEsk8Q==
Date: Tue, 6 Sep 2011 21:34:19 +0000
Message-ID: <CA8BFC07.1027C%basavaraj.patil@nokia.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: <A23827FC5FD4384495B393C4EA09FAD5@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Sep 2011 21:34:21.0369 (UTC) FILETIME=[BD6F3A90:01CC6CDC]
X-Nokia-AV: Clean
Cc: netext@ietf.org
Subject: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
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:32:46 -0000

Hello,

A few comments regarding this I-D before it is ready to be sent to the
IESG:

1. The abstract is very poorly written. It simply says "This I-D
defines X and Y and Z". It would be preferable to have a real abstract
which states that the PMIP6 uses Radius based interfaces between:
- the MAG and the AAA server
- the LMA and the AAA server
which are used for authentication, authorization and policy functions.

Please update the abstract. In fact part of the 1st paragraph of the
Intro section can be used in the abstract.

2.=20

s/In the context of this document, the NAS function is logically
coupled with the MAG./This document makes an assumption that the NAS
function is co-located with the MAG.

s/In deployments where the NAS function and the MAG functions are
decoupled, the specific interactions needed for that to work is
outside the scope of this document./In scenarios where the NAS
function and MAG are decoupled, the messaging interface needed between
them for the operation of PMIP6 is beyond the scope of this document.

3.=20
s/Any time a mobile node attaches to an access network/When a mobile
node attaches to an access network

4. In Section 3:
Q: The I-D says: "If the network access authentication succeeds, the
MN is identified "=20

The MN identity is already known as part of access authentication. The
above sentence implies that only of network authentication succeeds,
MN identity is known. You may want to rephrase.

5.=20
s/access authentication procedure SHALL provide/access authentication
procedure SHOULD provide

(In IETF parlance, we use MUST, SHOULD and MAY)

6.=20
"After the successful network access authentication and after
   obtaining the mobile node's Policy Profile, the MAG sends a PBU to
   the LMA."

Rephrase and avoid using After multiple times in the same sentence.

7.=20
s/needed for authorizing and setting up the mobility service./which is
required for authorizing and activating mobility service.

8. In Section 4.2
Q: The I-D states: "If the MAG has not acquired a valid MN-Identifier by
other
   means, it MUST use the received MN-Identifier."

How else would the MAG get the MN-ID?

9. In section 4.3:
Q: I-D states: "The MAG MUST include the Service-Selection attribute
in the Access-Request sent to the AAA if the information was
acquired."

How does the MAG obtain the service selection attribute? It needs to
be explained. Because if the MAG is going to populate this attribute
in the Access-Request message, it MUST have obtained that parameter
somehow.=20

10.=20
s/The AAA MAY
   return the Service-Selection to the MAG even if it was not included
   in the Access-Request as means to indicate MN's default service to
   the MAG./
The AAA MAY include the Service-Selection attribute in the
Acess-Accept response message to the MAG even if it was not included
in the Access-Request as a means of indicating the MN's default service.

11. In sec 4.3 I-D states:
"On the LMA-to-AAA interface, the LMA MAY populate the Service-
   Selection attribute in the Access-Request message using the service
   information found in the received PBU, if such mobility option was
   included."

In which I-D or RFC is the service-information option that can be
carried within a PBU specified?

12.=20
s/Before the MAG can engage in Proxy Mobile IPv6 signaling/Before the
MAG can initiate Proxy Mobile IPv6 signaling

13.=20
s/PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
   to VAAA in the RADIUS Access-Request packet as a proposal to allocate
   the particular LMA to the MN./
PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
   to the VAAA entity in the RADIUS Access-Request message. It enables
the MAG to request an LMA in the visited network.

Q: How does the MAG decide if it is authorized to request an LMA in
the visited network? Needs to be explained.

This comment also applies to Sec 4.7

14. Sec 4.10:
"For Proxy Mobile IPv6 the Home Network Prefixes assigned to the
   mobile node have to be maintained on a per-interface basis.  When the
   LMA is located in the home network, PMIP6-Home-Interface-ID attribute
   conveys 64 bits interface identifier representing a particular MN's
   interface.  The attribute is assigned by the HAAA to the MAG for
   derivation of the MN-HoA.
"

Is it the MNs interface ID that is being sent? The description in this
section is not clear.

15. Sec 4.18  =20

Which specific attribute defined in RFC5213 are you suggesting as the
one to be used for the Calling-station-ID. RFC5213 itself does not
mention any such attribute in the nomenclature.

16. Sec 7.1/2

Does this I-D mandate the MAG and LMA entities to do metering of
traffic associated with an MN? RFC5213 itself does not require such
functionality. You may want to make this clear in these sections.

17. The security section needs to be further improved. What are the
types of threats associated with sending MN specific information
between the MAG and AAA server; And between the LMA and AAA server.
The current security considerations section is lacking in detail.

-Basavaraj


From Basavaraj.Patil@nokia.com  Tue Sep  6 14:37:30 2011
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,=20
>
>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.
>=20
>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


From Basavaraj.Patil@nokia.com  Tue Sep  6 14:49:14 2011
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 E053A21F8EFD for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 14:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.631
X-Spam-Level: 
X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 cAuKe5CjP8C1 for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 14:49:14 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4C26D21F8DBB for <netext@ietf.org>; Tue,  6 Sep 2011 14:49:14 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p86LoxCG030490; Wed, 7 Sep 2011 00:51:01 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Sep 2011 00:50:59 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) 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:50:58 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Tue, 6 Sep 2011 23:50:58 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Short WGLC on I-D draft-ietf-netext-redirect-10
Thread-Index: AQHMbN8PgY6GdT+J0kiua3aYdqT8BQ==
Date: Tue, 6 Sep 2011 21:50:58 +0000
Message-ID: <CA8BFFF1.10299%basavaraj.patil@nokia.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: <D47C142E2DC144469604AAADB7447F55@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Sep 2011 21:50:59.0200 (UTC) FILETIME=[10302800:01CC6CDF]
X-Nokia-AV: Clean
Cc: adrian@olddog.co.uk, draft-ietf-netext-redirect@tools.ietf.org
Subject: [netext] Short WGLC on 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: Tue, 06 Sep 2011 21:49:15 -0000

Hello,

The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6
< draft-ietf-netext-redirect-10.txt> has undergone several edits and
corrections as a result of implementation experience.
Please see Jouni Korhonen's email to the ML :
http://www.ietf.org/mail-archive/web/netext/current/msg02170.html
which explains the changes and the rationale.

Given the scope of the changes, we would like the WG to give their
feedback through a short WG LC that is limited to one week.

Please consider this email as the start of the WG LC for this I-D.
Reviews and feedback on the changes made to the I-D should be posted to
the netext WG ML by  Sept 15th 2011.

URL for I-D: http://www.ietf.org/id/draft-ietf-netext-redirect-10.txt

-Chairs


From sgundave@cisco.com  Tue Sep  6 21:08:14 2011
Return-Path: <sgundave@cisco.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 2759D21F8D7C for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 21:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level: 
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599]
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 94zCsYSrpeWS for <netext@ietfa.amsl.com>; Tue,  6 Sep 2011 21:08:13 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 698F821F8D80 for <netext@ietf.org>; Tue,  6 Sep 2011 21:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2692; q=dns/txt; s=iport; t=1315368601; x=1316578201; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=JtPGs2ETPWMKrFMAtoD3FvVlnnqMr4tC+paPHwkTP+g=; b=nKA4/gf6EOkkr1R0pzpK2SWlMohnvZ11rVGwpod6rOzCr+PQzCUxLjDQ UJL4WesFSQNJSuuMAEdJajbAg3XaZjw9IbuJTe13Ed88nn8C91hnSWtbC n42CWzryIaVwBKIAVOYlBVVWKo0NAITMXWE7eRe8qX0VNBOIYDLbpQQAd o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAPbtZk6rRDoH/2dsb2JhbABDqAx4gUYBAQEBAgESAScCATwFDQEIgR0BAQQOBSKHU5glAZ5WhmsEh2uLRIUbjBg
X-IronPort-AV: E=Sophos;i="4.68,343,1312156800";  d="scan'208";a="576158"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 07 Sep 2011 04:10:01 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p874A1cR024903; Wed, 7 Sep 2011 04:10:01 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 6 Sep 2011 21:10:01 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Wed,  7 Sep 2011 04:10:00 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Tue, 06 Sep 2011 21:09:54 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Brian Haley <brian.haley@hp.com>
Message-ID: <CA8C3CA2.27A18%sgundave@cisco.com>
Thread-Topic: I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AcxtE/8vyxb5jigt/kOfdnY8pMieZg==
In-Reply-To: <4E6621D4.4020407@hp.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2011 04:10:01.0576 (UTC) FILETIME=[03B35680:01CC6D14]
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Wed, 07 Sep 2011 04:08:14 -0000

Hi Brian,

Long time :)

Thanks for the review comment. Please see inline.



On 9/6/11 6:36 AM, "Brian Haley" <brian.haley@hp.com> wrote:

> Hi Sri,

> I read this draft and had a comment on Section 6.5:
> 
> 6.5.  ND Considerations for Logical Interface
> 
>    The following are the Neighbor Discovery related considerations for
>    the logical interface.
> 
>    o  Any Neighbor Discovery messages, such as Router Solicitation,
>       Neighbor Solicitation messages that the host sends to a multicast
>       destination address of link-local scope such as, all-nodes, all-
>       routers, solicited-node multicast group addresses, using either an
>       unspecified (::) source address, or a link-local address
>       configured on the logical interface will be replicated and
>       forwarded on each of the sub-interfaces under that logical
>       interface.  However, if the destination address is a unicast
>       address and if that target is known to exist on a specific sub-
>       interface, the message will be forwarded only on that specific
>       sub-interface.
> 
> I'm not sure about other OSes, but since you mentioned the Linux bonding
> driver
> as an example of a Logical interface I can respond regarding that.  There are
> configurations where you do NOT want to replicate a packet and forward it on
> all
> the underlying physical interfaces.  Doing so can cause DAD failures if any of
> the other interfaces see those packets sent to the all-nodes multicast
> address.
>  We noticed and fixed that back in 2008.
> 

Thanks for the info. I'm not sure, if your failure scenario is specific to
logical interface construct, or if you are referring to a general case of
packet replication. For the case of logical interface construct,
essentially, we are presenting a single interface to the host stack, but
underneath there are multiple physical interfaces. Some of the operations
such as router discovery when initiated on the logical interface, should
translate to performing this operation on multiple physical interfaces.

For example, Sending a RS message on a LI abstracting WLAN and WiMAX should
result in sending that RS message on both the paths. I'm sure, this can be
achieved in multiple ways, but the external behavior what needs to be seen
is the generation of two RS packets on those two sub-interfaces. May be if
you can provide more info on your failure case, we can structure this right.
But, that was our intent.
  


> BTW, I'm not subscribed to net-next, so haven't seen any previous discussion
> on
> the draft.

Will surely help us, if you are on the list.

Regards
Sri


From julien.ietf@gmail.com  Wed Sep  7 07:58:13 2011
Return-Path: <julien.ietf@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 809C321F8C47 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 07:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.511
X-Spam-Level: 
X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088,  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 vrhbJscO+ewf for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 07:58:13 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC1EC21F8B52 for <netext@ietf.org>; Wed,  7 Sep 2011 07:58:12 -0700 (PDT)
Received: by wwf5 with SMTP id 5so4961850wwf.13 for <netext@ietf.org>; Wed, 07 Sep 2011 08:00:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=1YrbvN7VFb8IeVFASZfNLlsxsBR8yTYr/rF5ilJaVGs=; b=ERtdxB0OL4E2Qa/kI1p7QFIPzyVhI90fs+IIPmEtQb5jK6GSJlkmDVbWh+XOZkdVcy pJP4OWOoBniHpENg0WKgQqQ3Y4HXxj9fipnf3FhoJXY5s1x86n4x4oaxkaZP1P8pt/Kn 1HyejLzI5D3hxaJISJi4e1HjVUKrjy2lBqvCI=
MIME-Version: 1.0
Received: by 10.227.11.85 with SMTP id s21mr5242985wbs.59.1315407601735; Wed, 07 Sep 2011 08:00:01 -0700 (PDT)
Received: by 10.227.27.141 with HTTP; Wed, 7 Sep 2011 08:00:01 -0700 (PDT)
In-Reply-To: <20110906133001.28960.5382.idtracker@ietfa.amsl.com>
References: <20110906133001.28960.5382.idtracker@ietfa.amsl.com>
Date: Wed, 7 Sep 2011 08:00:01 -0700
Message-ID: <CAE_dhju+v_sObRtKBy8mT7_aAhB9HqWR70qaVgUw__sgpNkxfQ@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: netext@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-00.txt
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: Wed, 07 Sep 2011 14:58:13 -0000

We agreed to adopt the draft without the LMA-initiated flow movement.
However the draft still contains material where the LMA decide to move
flows, e.g.,

"At certain point, either MN or LMA can decide to move flow Y to also
go through MAG1."

I think these should be removed.

--julien

On Tue, Sep 6, 2011 at 6:30 AM,  <internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the Network-Based Mobility Extensions W=
orking Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Proxy Mobile IPv6 Extensions t=
o Support Flow Mobility
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Carlos J. Bernardos
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-pmipv6-flowmob=
-00.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-06
>
> =A0 Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
> =A0 management protocol that enables mobile devices to connect to a
> =A0 PMIPv6 domain and roam across gateways without changing their IP
> =A0 addresses. =A0The PMIPv6 basic specification also provides limited
> =A0 multi-homing support to multi-mode mobile devices. =A0The ability of
> =A0 movement of selected flows from one access technology to another is
> =A0 missing in the basic PMIPv6. =A0This document describes enhancements =
to
> =A0 the Proxy Mobile IPv6 protocol that are required to support flow
> =A0 mobility over multiple physical interfaces.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.t=
xt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.tx=
t
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

From Basavaraj.Patil@nokia.com  Wed Sep  7 08:05:49 2011
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 B6E1321F8C5F for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 08:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.131
X-Spam-Level: 
X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 o3+jfph7dXml for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 08:05:49 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0373D21F8C5B for <netext@ietf.org>; Wed,  7 Sep 2011 08:05:48 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p87F6gpm021123; Wed, 7 Sep 2011 18:07:35 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Sep 2011 18:07:28 +0300
Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 17:07:27 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Wed, 7 Sep 2011 17:07:26 +0200
From: <Basavaraj.Patil@nokia.com>
To: <julien.ietf@gmail.com>, <netext@ietf.org>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-00.txt
Thread-Index: AQHMbJlgLtiH7r/PqEeMf/IVMBLbz5VB4uiA//+uPAA=
Date: Wed, 7 Sep 2011 15:07:26 +0000
Message-ID: <CA8CF297.10391%basavaraj.patil@nokia.com>
In-Reply-To: <CAE_dhju+v_sObRtKBy8mT7_aAhB9HqWR70qaVgUw__sgpNkxfQ@mail.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: <6C3315914BEA194CBBB5B493A01C8D7C@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Sep 2011 15:07:28.0124 (UTC) FILETIME=[DBACE3C0:01CC6D6F]
X-Nokia-AV: Clean
Subject: Re: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-00.txt
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: Wed, 07 Sep 2011 15:05:49 -0000

Hi Julien,

I concur. I reviewed the revised I-D prior to Carlos submitting it and
missed this one.=20
Carlos, please remove the statement from the I-D.

-Raj

On 9/7/11 10:00 AM, "ext Julien Laganier" <julien.ietf@gmail.com> wrote:

>We agreed to adopt the draft without the LMA-initiated flow movement.
>However the draft still contains material where the LMA decide to move
>flows, e.g.,
>
>"At certain point, either MN or LMA can decide to move flow Y to also
>go through MAG1."
>
>I think these should be removed.
>
>--julien
>
>On Tue, Sep 6, 2011 at 6:30 AM,  <internet-drafts@ietf.org> wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories. This draft is a work item of the Network-Based Mobility
>>Extensions Working Group of the IETF.
>>
>>        Title           : Proxy Mobile IPv6 Extensions to Support Flow
>>Mobility
>>        Author(s)       : Carlos J. Bernardos
>>        Filename        : draft-ietf-netext-pmipv6-flowmob-00.txt
>>        Pages           : 19
>>        Date            : 2011-09-06
>>
>>   Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
>>   management protocol that enables mobile devices to connect to a
>>   PMIPv6 domain and roam across gateways without changing their IP
>>   addresses.  The PMIPv6 basic specification also provides limited
>>   multi-homing support to multi-mode mobile devices.  The ability of
>>   movement of selected flows from one access technology to another is
>>   missing in the basic PMIPv6.  This document describes enhancements to
>>   the Proxy Mobile IPv6 protocol that are required to support flow
>>   mobility over multiple physical interfaces.
>>
>>
>>
>> A URL for this Internet-Draft is:
>>=20
>>http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.t
>>xt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>>=20
>>ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.tx
>>t
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext


From behcetsarikaya@yahoo.com  Wed Sep  7 12:49:20 2011
Return-Path: <behcetsarikaya@yahoo.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 7FE7E21F8C18 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 12:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level: 
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811,  BAYES_00=-2.599]
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 C8A8LpRdheIC for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 12:49:19 -0700 (PDT)
Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by ietfa.amsl.com (Postfix) with SMTP id B973A21F8C42 for <netext@ietf.org>; Wed,  7 Sep 2011 12:49:19 -0700 (PDT)
Received: from [98.139.91.65] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
Received: from [98.139.91.23] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 07 Sep 2011 19:51:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 451826.2665.bm@omp1023.mail.sp2.yahoo.com
Received: (qmail 54246 invoked by uid 60001); 7 Sep 2011 19:51:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315425066; bh=Y2cZsGDuZCEzBXt3270MPmgkZGq8V9gmp/Qw9LBkeJY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XP25rn0c3g4L899rlQDHB3wCKwgt+m5OZqtIOUJ4E/IrZr6oGnacT9Pnh8Fhd16O4pCPrXFu+ov5gL7Z5zWYeOSAacTxjqO3Vp0f5CkP+waK8ac9mvaqIWc8mc0dik9yoOpROj1vxTz3qgf9lCqrMM6/QkISn/dVzfYlhgB42t8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RK/0fwDfgX9E26PaPcrNrxqJ6vBaDnVEiq8G5nktqlYB3zEGYOp5F6mKarf2/bHVpK3lbYMsnMq6pdHDPeyZeCxpep9uzyxDrB+Ei1i1sel+IVvuq/L3LcMrXpvZgJcQb6EPcbGTfMpP7RRZvmvHdDFPrEvF8kDSy6QxcJhT46w=;
X-YMail-OSG: c1AgEjYVM1mdmU2t63amM6hhfzEehKZLlVBEGFlbK7Ztp1V VIY3pTyJn995hrVha2exiwbghPFqGTX2J.DXUw.K1J1l46R9E1GoOYMUMrE9 f..vR6iSCKw0H6R1RIYM37dDfS4PshaDCZE.ywyfRJpFoTgtwapKRn63NuE8 KEEBb6MUwU4nQY8loOMvj_wnxSaDhm3u4YdIBWhsdqebo1uti6AGBGpivFCS STysrZH9Hd7UGyFy_wiwOetPMO8y5S1oHMGMKJFSXS_5cgmlQE1bKiBhN6iK 6sJ8GKtIFNRgHA9cq1_GusTgBwj_GDGz48rVYkZyyy2mPydXDs_SCAbIGseB LINw6FXcff818vO9OdAaOVDy9nsNiBcB_7ByAJB5.HJ8KJOEO1iMsf52bQz2 nALEq.Xk0gSlX6fp5tr1K1GWu.3DtGgQHL6M4jNwkJmIKhwTGsfCkb0DTj0v 9dahZguE-
Received: from [50.58.7.243] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 07 Sep 2011 12:51:06 PDT
X-Mailer: YahooMailWebService/0.8.113.315625
References: <CA8BFC07.1027C%basavaraj.patil@nokia.com>
Message-ID: <1315425066.78916.YahooMailNeo@web111416.mail.gq1.yahoo.com>
Date: Wed, 7 Sep 2011 12:51:06 -0700 (PDT)
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>, "draft-ietf-netext-radius-pmip6@tools.ietf.org" <draft-ietf-netext-radius-pmip6@tools.ietf.org>
In-Reply-To: <CA8BFC07.1027C%basavaraj.patil@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
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: Wed, 07 Sep 2011 19:49:20 -0000

Hi Basavaraj,=0A=0AThank you for your comments. We revised the draft accord=
ingly. =0A=0AHowever there is only one issue which is given below.=0A=0AReg=
ards,=0A=0ABehcet=0A=0A=0A> =0A> Hello,=0A> =0A> A few comments regarding t=
his I-D before it is ready to be sent to the=0A> IESG:=0A> =0A> 1. The abst=
ract is very poorly written. It simply says "This I-D=0A> defines X and Y a=
nd Z". It would be preferable to have a real abstract=0A> which states that=
 the PMIP6 uses Radius based interfaces between:=0A> - the MAG and the AAA =
server=0A> - the LMA and the AAA server=0A> which are used for authenticati=
on, authorization and policy functions.=0A> =0A> Please update the abstract=
. In fact part of the 1st paragraph of the=0A> Intro section can be used in=
 the abstract.=0A> =0A> 2. =0A> =0A> s/In the context of this document, the=
 NAS function is logically=0A> coupled with the MAG./This document makes an=
 assumption that the NAS=0A> function is co-located with the MAG.=0A> =0A> =
s/In deployments where the NAS function and the MAG functions are=0A> decou=
pled, the specific interactions needed for that to work is=0A> outside the =
scope of this document./In scenarios where the NAS=0A> function and MAG are=
 decoupled, the messaging interface needed between=0A> them for the operati=
on of PMIP6 is beyond the scope of this document.=0A> =0A> 3. =0A> s/Any ti=
me a mobile node attaches to an access network/When a mobile=0A> node attac=
hes to an access network=0A> =0A> 4. In Section 3:=0A> Q: The I-D says: "If=
 the network access authentication succeeds, the=0A> MN is identified " =0A=
> =0A> The MN identity is already known as part of access authentication. T=
he=0A> above sentence implies that only of network authentication succeeds,=
=0A> MN identity is known. You may want to rephrase.=0A> =0A> 5. =0A> s/acc=
ess authentication procedure SHALL provide/access authentication=0A> proced=
ure SHOULD provide=0A> =0A> (In IETF parlance, we use MUST, SHOULD and MAY)=
=0A> =0A> 6. =0A> "After the successful network access authentication and a=
fter=0A> =A0  obtaining the mobile node's Policy Profile, the MAG sends a P=
BU to=0A> =A0  the LMA."=0A> =0A> Rephrase and avoid using After multiple t=
imes in the same sentence.=0A> =0A> 7. =0A> s/needed for authorizing and se=
tting up the mobility service./which is=0A> required for authorizing and ac=
tivating mobility service.=0A> =0A> 8. In Section 4.2=0A> Q: The I-D states=
: "If the MAG has not acquired a valid MN-Identifier by=0A> other=0A> =A0  =
means, it MUST use the received MN-Identifier."=0A> =0A> How else would the=
 MAG get the MN-ID?=0A> =0A> 9. In section 4.3:=0A> Q: I-D states: "The MAG=
 MUST include the Service-Selection attribute=0A> in the Access-Request sen=
t to the AAA if the information was=0A> acquired."=0A> =0A> How does the MA=
G obtain the service selection attribute? It needs to=0A> be explained. Bec=
ause if the MAG is going to populate this attribute=0A> in the Access-Reque=
st message, it MUST have obtained that parameter=0A> somehow. =0A> =0A> 10.=
 =0A> s/The AAA MAY=0A> =A0  return the Service-Selection to the MAG even i=
f it was not included=0A> =A0  in the Access-Request as means to indicate M=
N's default service to=0A> =A0  the MAG./=0A> The AAA MAY include the Servi=
ce-Selection attribute in the=0A> Acess-Accept response message to the MAG =
even if it was not included=0A> in the Access-Request as a means of indicat=
ing the MN's default service.=0A> =0A> 11. In sec 4.3 I-D states:=0A> "On t=
he LMA-to-AAA interface, the LMA MAY populate the Service-=0A> =A0  Selecti=
on attribute in the Access-Request message using the service=0A> =A0  infor=
mation found in the received PBU, if such mobility option was=0A> =A0  incl=
uded."=0A> =0A> In which I-D or RFC is the service-information option that =
can be=0A> carried within a PBU specified?=0A=0A=0A=0AHere, as in RFC 5779,=
 the assumption is that the option defined in RFC 5149 for BU can also be u=
sed in PBU.=0AIs this OK?=0A=0A=0A> =0A> 12. =0A> s/Before the MAG can enga=
ge in Proxy Mobile IPv6 signaling/Before the=0A> MAG can initiate Proxy Mob=
ile IPv6 signaling=0A> =0A> 13. =0A> s/PMIP6-Visited-LMA-IPv6-Address attri=
bute MAY be included by the MAG=0A> =A0  to VAAA in the RADIUS Access-Reque=
st packet as a proposal to allocate=0A> =A0  the particular LMA to the MN./=
=0A> PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG=0A=
> =A0  to the VAAA entity in the RADIUS Access-Request message. It enables=
=0A> the MAG to request an LMA in the visited network.=0A> =0A> Q: How does=
 the MAG decide if it is authorized to request an LMA in=0A> the visited ne=
twork? Needs to be explained.=0A> =0A> This comment also applies to Sec 4.7=
=0A> =0A> 14. Sec 4.10:=0A> "For Proxy Mobile IPv6 the Home Network Prefixe=
s assigned to the=0A> =A0  mobile node have to be maintained on a per-inter=
face basis.=A0 When the=0A> =A0  LMA is located in the home network, PMIP6-=
Home-Interface-ID attribute=0A> =A0  conveys 64 bits interface identifier r=
epresenting a particular MN's=0A> =A0  interface.=A0 The attribute is assig=
ned by the HAAA to the MAG for=0A> =A0  derivation of the MN-HoA.=0A> "=0A>=
 =0A> Is it the MNs interface ID that is being sent? The description in thi=
s=0A> section is not clear.=0A> =0A> 15. Sec 4.18=A0 =0A> =0A> Which specif=
ic attribute defined in RFC5213 are you suggesting as the=0A> one to be use=
d for the Calling-station-ID. RFC5213 itself does not=0A> mention any such =
attribute in the nomenclature.=0A> =0A> 16. Sec 7.1/2=0A> =0A> Does this I-=
D mandate the MAG and LMA entities to do metering of=0A> traffic associated=
 with an MN? RFC5213 itself does not require such=0A> functionality. You ma=
y want to make this clear in these sections.=0A> =0A> 17. The security sect=
ion needs to be further improved. What are the=0A> types of threats associa=
ted with sending MN specific information=0A> between the MAG and AAA server=
; And between the LMA and AAA server.=0A> The current security consideratio=
ns section is lacking in detail.=0A> =0A> -Basavaraj=0A> =0A> _____________=
__________________________________=0A> netext mailing list=0A> netext@ietf.=
org=0A> https://www.ietf.org/mailman/listinfo/netext=0A>

From brian.haley@hp.com  Wed Sep  7 13:34:38 2011
Return-Path: <brian.haley@hp.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 CED1521F8C8A for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.953
X-Spam-Level: 
X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 AJriCqPgwjrK for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:34:38 -0700 (PDT)
Received: from g1u1820.austin.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41121F8C81 for <netext@ietf.org>; Wed,  7 Sep 2011 13:34:38 -0700 (PDT)
Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g1u1820.austin.hp.com (Postfix) with ESMTP id DDB3E38084; Wed,  7 Sep 2011 20:36:27 +0000 (UTC)
Received: from [16.1.1.40] (squirrel.fc.hp.com [15.11.146.57]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 440F1C034; Wed,  7 Sep 2011 20:36:27 +0000 (UTC)
Message-ID: <4E67D5CA.1080607@hp.com>
Date: Wed, 07 Sep 2011 16:36:26 -0400
From: Brian Haley <brian.haley@hp.com>
Organization: HP Cloud Services
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12
MIME-Version: 1.0
To: Sri Gundavelli <sgundave@cisco.com>
References: <CA8C3CA2.27A18%sgundave@cisco.com>
In-Reply-To: <CA8C3CA2.27A18%sgundave@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Wed, 07 Sep 2011 20:34:38 -0000

Hi Sri,

Yes, it's been a while, I tend to only lurk on the MLs these days...

More inline.

On 09/07/2011 12:09 AM, Sri Gundavelli wrote:
> Hi Brian,
> 
> Long time :)
> 
> Thanks for the review comment. Please see inline.
> 
> 
> 
> On 9/6/11 6:36 AM, "Brian Haley" <brian.haley@hp.com> wrote:
> 
>> Hi Sri,
> 
>> I read this draft and had a comment on Section 6.5:
>>
>> 6.5.  ND Considerations for Logical Interface
>>
>>    The following are the Neighbor Discovery related considerations for
>>    the logical interface.
>>
>>    o  Any Neighbor Discovery messages, such as Router Solicitation,
>>       Neighbor Solicitation messages that the host sends to a multicast
>>       destination address of link-local scope such as, all-nodes, all-
>>       routers, solicited-node multicast group addresses, using either an
>>       unspecified (::) source address, or a link-local address
>>       configured on the logical interface will be replicated and
>>       forwarded on each of the sub-interfaces under that logical
>>       interface.  However, if the destination address is a unicast
>>       address and if that target is known to exist on a specific sub-
>>       interface, the message will be forwarded only on that specific
>>       sub-interface.
>>
>> I'm not sure about other OSes, but since you mentioned the Linux bonding
>> driver
>> as an example of a Logical interface I can respond regarding that.  There are
>> configurations where you do NOT want to replicate a packet and forward it on
>> all
>> the underlying physical interfaces.  Doing so can cause DAD failures if any of
>> the other interfaces see those packets sent to the all-nodes multicast
>> address.
>>  We noticed and fixed that back in 2008.
>>
> 
> Thanks for the info. I'm not sure, if your failure scenario is specific to
> logical interface construct, or if you are referring to a general case of
> packet replication. For the case of logical interface construct,
> essentially, we are presenting a single interface to the host stack, but
> underneath there are multiple physical interfaces. Some of the operations
> such as router discovery when initiated on the logical interface, should
> translate to performing this operation on multiple physical interfaces.
> 
> For example, Sending a RS message on a LI abstracting WLAN and WiMAX should
> result in sending that RS message on both the paths. I'm sure, this can be
> achieved in multiple ways, but the external behavior what needs to be seen
> is the generation of two RS packets on those two sub-interfaces. May be if
> you can provide more info on your failure case, we can structure this right.
> But, that was our intent.

I can understand the abstraction, and why you would want to send some messages
on all the underlying interfaces.

The Linux bonding driver typically isn't used in this way though, it's more of
an HA mechanism to attach a system to a switch, or set of switches, via multiple
paths.  Usually just a group of ports on the top-of-rack switch, for example in
802.3ad mode.  All physical interfaces need to be in the same network.

I've never seen it used where there are multiple types of physical interfaces in
different networks in the bond, not even sure if that's supported...

The failure in question is that in some operating modes you can see broadcasts
sent from other members of the bond (not 802.3ad of course), and that causes
problems, so we create workarounds by trapping them and only transmitting on one
of the interfaces.  That probably isn't going to happen in your scenario.

Maybe the easiest solution is to just remove the Linux reference, I probably
wouldn't have noticed otherwise :)

>> BTW, I'm not subscribed to net-next, so haven't seen any previous discussion
>> on
>> the draft.
> 
> Will surely help us, if you are on the list.

I'll try if the bandwidth is low...

-Brian

From Basavaraj.Patil@nokia.com  Wed Sep  7 13:51:22 2011
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 E0B9A21F8B18 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level: 
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 StvIDamlHW3c for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:51:22 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1521F8B0C for <netext@ietf.org>; Wed,  7 Sep 2011 13:51:21 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p87Kr8qb016940; Wed, 7 Sep 2011 23:53:08 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Sep 2011 23:53:03 +0300
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 22:53:03 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Wed, 7 Sep 2011 22:53:02 +0200
From: <Basavaraj.Patil@nokia.com>
To: <sarikaya@ieee.org>, <draft-ietf-netext-radius-pmip6@tools.ietf.org>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
Thread-Index: AQHMbNy8PJKafFxS906ekAVZzEsk8ZVCM7UA//+9foA=
Date: Wed, 7 Sep 2011 20:53:02 +0000
Message-ID: <CA8D4365.104C4%basavaraj.patil@nokia.com>
In-Reply-To: <1315425066.78916.YahooMailNeo@web111416.mail.gq1.yahoo.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: <8136FE63EB198C4D9C0E95E4B25FA9A6@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Sep 2011 20:53:03.0735 (UTC) FILETIME=[23100870:01CC6DA0]
X-Nokia-AV: Clean
Cc: netext@ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-radius-pmip6 (Rev 4)
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: Wed, 07 Sep 2011 20:51:23 -0000

Hi Behcet,

On 9/7/11 2:51 PM, "ext Behcet Sarikaya" <behcetsarikaya@yahoo.com> wrote:

>>11. In sec 4.3 I-D states:
>> "On the LMA-to-AAA interface, the LMA MAY populate the Service-
>>    Selection attribute in the Access-Request message using the service
>>    information found in the received PBU, if such mobility option was
>>    included."
>>=20
>> In which I-D or RFC is the service-information option that can be
>> carried within a PBU specified?
>
>
>
>Here, as in RFC 5779, the assumption is that the option defined in RFC
>5149 for BU can also be used in PBU.
>Is this OK?
>


Yes.. Thanks for the clarification. The service-selection mobility option
defined in RFC5149 can be used between the MAG and LMA. It would be good
to clarify in the I-D and add a reference to it as well.

-Raj


From internet-drafts@ietf.org  Wed Sep  7 13:52:49 2011
Return-Path: <internet-drafts@ietf.org>
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 BF83321F8CF2; Wed,  7 Sep 2011 13:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BT5YlBMb5UQ7; Wed,  7 Sep 2011 13:52:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3268821F8CE2; Wed,  7 Sep 2011 13:52:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110907205246.1705.51938.idtracker@ietfa.amsl.com>
Date: Wed, 07 Sep 2011 13:52:46 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-01.txt
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: Wed, 07 Sep 2011 20:52:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Proxy Mobile IPv6 Extensions to Support Flow Mobility
	Author(s)       : Carlos J. Bernardos
	Filename        : draft-ietf-netext-pmipv6-flowmob-01.txt
	Pages           : 19
	Date            : 2011-09-07

   Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
   management protocol that enables mobile devices to connect to a
   PMIPv6 domain and roam across gateways without changing their IP
   addresses.  The PMIPv6 basic specification also provides limited
   multi-homing support to multi-mode mobile devices.  The ability of
   movement of selected flows from one access technology to another is
   missing in the basic PMIPv6.  This document describes enhancements to
   the Proxy Mobile IPv6 protocol that are required to support flow
   mobility over multiple physical interfaces.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-01.txt

From cjbc@it.uc3m.es  Wed Sep  7 13:53:59 2011
Return-Path: <cjbc@it.uc3m.es>
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 3A28B21F8D13 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 pSWHkqZ5ky0M for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 13:53:58 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id E4CC021F8CE6 for <netext@ietf.org>; Wed,  7 Sep 2011 13:53:55 -0700 (PDT)
X-uc3m-safe: yes
Received: from [10.3.251.228] (unknown [64.194.250.99]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 711C9C28CF3; Wed,  7 Sep 2011 22:55:44 +0200 (CEST)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Basavaraj.Patil@nokia.com
In-Reply-To: <CA8CF297.10391%basavaraj.patil@nokia.com>
References: <CA8CF297.10391%basavaraj.patil@nokia.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-J1n2ypKkCDLsKvyaH0/f"
Organization: Universidad Carlos III de Madrid
Date: Wed, 07 Sep 2011 22:55:42 +0200
Message-ID: <1315428942.7018.35.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18372.000
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-00.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: Wed, 07 Sep 2011 20:53:59 -0000

--=-J1n2ypKkCDLsKvyaH0/f
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Raj, Julien,

Updated and submitted.

Carlos

On Wed, 2011-09-07 at 15:07 +0000, Basavaraj.Patil@nokia.com wrote:
> Hi Julien,
>=20
> I concur. I reviewed the revised I-D prior to Carlos submitting it and
> missed this one.=20
> Carlos, please remove the statement from the I-D.
>=20
> -Raj
>=20
> On 9/7/11 10:00 AM, "ext Julien Laganier" <julien.ietf@gmail.com> wrote:
>=20
> >We agreed to adopt the draft without the LMA-initiated flow movement.
> >However the draft still contains material where the LMA decide to move
> >flows, e.g.,
> >
> >"At certain point, either MN or LMA can decide to move flow Y to also
> >go through MAG1."
> >
> >I think these should be removed.
> >
> >--julien
> >
> >On Tue, Sep 6, 2011 at 6:30 AM,  <internet-drafts@ietf.org> wrote:
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories. This draft is a work item of the Network-Based Mobility
> >>Extensions Working Group of the IETF.
> >>
> >>        Title           : Proxy Mobile IPv6 Extensions to Support Flow
> >>Mobility
> >>        Author(s)       : Carlos J. Bernardos
> >>        Filename        : draft-ietf-netext-pmipv6-flowmob-00.txt
> >>        Pages           : 19
> >>        Date            : 2011-09-06
> >>
> >>   Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
> >>   management protocol that enables mobile devices to connect to a
> >>   PMIPv6 domain and roam across gateways without changing their IP
> >>   addresses.  The PMIPv6 basic specification also provides limited
> >>   multi-homing support to multi-mode mobile devices.  The ability of
> >>   movement of selected flows from one access technology to another is
> >>   missing in the basic PMIPv6.  This document describes enhancements t=
o
> >>   the Proxy Mobile IPv6 protocol that are required to support flow
> >>   mobility over multiple physical interfaces.
> >>
> >>
> >>
> >> A URL for this Internet-Draft is:
> >>=20
> >>http://www.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00=
.t
> >>xt
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> This Internet-Draft can be retrieved at:
> >>=20
> >>ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmipv6-flowmob-00.=
tx
> >>t
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> I-D-Announce@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft directories: http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >_______________________________________________
> >netext mailing list
> >netext@ietf.org
> >https://www.ietf.org/mailman/listinfo/netext
>=20
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext

--=20
Carlos Jes=FAs Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--=-J1n2ypKkCDLsKvyaH0/f
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk5n2k4ACgkQNdy6TdFwT2dLjgCgwbm6VkPYyof2MOsYTW5S9kSe
SCsAoOC/VRD5bPheM5u/aMO4JHWoZVnH
=x2i4
-----END PGP SIGNATURE-----

--=-J1n2ypKkCDLsKvyaH0/f--


From Basavaraj.Patil@nokia.com  Wed Sep  7 14:55:42 2011
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 5763421F8DCD for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 14:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.64
X-Spam-Level: 
X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 Epjbwn0bPxMR for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 14:55:41 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7E821F8DC3 for <netext@ietf.org>; Wed,  7 Sep 2011 14:55:40 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p87LvRtW028976; Thu, 8 Sep 2011 00:57:27 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Sep 2011 00:57:27 +0300
Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 23:57:26 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Wed, 7 Sep 2011 23:57:26 +0200
From: <Basavaraj.Patil@nokia.com>
To: <brian.haley@hp.com>, <sgundave@cisco.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AQHMbakgfzZ83rhZDUeFJBDNzcp++w==
Date: Wed, 7 Sep 2011 21:57:25 +0000
Message-ID: <CA8D50BD.104D3%basavaraj.patil@nokia.com>
In-Reply-To: <4E67D5CA.1080607@hp.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: <44BABC25AB0FCC41ACA5F66CD0418DDA@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Sep 2011 21:57:27.0063 (UTC) FILETIME=[21C91A70:01CC6DA9]
X-Nokia-AV: Clean
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Wed, 07 Sep 2011 21:55:42 -0000

Following up on Brian's point, the I-D says in Sec 4.1:

"
Depending on the OS support, it might
      be possible to use more than one physical interface at a time --
      so the node is simultaneously attached to different media -- or
      just to provide a fail-over mode.  Controlling the way the
      different media is used (simultaneous, sequential attachment, etc)
      is not trivial and requires additional intelligence and/or
      configuration at the logical interface device driver.  An example
      of this type of solution is the Logical interface, which is
      defined in this document, or the bonding driver (a Linux
      implementation).

"

Do you have examples of implementations wherein a logical interface is
able to use multiple physical interfaces simultaneously?

The multiple-care-of-address solution for MIP6 enables the MN to be
simultaneously attached to an HA via different interfaces. But in such a
model, you have different CoAs associated with those physical interfaces.

-Raj

On 9/7/11 3:36 PM, "ext Brian Haley" <brian.haley@hp.com> wrote:

>Hi Sri,
>
>Yes, it's been a while, I tend to only lurk on the MLs these days...
>
>More inline.
>
>On 09/07/2011 12:09 AM, Sri Gundavelli wrote:
>> Hi Brian,
>>=20
>> Long time :)
>>=20
>> Thanks for the review comment. Please see inline.
>>=20
>>=20
>>=20
>> On 9/6/11 6:36 AM, "Brian Haley" <brian.haley@hp.com> wrote:
>>=20
>>> Hi Sri,
>>=20
>>> I read this draft and had a comment on Section 6.5:
>>>
>>> 6.5.  ND Considerations for Logical Interface
>>>
>>>    The following are the Neighbor Discovery related considerations for
>>>    the logical interface.
>>>
>>>    o  Any Neighbor Discovery messages, such as Router Solicitation,
>>>       Neighbor Solicitation messages that the host sends to a multicast
>>>       destination address of link-local scope such as, all-nodes, all-
>>>       routers, solicited-node multicast group addresses, using either
>>>an
>>>       unspecified (::) source address, or a link-local address
>>>       configured on the logical interface will be replicated and
>>>       forwarded on each of the sub-interfaces under that logical
>>>       interface.  However, if the destination address is a unicast
>>>       address and if that target is known to exist on a specific sub-
>>>       interface, the message will be forwarded only on that specific
>>>       sub-interface.
>>>
>>> I'm not sure about other OSes, but since you mentioned the Linux
>>>bonding
>>> driver
>>> as an example of a Logical interface I can respond regarding that.
>>>There are
>>> configurations where you do NOT want to replicate a packet and forward
>>>it on
>>> all
>>> the underlying physical interfaces.  Doing so can cause DAD failures
>>>if any of
>>> the other interfaces see those packets sent to the all-nodes multicast
>>> address.
>>>  We noticed and fixed that back in 2008.
>>>
>>=20
>> Thanks for the info. I'm not sure, if your failure scenario is specific
>>to
>> logical interface construct, or if you are referring to a general case
>>of
>> packet replication. For the case of logical interface construct,
>> essentially, we are presenting a single interface to the host stack, but
>> underneath there are multiple physical interfaces. Some of the
>>operations
>> such as router discovery when initiated on the logical interface, should
>> translate to performing this operation on multiple physical interfaces.
>>=20
>> For example, Sending a RS message on a LI abstracting WLAN and WiMAX
>>should
>> result in sending that RS message on both the paths. I'm sure, this can
>>be
>> achieved in multiple ways, but the external behavior what needs to be
>>seen
>> is the generation of two RS packets on those two sub-interfaces. May be
>>if
>> you can provide more info on your failure case, we can structure this
>>right.
>> But, that was our intent.
>
>I can understand the abstraction, and why you would want to send some
>messages
>on all the underlying interfaces.
>
>The Linux bonding driver typically isn't used in this way though, it's
>more of
>an HA mechanism to attach a system to a switch, or set of switches, via
>multiple
>paths.  Usually just a group of ports on the top-of-rack switch, for
>example in
>802.3ad mode.  All physical interfaces need to be in the same network.
>
>I've never seen it used where there are multiple types of physical
>interfaces in
>different networks in the bond, not even sure if that's supported...
>
>The failure in question is that in some operating modes you can see
>broadcasts
>sent from other members of the bond (not 802.3ad of course), and that
>causes
>problems, so we create workarounds by trapping them and only transmitting
>on one
>of the interfaces.  That probably isn't going to happen in your scenario.
>
>Maybe the easiest solution is to just remove the Linux reference, I
>probably
>wouldn't have noticed otherwise :)
>
>>> BTW, I'm not subscribed to net-next, so haven't seen any previous
>>>discussion
>>> on
>>> the draft.
>>=20
>> Will surely help us, if you are on the list.
>
>I'll try if the bandwidth is low...
>
>-Brian
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext


From sgundave@cisco.com  Wed Sep  7 16:18:48 2011
Return-Path: <sgundave@cisco.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 C389321F8C85 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 16:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Level: 
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.221,  BAYES_00=-2.599]
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 HIdiYp4gcpZ0 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 16:18:48 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2851921F8C7C for <netext@ietf.org>; Wed,  7 Sep 2011 16:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1611; q=dns/txt; s=iport; t=1315437639; x=1316647239; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/rM8gvGhtxQn9MjoeLkm/Rxz3Ora+WyccPsmVVZfHP4=; b=Gedh8ZuRtYOd5oCrs7MlWhyupmI9Tqo6/huNPds2MF/Fl7B/xJSEzbyH 8p2yfaXpFtefOmFTPkn4MoX8eJuVRJ09jU9P3rVqtugzPWcGjDB9GnwbA mRQqDluXASzcqvlsfEs/+LN0atW+R0+o7GP+cLDyCouI073Nb5s8GzIfA g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJb7Z06rRDoH/2dsb2JhbABDp3J4gUYBAQEBAgESAScCATwFDQEIgR0BAQQOBRsHh1OZVgGeK4ZrBIdsi0aFG4wb
X-IronPort-AV: E=Sophos;i="4.68,347,1312156800";  d="scan'208";a="799737"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Sep 2011 23:20:37 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p87NKatU023275; Wed, 7 Sep 2011 23:20:37 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Sep 2011 16:20:36 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Wed,  7 Sep 2011 23:20:35 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Wed, 07 Sep 2011 16:20:35 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Brian Haley <brian.haley@hp.com>
Message-ID: <CA8D4A53.27BF3%sgundave@cisco.com>
Thread-Topic: I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AcxttL7T3fQHJPHmq0S8DTZB2TsBoA==
In-Reply-To: <4E67D5CA.1080607@hp.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2011 23:20:36.0177 (UTC) FILETIME=[BF877C10:01CC6DB4]
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Wed, 07 Sep 2011 23:18:48 -0000

Hi Brian,

Thanks for your response.



On 9/7/11 1:36 PM, "Brian Haley" <brian.haley@hp.com> wrote:

> Hi Sri,
> 
> Yes, it's been a while, I tend to only lurk on the MLs these days...
> 
> More inline.
> 
> On 09/07/2011 12:09 AM, Sri Gundavelli wrote:

> 
> I can understand the abstraction, and why you would want to send some messages
> on all the underlying interfaces.
> 
> The Linux bonding driver typically isn't used in this way though, it's more of
> an HA mechanism to attach a system to a switch, or set of switches, via
> multiple
> paths.  Usually just a group of ports on the top-of-rack switch, for example
> in
> 802.3ad mode.  All physical interfaces need to be in the same network.
> 
> I've never seen it used where there are multiple types of physical interfaces
> in
> different networks in the bond, not even sure if that's supported...
> 
> The failure in question is that in some operating modes you can see broadcasts
> sent from other members of the bond (not 802.3ad of course), and that causes
> problems, so we create workarounds by trapping them and only transmitting on
> one
> of the interfaces.  That probably isn't going to happen in your scenario.
> 
> Maybe the easiest solution is to just remove the Linux reference, I probably
> wouldn't have noticed otherwise :)
> 

Thanks for the info about the issue with that usage. I understand what you
are saying. We will try to remove the bonding driver example and leave it
with the requirement, expected external behavior, independent of the
specific approach/OS.


Regards
Sri



From sgundave@cisco.com  Wed Sep  7 16:19:27 2011
Return-Path: <sgundave@cisco.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 5F4BE21F8C85 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 16:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.816
X-Spam-Level: 
X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599]
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 gDJb6IuHOkc6 for <netext@ietfa.amsl.com>; Wed,  7 Sep 2011 16:19:26 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BD52E21F8C7C for <netext@ietf.org>; Wed,  7 Sep 2011 16:19:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1759; q=dns/txt; s=iport; t=1315437677; x=1316647277; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=VtfDq/FA8DX/R4UsvhQAYrYhBjffsU8CFEOz6Qo2JpI=; b=Z4JVS/1OQ2wk0TP5jX0JqXn1SA2ikvagLWrgN2JVq6JXUaIHsxK7JloY NW+33PNHUTQF1pL/iKjeWxNdCLDNUrV+TZOwqkk8a17aEOUUz3onRhgpS 5GwLrGmcBHDxF8FqL9EAUqHHFjx+JePS3LXshBIKsK+Y0uJZX99tiOpsq 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJb7Z06rRDoH/2dsb2JhbABDp3J4gUYBAQEBAgESAScCATUHBQ0BCIEdAgQBDQUbB4dTBJlSAZ4rhmsEh2yLRoUbjBs
X-IronPort-AV: E=Sophos;i="4.68,347,1312156800";  d="scan'208";a="799564"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 07 Sep 2011 23:21:15 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p87NLFJb023762; Wed, 7 Sep 2011 23:21:15 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 7 Sep 2011 16:21:15 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Wed,  7 Sep 2011 23:21:14 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Wed, 07 Sep 2011 16:21:13 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: <Basavaraj.Patil@nokia.com>, <brian.haley@hp.com>
Message-ID: <CA8D4A79.27BF5%sgundave@cisco.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AQHMbakgfzZ83rhZDUeFJBDNzcp++5VCjljv
In-Reply-To: <CA8D50BD.104D3%basavaraj.patil@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 07 Sep 2011 23:21:15.0442 (UTC) FILETIME=[D6EED920:01CC6DB4]
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Wed, 07 Sep 2011 23:19:27 -0000

Hi Raj:



On 9/7/11 2:57 PM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
wrote:

> 
> Following up on Brian's point, the I-D says in Sec 4.1:
> 
> "
> Depending on the OS support, it might
>       be possible to use more than one physical interface at a time --
>       so the node is simultaneously attached to different media -- or
>       just to provide a fail-over mode.  Controlling the way the
>       different media is used (simultaneous, sequential attachment, etc)
>       is not trivial and requires additional intelligence and/or
>       configuration at the logical interface device driver.  An example
>       of this type of solution is the Logical interface, which is
>       defined in this document, or the bonding driver (a Linux
>       implementation).
> 
> "
> 
> Do you have examples of implementations wherein a logical interface is
> able to use multiple physical interfaces simultaneously?
> 

I can think of the Linux bridge control interface, where the physical
interface are put in a bridge mode.

Since you asked :)

http://www.mendeley.com/research/applicability-virtual-interface-intertechno
logy-handoffs-proxy-mobile-ipv6/


> The multiple-care-of-address solution for MIP6 enables the MN to be
> simultaneously attached to an HA via different interfaces. But in such a
> model, you have different CoAs associated with those physical interfaces.
> 

Slight difference though. In the MCoA model, the HoA is bound to virtual
interface, however the tunnel is established from the IP addresses
associated with a physical interface. The relation between the two being the
tunnel providing the routing path for the home address on the virtual
interface.

Regards
Sri





From Basavaraj.Patil@nokia.com  Thu Sep  8 08:59:39 2011
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 323C521F85BB for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 08:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.639
X-Spam-Level: 
X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 CXwBm39iFAAZ for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 08:59:38 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B721F85B5 for <netext@ietf.org>; Thu,  8 Sep 2011 08:59:37 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p88G1PQB014781; Thu, 8 Sep 2011 19:01:26 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Sep 2011 19:01:21 +0300
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 8 Sep 2011 18:01:20 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Thu, 8 Sep 2011 18:01:20 +0200
From: <Basavaraj.Patil@nokia.com>
To: <sgundave@cisco.com>, <ryuji@us.toyota-itc.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AQHMbakgfzZ83rhZDUeFJBDNzcp++5VCjljvgACiFQA=
Date: Thu, 8 Sep 2011 16:01:19 +0000
Message-ID: <CA8E4F30.10555%basavaraj.patil@nokia.com>
In-Reply-To: <CA8D4A79.27BF5%sgundave@cisco.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.19]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <01F6685D9BCFC943887D41997AAE272E@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Sep 2011 16:01:21.0038 (UTC) FILETIME=[8D0E2AE0:01CC6E40]
X-Nokia-AV: Clean
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Thu, 08 Sep 2011 15:59:39 -0000

Sri,

Thanks for the reference.
A few questions from the configuration of the MN in the experiment
mentioned in the paper:

1. Are multiple interfaces active at the same time (eth0 and eth1)?

2. How does the bridge interface handle the scenario when you have
multiple interfaces simultaneously active and operational? From a PMIP6
standpoint, does the MN (assuming attachment to different MAGs) obtain
different prefixes from the MAGs?

3. How does SLAAC work when the bridge IF is used? Given that you have
different EUI48s associated with Eth0 and Eth1, what does the br IF use
for address config?

-Raj

On 9/7/11 6:21 PM, "ext Sri Gundavelli" <sgundave@cisco.com> wrote:

>Hi Raj:
>
>
>
>On 9/7/11 2:57 PM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
>wrote:
>
>>=20
>> Following up on Brian's point, the I-D says in Sec 4.1:
>>=20
>> "
>> Depending on the OS support, it might
>>       be possible to use more than one physical interface at a time --
>>       so the node is simultaneously attached to different media -- or
>>       just to provide a fail-over mode.  Controlling the way the
>>       different media is used (simultaneous, sequential attachment, etc)
>>       is not trivial and requires additional intelligence and/or
>>       configuration at the logical interface device driver.  An example
>>       of this type of solution is the Logical interface, which is
>>       defined in this document, or the bonding driver (a Linux
>>       implementation).
>>=20
>> "
>>=20
>> Do you have examples of implementations wherein a logical interface is
>> able to use multiple physical interfaces simultaneously?
>>=20
>
>I can think of the Linux bridge control interface, where the physical
>interface are put in a bridge mode.
>
>Since you asked :)
>
>http://www.mendeley.com/research/applicability-virtual-interface-intertech
>no
>logy-handoffs-proxy-mobile-ipv6/
>
>
>> The multiple-care-of-address solution for MIP6 enables the MN to be
>> simultaneously attached to an HA via different interfaces. But in such a
>> model, you have different CoAs associated with those physical
>>interfaces.
>>=20
>
>Slight difference though. In the MCoA model, the HoA is bound to virtual
>interface, however the tunnel is established from the IP addresses
>associated with a physical interface. The relation between the two being
>the
>tunnel providing the routing path for the home address on the virtual
>interface.
>
>Regards
>Sri
>
>
>
>


From julien.ietf@gmail.com  Thu Sep  8 09:02:33 2011
Return-Path: <julien.ietf@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 4908821F87FA for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 09:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.518
X-Spam-Level: 
X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081,  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 9lou9hoSUQls for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 09:02:32 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5FA21F85EC for <netext@ietf.org>; Thu,  8 Sep 2011 09:02:32 -0700 (PDT)
Received: by ewy19 with SMTP id 19so447771ewy.31 for <netext@ietf.org>; Thu, 08 Sep 2011 09:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=/LbOaQERDClaA8X+hV8uB7jAgx+5FWGelzfWVq/qCR8=; b=qx1wqTo4HizhuPjIgyxpLVKs3tGqFF1A0Xu50mZl5LcDk08vgI2E3DPGqf4+WGmJrF 9spfazgItrp7zixksdgOBSU2t2Q/NRjamgWCKWWBek6SnueCF8Amz3aPA29OadGVbCGl jOZmhfQQ+YeRHxKw7NV+8PZIosaTTOf6cXNcY=
MIME-Version: 1.0
Received: by 10.52.75.41 with SMTP id z9mr920387vdv.93.1315497863831; Thu, 08 Sep 2011 09:04:23 -0700 (PDT)
Received: by 10.52.165.229 with HTTP; Thu, 8 Sep 2011 09:04:23 -0700 (PDT)
In-Reply-To: <20110905161510.5234.57634.idtracker@ietfa.amsl.com>
References: <20110905161510.5234.57634.idtracker@ietfa.amsl.com>
Date: Thu, 8 Sep 2011 09:04:23 -0700
Message-ID: <CAE_dhjvw1iS=+Yd=p8mdh3Lnhv1dubQBjg+9uuHGJNJSk+hJQw@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: netext@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Thu, 08 Sep 2011 16:02:33 -0000

I thought that we already discussed this and concluded it wasn't appropriat=
e?

6.3.  Supported Link models for a logical interface

   The sub-interfaces of a logical interface can be bound to a point-to-
   point or a shared link (Example: LTE and WLAN).  The logical
   interface appears as a shared-link to the applications, and adapts to
   the link model of the sub-interface for packet communication.  For
   example, when transmitting a packet on a sub-interface which is
   attached to a p2p link, the transmission conforms to the p2p link
   model and when transmitting on a sub-interface attached to a shared
   link, the transmission conforms to the shared link model.

   Based on the link to which the sub-interface is attached to, the
   layer-2 resolutions may or may not be needed.  If the interface is
   bound to a P2P link with PPP running, there will not be any link-
   layer resolutions in the form of ARP/ND messages.  However, if the
   interface is bound to a shared link such as Ethernet, there will be
   ND resolutions.  The logical interface implementation has to maintain
   the required link model and the associated state for each sub-
   interface.

On Mon, Sep 5, 2011 at 9:15 AM,  <internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the Network-Based Mobility Extensions W=
orking Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for =
multi-mode IP Hosts
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Telemaco Melia
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sri Gundavelli
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interf=
ace-support-03.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-05
>
> =A0 A Logical Interface is a software semantic internal to the host
> =A0 operating system. =A0This semantic is available in all popular
> =A0 operating systems and is used in various protocol implementations.
> =A0 The Logical Interface support is required on the mobile node
> =A0 operating in a Proxy Mobile IPv6 domain, for leveraging various
> =A0 network-based mobility management features such as inter-technology
> =A0 handoffs, multihoming and flow mobility support. =A0This document
> =A0 explains the operational details of Logical Interface construct and
> =A0 the specifics on how the link-layer implementations hide the physical
> =A0 interfaces from the IP stack and from the network nodes on the
> =A0 attached access networks. =A0Furthermore, this document identifies th=
e
> =A0 applicability of this approach to various link-layer technologies and
> =A0 analyzes the issues around it when used in context with various
> =A0 mobility management features.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-s=
upport-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-su=
pport-03.txt
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>

From sgundave@cisco.com  Thu Sep  8 21:29:32 2011
Return-Path: <sgundave@cisco.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 1222221F8AAA for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 21:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599]
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 FeDk3YbHcsyo for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 21:29:31 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77121F8B1E for <netext@ietf.org>; Thu,  8 Sep 2011 21:29:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1543; q=dns/txt; s=iport; t=1315542685; x=1316752285; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=qLP/89/ypJDoUqra8Go8mlnzc7fy3vZjucAklvPuiWg=; b=UIDdOxNqC0+FLso9Pta91wbPIb+5GMN0V3/Got8dNvnjcMTfMgdl3Y3L jw84aPWmNRkb9NehZqmDiJHPqIsSZqeaKn0qZKxrVkep0AgUmbeniCAFC bY6BIjZ5pi3rvucji+w6oSHsScDQCdX5ph1HRvyze0Y3BGNWSZshxniPH A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAKiVaU6rRDoG/2dsb2JhbABCqAV4gUYBAQEBAgESAScCATwFDQEIgR0CBAENBSKHU5ldAZ5Bhm0Eh2yLR4UbjBo
X-IronPort-AV: E=Sophos;i="4.68,354,1312156800";  d="scan'208";a="1081606"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 09 Sep 2011 04:31:25 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p894VPQc008018; Fri, 9 Sep 2011 04:31:25 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Sep 2011 21:31:25 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Fri,  9 Sep 2011 04:31:24 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Thu, 08 Sep 2011 21:31:18 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: <Basavaraj.Patil@nokia.com>, <ryuji@us.toyota-itc.com>
Message-ID: <CA8EE4A6.27E7B%sgundave@cisco.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AQHMbakgfzZ83rhZDUeFJBDNzcp++5VCjljvgACiFQCAAUbjIw==
In-Reply-To: <CA8E4F30.10555%basavaraj.patil@nokia.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2011 04:31:25.0069 (UTC) FILETIME=[558C53D0:01CC6EA9]
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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, 09 Sep 2011 04:29:32 -0000

Hi Raj:




On 9/8/11 9:01 AM, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
wrote:

> 
> Sri,
> 
> Thanks for the reference.
> A few questions from the configuration of the MN in the experiment
> mentioned in the paper:
> 
> 1. Are multiple interfaces active at the same time (eth0 and eth1)?
> 

Yes. Both the scenarios, keeping or both the interfaces active, was tested
by Sawako. 


> 2. How does the bridge interface handle the scenario when you have
> multiple interfaces simultaneously active and operational? From a PMIP6
> standpoint, does the MN (assuming attachment to different MAGs) obtain
> different prefixes from the MAGs?
> 

The brctl mode puts the interfaces in a bridge mode. For all practical
purposes the virtual interface that is configured aboves see's both the
prefixes as prefixes hosted on a link associated with that virtual
interface.



> 3. How does SLAAC work when the bridge IF is used? Given that you have
> different EUI48s associated with Eth0 and Eth1, what does the br IF use
> for address config?
> 

This is a good question. I remember some discussion on this, now I don't
remember. I have to ask Sawako, what is the identifier that she noticed in
her lab, if its a generated id, or if was of one of the physical interface.
We will check on that.

But, it was tested by a Japanese student under Ryuji, and not by me. So no
short cuts, no vaporware, its real and you should be rest assured, it really
worked like spot less :)



Regards
Sri





From sgundave@cisco.com  Thu Sep  8 21:32:37 2011
Return-Path: <sgundave@cisco.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 3303E21F8B04 for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 21:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 DWJbTdXQ2+LX for <netext@ietfa.amsl.com>; Thu,  8 Sep 2011 21:32:36 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DDF7521F8B03 for <netext@ietf.org>; Thu,  8 Sep 2011 21:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=4136; q=dns/txt; s=iport; t=1315542863; x=1316752463; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ASfGvs2Tp6b66m3OtjkqBtp4gkXCWhmuWAeBKbaiTbE=; b=QFT9+8LyW1i78cDLNU4VyMM83spS4pe3bJr+xSCsvZELyXok4KcCVflA pQ5x8gKTOrJ8wYurEtd7SQTZs5LiU6IbnmAQrtIK0lgxbEEDrInWcj1zD XD9BpPNtfbywmhBeyRk2zrTGDMYfrAHDx64H65/Tu3d54MfAvkFgmr5tw I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOuWaU6rRDoH/2dsb2JhbABCpwh9eIFGAQEBAQIBAQEBDwEpATEQDQEIGE8GMAEBBAESCRmHUwSZWAGeQYZtBIc9L4tHhRuEZ4cz
X-IronPort-AV: E=Sophos;i="4.68,354,1312156800";  d="scan'208";a="1082816"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 09 Sep 2011 04:34:21 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p894YLZ2031736; Fri, 9 Sep 2011 04:34:21 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 8 Sep 2011 21:34:21 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Fri,  9 Sep 2011 04:34:21 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Thu, 08 Sep 2011 21:34:17 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Julien Laganier <julien.ietf@gmail.com>, <netext@ietf.org>
Message-ID: <CA8EE559.27E7F%sgundave@cisco.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: AcxuqbwGKIQpDXPM4ky+XZofJzGQwg==
In-Reply-To: <CAE_dhjvw1iS=+Yd=p8mdh3Lnhv1dubQBjg+9uuHGJNJSk+hJQw@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 09 Sep 2011 04:34:21.0486 (UTC) FILETIME=[BEB36CE0:01CC6EA9]
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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, 09 Sep 2011 04:32:37 -0000

Hi Julien,

I know we discussed about this during the meeting, on wow the logical
interface should appear to the applications. You preferred to not to state
any thing. I was ok with that, I just wanted to check the socket API, and i=
f
there is any API which provides the type (p2p or non-p2p), based on that we
can resolve this. Let me work on this.



Regards
Sri



=20



On 9/8/11 9:04 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:

> I thought that we already discussed this and concluded it wasn't appropri=
ate?
>=20
> 6.3.  Supported Link models for a logical interface
>=20
>    The sub-interfaces of a logical interface can be bound to a point-to-
>    point or a shared link (Example: LTE and WLAN).  The logical
>    interface appears as a shared-link to the applications, and adapts to
>    the link model of the sub-interface for packet communication.  For
>    example, when transmitting a packet on a sub-interface which is
>    attached to a p2p link, the transmission conforms to the p2p link
>    model and when transmitting on a sub-interface attached to a shared
>    link, the transmission conforms to the shared link model.
>=20
>    Based on the link to which the sub-interface is attached to, the
>    layer-2 resolutions may or may not be needed.  If the interface is
>    bound to a P2P link with PPP running, there will not be any link-
>    layer resolutions in the form of ARP/ND messages.  However, if the
>    interface is bound to a shared link such as Ethernet, there will be
>    ND resolutions.  The logical interface implementation has to maintain
>    the required link model and the associated state for each sub-
>    interface.
>=20
> On Mon, Sep 5, 2011 at 9:15 AM,  <internet-drafts@ietf.org> wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Network-Based Mobility
>> Extensions Working Group of the IETF.
>>=20
>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for multi-mode IP Hos=
ts
>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Telemaco Melia
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sri Gundavelli
>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interface-support-03.=
txt
>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26
>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-05
>>=20
>> =A0 A Logical Interface is a software semantic internal to the host
>> =A0 operating system. =A0This semantic is available in all popular
>> =A0 operating systems and is used in various protocol implementations.
>> =A0 The Logical Interface support is required on the mobile node
>> =A0 operating in a Proxy Mobile IPv6 domain, for leveraging various
>> =A0 network-based mobility management features such as inter-technology
>> =A0 handoffs, multihoming and flow mobility support. =A0This document
>> =A0 explains the operational details of Logical Interface construct and
>> =A0 the specifics on how the link-layer implementations hide the physical
>> =A0 interfaces from the IP stack and from the network nodes on the
>> =A0 attached access networks. =A0Furthermore, this document identifies the
>> =A0 applicability of this approach to various link-layer technologies and
>> =A0 analyzes the issues around it when used in context with various
>> =A0 mobility management features.
>>=20
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-=
suppo
>> rt-03.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-s=
uppor
>> t-03.txt
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>>=20
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext


From julien.ietf@gmail.com  Fri Sep  9 09:33:50 2011
Return-Path: <julien.ietf@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 9CF9621F8715 for <netext@ietfa.amsl.com>; Fri,  9 Sep 2011 09:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.517
X-Spam-Level: 
X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082,  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 AIVjeaA91f7e for <netext@ietfa.amsl.com>; Fri,  9 Sep 2011 09:33:50 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D183521F850B for <netext@ietf.org>; Fri,  9 Sep 2011 09:33:42 -0700 (PDT)
Received: by wwf5 with SMTP id 5so888918wwf.13 for <netext@ietf.org>; Fri, 09 Sep 2011 09:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I0Yhc49zDoW0txHai/ni4PaQn6xexrf99ajbuEBPHCA=; b=SG2jlVpuhoRtoDNTk7O38QymrwM19ME+dNrbxXuFTjsE1ExI9aiT6Vb0PY/C5saM0d EO/hmU4IEsXRfOrqW04CMeO1LLhcaBUxTxs8wyu58HIG9C+STPLaIgIo7ZEM/vqCgBY2 iaGfCrFzseedJgY7nrvAqMJyTp99jg8kaHTcM=
MIME-Version: 1.0
Received: by 10.227.151.66 with SMTP id b2mr2224904wbw.44.1315586134429; Fri, 09 Sep 2011 09:35:34 -0700 (PDT)
Received: by 10.227.27.141 with HTTP; Fri, 9 Sep 2011 09:35:34 -0700 (PDT)
In-Reply-To: <CA8EE559.27E7F%sgundave@cisco.com>
References: <CAE_dhjvw1iS=+Yd=p8mdh3Lnhv1dubQBjg+9uuHGJNJSk+hJQw@mail.gmail.com> <CA8EE559.27E7F%sgundave@cisco.com>
Date: Fri, 9 Sep 2011 09:35:34 -0700
Message-ID: <CAE_dhjsPkif2AzdUdOEUw1=DjWrZ0vHw58EFvjtdoVjRmHLpwg@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Sri Gundavelli <sgundave@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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, 09 Sep 2011 16:33:50 -0000

We have discussed this extensively during meetings and on list and
this was the proposal on the table:

http://www.ietf.org/mail-archive/web/netext/current/msg01944.html

--julien

On Thu, Sep 8, 2011 at 9:34 PM, Sri Gundavelli <sgundave@cisco.com> wrote:
> Hi Julien,
>
> I know we discussed about this during the meeting, on wow the logical
> interface should appear to the applications. You preferred to not to stat=
e
> any thing. I was ok with that, I just wanted to check the socket API, and=
 if
> there is any API which provides the type (p2p or non-p2p), based on that =
we
> can resolve this. Let me work on this.
>
>
>
> Regards
> Sri
>
>
>
>
>
>
>
> On 9/8/11 9:04 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:
>
>> I thought that we already discussed this and concluded it wasn't appropr=
iate?
>>
>> 6.3. =A0Supported Link models for a logical interface
>>
>> =A0 =A0The sub-interfaces of a logical interface can be bound to a point=
-to-
>> =A0 =A0point or a shared link (Example: LTE and WLAN). =A0The logical
>> =A0 =A0interface appears as a shared-link to the applications, and adapt=
s to
>> =A0 =A0the link model of the sub-interface for packet communication. =A0=
For
>> =A0 =A0example, when transmitting a packet on a sub-interface which is
>> =A0 =A0attached to a p2p link, the transmission conforms to the p2p link
>> =A0 =A0model and when transmitting on a sub-interface attached to a shar=
ed
>> =A0 =A0link, the transmission conforms to the shared link model.
>>
>> =A0 =A0Based on the link to which the sub-interface is attached to, the
>> =A0 =A0layer-2 resolutions may or may not be needed. =A0If the interface=
 is
>> =A0 =A0bound to a P2P link with PPP running, there will not be any link-
>> =A0 =A0layer resolutions in the form of ARP/ND messages. =A0However, if =
the
>> =A0 =A0interface is bound to a shared link such as Ethernet, there will =
be
>> =A0 =A0ND resolutions. =A0The logical interface implementation has to ma=
intain
>> =A0 =A0the required link model and the associated state for each sub-
>> =A0 =A0interface.
>>
>> On Mon, Sep 5, 2011 at 9:15 AM, =A0<internet-drafts@ietf.org> wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Network-Based Mobility
>>> Extensions Working Group of the IETF.
>>>
>>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support fo=
r multi-mode IP Hosts
>>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Telemaco Melia
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sri Gundavelli
>>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-inte=
rface-support-03.txt
>>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26
>>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-05
>>>
>>> =A0 A Logical Interface is a software semantic internal to the host
>>> =A0 operating system. =A0This semantic is available in all popular
>>> =A0 operating systems and is used in various protocol implementations.
>>> =A0 The Logical Interface support is required on the mobile node
>>> =A0 operating in a Proxy Mobile IPv6 domain, for leveraging various
>>> =A0 network-based mobility management features such as inter-technology
>>> =A0 handoffs, multihoming and flow mobility support. =A0This document
>>> =A0 explains the operational details of Logical Interface construct and
>>> =A0 the specifics on how the link-layer implementations hide the physic=
al
>>> =A0 interfaces from the IP stack and from the network nodes on the
>>> =A0 attached access networks. =A0Furthermore, this document identifies =
the
>>> =A0 applicability of this approach to various link-layer technologies a=
nd
>>> =A0 analyzes the issues around it when used in context with various
>>> =A0 mobility management features.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface=
-suppo
>>> rt-03.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-=
suppor
>>> t-03.txt
>>> _______________________________________________
>>> netext mailing list
>>> netext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>>>
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>
>

From Basavaraj.Patil@nokia.com  Fri Sep  9 15:23:10 2011
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 B20E021F899D for <netext@ietfa.amsl.com>; Fri,  9 Sep 2011 15:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.638
X-Spam-Level: 
X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 WWCcxAK06DA8 for <netext@ietfa.amsl.com>; Fri,  9 Sep 2011 15:23:10 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id DE74B21F8564 for <netext@ietf.org>; Fri,  9 Sep 2011 15:23:09 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p89MP45P031749; Sat, 10 Sep 2011 01:25:04 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 10 Sep 2011 01:25:04 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 10 Sep 2011 00:25:04 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Sat, 10 Sep 2011 00:24:51 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Review of I-D: draft-ietf-netext-redirect-10
Thread-Index: AQHMbz9K1OOVFC+yBEKKB/AJ5YQGcQ==
Date: Fri, 9 Sep 2011 22:24:50 +0000
Message-ID: <CA8FFC68.108EC%basavaraj.patil@nokia.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.28]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E3754EF31F29F840B87514897CB01DDC@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Sep 2011 22:25:04.0379 (UTC) FILETIME=[5272F4B0:01CC6F3F]
X-Nokia-AV: Clean
Cc: draft-ietf-netext-redirect@tools.ietf.org
Subject: [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, 09 Sep 2011 22:23:10 -0000

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.

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)

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.

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.

-Raj


From sgundave@cisco.com  Sun Sep 11 11:15:04 2011
Return-Path: <sgundave@cisco.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 55BFE21F889A for <netext@ietfa.amsl.com>; Sun, 11 Sep 2011 11:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level: 
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 TX-2uEk5Xar3 for <netext@ietfa.amsl.com>; Sun, 11 Sep 2011 11:15:03 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9751521F888A for <netext@ietf.org>; Sun, 11 Sep 2011 11:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5097; q=dns/txt; s=iport; t=1315765025; x=1316974625; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=HLMZrhtSdgYmMjv4AmwMMv1nHAMC/+08BOKWELPWHf8=; b=IyxeX0nOOecx4b6g5Nq2YM1O25ApS1a3NfGcPqN/TO2gcjqpI4nouWsJ 4WgwAVeNpGtLjyACRDGb42I0u71ZtS9LYNLYan6Zk6Vp6lGLiqmrzT3mL oJIseGLeL4f7i8A66VG6BghEhC8NsKfVjdEBtw7iW4NLwJY58czAn9jJ0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjgGADz6bE6rRDoG/2dsb2JhbABBoV+FPH94gVIBAQQBAQEBDwEpATELBQ0BCBhPBjABAQQOBQkZh1UElzgBnGCGbgSHPi+LToUghGiHNg
X-IronPort-AV: E=Sophos;i="4.68,364,1312156800";  d="scan'208";a="1436090"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Sep 2011 18:17:04 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8BIH4GB006635; Sun, 11 Sep 2011 18:17:04 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 11 Sep 2011 11:17:04 -0700
Received: from 10.32.246.213 ([10.32.246.213]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Sun, 11 Sep 2011 18:17:03 +0000
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Sun, 11 Sep 2011 11:16:59 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Julien Laganier <julien.ietf@gmail.com>
Message-ID: <CA92492B.280FF%sgundave@cisco.com>
Thread-Topic: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
Thread-Index: Acxwrv7lEKIN0cvaq0WQEsFjAeMooA==
In-Reply-To: <CAE_dhjsPkif2AzdUdOEUw1=DjWrZ0vHw58EFvjtdoVjRmHLpwg@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 11 Sep 2011 18:17:04.0378 (UTC) FILETIME=[021A7DA0:01CC70AF]
Cc: netext@ietf.org
Subject: Re: [netext] I-D Action: draft-ietf-netext-logical-interface-support-03.txt
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: Sun, 11 Sep 2011 18:15:04 -0000

Yes. There is the proposed text from you. Thanks !

There was also a comment on ND layer considerations when presenting multipl=
e
peers on the other side of the p2p link as a single peer. Else, it should b=
e
fine.=20


Regards
Sri



On 9/9/11 9:35 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:

> We have discussed this extensively during meetings and on list and
> this was the proposal on the table:
>=20
> http://www.ietf.org/mail-archive/web/netext/current/msg01944.html
>=20
> --julien
>=20
> On Thu, Sep 8, 2011 at 9:34 PM, Sri Gundavelli <sgundave@cisco.com> wrote=
:
>> Hi Julien,
>>=20
>> I know we discussed about this during the meeting, on wow the logical
>> interface should appear to the applications. You preferred to not to sta=
te
>> any thing. I was ok with that, I just wanted to check the socket API, an=
d if
>> there is any API which provides the type (p2p or non-p2p), based on that=
 we
>> can resolve this. Let me work on this.
>>=20
>>=20
>>=20
>> Regards
>> Sri
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 9/8/11 9:04 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:
>>=20
>>> I thought that we already discussed this and concluded it wasn't
>>> appropriate?
>>>=20
>>> 6.3. =A0Supported Link models for a logical interface
>>>=20
>>> =A0 =A0The sub-interfaces of a logical interface can be bound to a point-to=
-
>>> =A0 =A0point or a shared link (Example: LTE and WLAN). =A0The logical
>>> =A0 =A0interface appears as a shared-link to the applications, and adapts t=
o
>>> =A0 =A0the link model of the sub-interface for packet communication. =A0For
>>> =A0 =A0example, when transmitting a packet on a sub-interface which is
>>> =A0 =A0attached to a p2p link, the transmission conforms to the p2p link
>>> =A0 =A0model and when transmitting on a sub-interface attached to a shared
>>> =A0 =A0link, the transmission conforms to the shared link model.
>>>=20
>>> =A0 =A0Based on the link to which the sub-interface is attached to, the
>>> =A0 =A0layer-2 resolutions may or may not be needed. =A0If the interface is
>>> =A0 =A0bound to a P2P link with PPP running, there will not be any link-
>>> =A0 =A0layer resolutions in the form of ARP/ND messages. =A0However, if the
>>> =A0 =A0interface is bound to a shared link such as Ethernet, there will be
>>> =A0 =A0ND resolutions. =A0The logical interface implementation has to maintai=
n
>>> =A0 =A0the required link model and the associated state for each sub-
>>> =A0 =A0interface.
>>>=20
>>> On Mon, Sep 5, 2011 at 9:15 AM, =A0<internet-drafts@ietf.org> wrote:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories. This draft is a work item of the Network-Based Mobility
>>>> Extensions Working Group of the IETF.
>>>>=20
>>>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Logical Interface Support for multi-mode IP H=
osts
>>>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Telemaco Melia
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sri Gundavelli
>>>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-netext-logical-interface-support-0=
3.txt
>>>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26
>>>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-09-05
>>>>=20
>>>> =A0 A Logical Interface is a software semantic internal to the host
>>>> =A0 operating system. =A0This semantic is available in all popular
>>>> =A0 operating systems and is used in various protocol implementations.
>>>> =A0 The Logical Interface support is required on the mobile node
>>>> =A0 operating in a Proxy Mobile IPv6 domain, for leveraging various
>>>> =A0 network-based mobility management features such as inter-technology
>>>> =A0 handoffs, multihoming and flow mobility support. =A0This document
>>>> =A0 explains the operational details of Logical Interface construct and
>>>> =A0 the specifics on how the link-layer implementations hide the physica=
l
>>>> =A0 interfaces from the IP stack and from the network nodes on the
>>>> =A0 attached access networks. =A0Furthermore, this document identifies the
>>>> =A0 applicability of this approach to various link-layer technologies an=
d
>>>> =A0 analyzes the issues around it when used in context with various
>>>> =A0 mobility management features.
>>>>=20
>>>>=20
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interfac=
e-sup
>>>> po
>>>> rt-03.txt
>>>>=20
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>=20
>>>> This Internet-Draft can be retrieved at:
>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface=
-supp
>>>> or
>>>> t-03.txt
>>>> _______________________________________________
>>>> netext mailing list
>>>> netext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>=20
>>> _______________________________________________
>>> netext mailing list
>>> netext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>>=20
>>=20


From jouni.nospam@gmail.com  Mon Sep 12 04:08:34 2011
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> <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:

>=20
> My WGLC review comments on Rev 10 of the I-D: =
draft-ietf-netext-redirect
>=20
> 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


>=20
> -Raj
>=20
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext


From Basavaraj.Patil@nokia.com  Mon Sep 12 06:27:11 2011
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 93A6E21F85A8 for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 06:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.67
X-Spam-Level: 
X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 u0VywwboTIS9 for <netext@ietfa.amsl.com>; Mon, 12 Sep 2011 06:27:11 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF9721F85B5 for <netext@ietf.org>; Mon, 12 Sep 2011 06:27:10 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8CDT0Do005272; Mon, 12 Sep 2011 16:29:11 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 12 Sep 2011 16:29:03 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 12 Sep 2011 15:29:03 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Mon, 12 Sep 2011 15:29:02 +0200
From: <Basavaraj.Patil@nokia.com>
To: <jouni.nospam@gmail.com>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-redirect-10
Thread-Index: AQHMbz9K1OOVFC+yBEKKB/AJ5YQGcZVJeSIAgABHT3M=
Date: Mon, 12 Sep 2011 13:29:02 +0000
Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719A967D4@008-AM1MPN1-051.mgdnok.nokia.com>
References: <CA8FFC68.108EC%basavaraj.patil@nokia.com>, <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com>
In-Reply-To: <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.74.219.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Sep 2011 13:29:03.0689 (UTC) FILETIME=[F06C5B90:01CC714F]
X-Nokia-AV: Clean
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 13:27:11 -0000

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 us=
eful and helps readability.
If you see Secs 6.2.4, .5 etc in RFC3775 as an example, these are also opti=
ons for MIP6 and they
do provide a brief explanation. Having such text IMO would be useful in thi=
s I-D.

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@n=
okia.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 Introduc=
tion.

> 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


From Basavaraj.Patil@nokia.com  Wed Sep 14 10:53:44 2011
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 F1DA421F86A5 for <netext@ietfa.amsl.com>; Wed, 14 Sep 2011 10:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.136
X-Spam-Level: 
X-Spam-Status: No, score=-103.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 zQYZp44pV0un for <netext@ietfa.amsl.com>; Wed, 14 Sep 2011 10:53:43 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4531C21F85F2 for <netext@ietf.org>; Wed, 14 Sep 2011 10:53:43 -0700 (PDT)
Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EHtRZa003724 for <netext@ietf.org>; Wed, 14 Sep 2011 20:55:51 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 14 Sep 2011 20:55:30 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 19:54:15 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 19:54:14 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Short WGLC on I-D draft-ietf-netext-redirect-10
Thread-Index: AQHMbN8PgY6GdT+J0kiua3aYdqT8BZVMv6YA
Date: Wed, 14 Sep 2011 17:54:14 +0000
Message-ID: <CA965447.10BF1%basavaraj.patil@nokia.com>
In-Reply-To: <CA8BFFF1.10299%basavaraj.patil@nokia.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.28]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0E5E95C83BA16944B3AE369A5E9ADFC3@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Sep 2011 17:55:30.0906 (UTC) FILETIME=[7E5F93A0:01CC7307]
X-Nokia-AV: Clean
Subject: [netext] FW: Short WGLC on 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: Wed, 14 Sep 2011 17:53:44 -0000

Just a reminder that this LC expires tomorrow. Encourage WG members to
review and provide feedback.

-Raj

On 9/6/11 4:50 PM, "Patil Basavaraj (Nokia-CIC/Dallas)"
<Basavaraj.Patil@nokia.com> wrote:

>
>Hello,
>
>The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6
>< draft-ietf-netext-redirect-10.txt> has undergone several edits and
>corrections as a result of implementation experience.
>Please see Jouni Korhonen's email to the ML :
>http://www.ietf.org/mail-archive/web/netext/current/msg02170.html
>which explains the changes and the rationale.
>
>Given the scope of the changes, we would like the WG to give their
>feedback through a short WG LC that is limited to one week.
>
>Please consider this email as the start of the WG LC for this I-D.
>Reviews and feedback on the changes made to the I-D should be posted to
>the netext WG ML by  Sept 15th 2011.
>
>URL for I-D: http://www.ietf.org/id/draft-ietf-netext-redirect-10.txt
>
>-Chairs
>


From internet-drafts@ietf.org  Thu Sep 15 11:29:07 2011
Return-Path: <internet-drafts@ietf.org>
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 48E6821F8B15; Thu, 15 Sep 2011 11:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.447
X-Spam-Level: 
X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 X2VbQd+CcuPK; Thu, 15 Sep 2011 11:29:06 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D035121F8ABC; Thu, 15 Sep 2011 11:29:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110915182906.8173.23015.idtracker@ietfa.amsl.com>
Date: Thu, 15 Sep 2011 11:29:06 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-pmip-lr-05.txt
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: Thu, 15 Sep 2011 18:29:07 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Localized Routing for Proxy Mobile IPv6
	Author(s)       : Suresh Krishnan
                          Rajeev Koodli
                          Paulo Loureiro
                          Qin Wu
                          Ashutosh Dutta
	Filename        : draft-ietf-netext-pmip-lr-05.txt
	Pages           : 25
	Date            : 2011-09-15

   Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
   protocol that enables IP mobility for a host without requiring its
   participation in any mobility-related signaling.  PMIPv6 requires all
   communications to go through the local mobility anchor.  As this can
   be suboptimal, localized routing (LR) allows mobile nodes attached to
   the same or different mobile access gateways to route traffic by
   using localized forwarding or a direct tunnel between the gateways.
   This document proposes initiation, utilization and termination
   mechanisms for localized routing between mobile access gateways
   within a proxy mobile IPv6 domain.  It defines two new signaling
   messages, Localized Routing Initiation (LRI) and Local Routing
   Acknowledgment (LRA), that are used to realize this mechanism.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-pmip-lr-05.txt

From suresh.krishnan@ericsson.com  Thu Sep 15 12:00:22 2011
Return-Path: <suresh.krishnan@ericsson.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 BA65F11E815A for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 12:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.355
X-Spam-Level: 
X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 oWQe1ZlzVE5d for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 12:00:22 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE611E810B for <netext@ietf.org>; Thu, 15 Sep 2011 12:00:15 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8FJ2NB5025949; Thu, 15 Sep 2011 14:02:27 -0500
Received: from [142.133.10.107] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 15 Sep 2011 15:02:22 -0400
Message-ID: <4E724ABD.4080408@ericsson.com>
Date: Thu, 15 Sep 2011 14:58:05 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>
References: <21E7D9BD69CC7241AAE00F4EA183B719083E70@008-AM1MPN1-024.mgdnok.nokia.com>
In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719083E70@008-AM1MPN1-024.mgdnok.nokia.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-netext-pmip-lr@tools.ietf.org" <draft-ietf-netext-pmip-lr@tools.ietf.org>, "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip-lr-04
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: Thu, 15 Sep 2011 19:00:22 -0000

Hi Raj,
  Thanks for the review. I have submitted version -05 resolving most of
the issues you raised in this mail. Please find my responses to the open
issues inline.


Basavaraj.Patil@nokia.com wrote:
> 10. Sec 5:
> 
>>  As earlier, the LMA initiates LR as a response to some trigger
> 
>>  mechanism.
> 
>  
> 
> What trigger mechanism? Can you provide at least some examples?

The earlier versions of the draft contained example triggers but there
was some opposition to mentioning the type of triggers possible.

> 
>  
> 
> 11.
> 
>>   The tunnel between the MAGs is assumed to be established by means
> 
>>   outside the scope of this document.
> 
>  
> 
> It would be useful to at least provide some examples of the tunnel
> 
> establishment between MAGs from a completeness perspective. It looks
> 
> like handwaving at the moment.

I agree with you that it is handwavy, but I am not sure what to add
here. People wanted all kinds of tunnels here, IPv6, IPv4, GRE, USP,
IPsec etc. with either manual or dynamic creation. If you want a
specific scenario, I could add it here but if I remember correctly we
did not even manage to get consensus among the authors.

> 18. The IANA considerations section is poorly written and does not
> 
>     provide sufficient information to IANA regarding the actions
> 
>     needed from them. I would recommend revisiting this section.

I went through the section again and I am not sure what is missing here.
What information required by IANA do you think is missing?

Thanks
Suresh

From Basavaraj.Patil@nokia.com  Thu Sep 15 15:09:02 2011
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 47F7321F89BA for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 15:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.65
X-Spam-Level: 
X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 C7le3l+p4Qt9 for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 15:09:01 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 921F721F893C for <netext@ietf.org>; Thu, 15 Sep 2011 15:09:01 -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 p8FMB92x007157; Fri, 16 Sep 2011 01:11:10 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 16 Sep 2011 01:11:09 +0300
Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 00:11:09 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 00:11:01 +0200
From: <Basavaraj.Patil@nokia.com>
To: <suresh.krishnan@ericsson.com>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pmip-lr-04
Thread-Index: AcxGcYt8Segd5A1bSEOc4ChY6g6NHQtVxdiA///iOYA=
Date: Thu, 15 Sep 2011 22:11:01 +0000
Message-ID: <CA97DFEB.10DD9%basavaraj.patil@nokia.com>
In-Reply-To: <4E724ABD.4080408@ericsson.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.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8381872DE2F06B4AAA5450BE4FCE9AE9@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 15 Sep 2011 22:11:09.0105 (UTC) FILETIME=[5F10C210:01CC73F4]
X-Nokia-AV: Clean
Cc: draft-ietf-netext-pmip-lr@tools.ietf.org, netext@ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip-lr-04
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: Thu, 15 Sep 2011 22:09:02 -0000

Thanks for revising the I-D and addressing the comments. Regarding the
open issues my comments inline below:


On 9/15/11 1:58 PM, "ext Suresh Krishnan" <suresh.krishnan@ericsson.com>
wrote:

>Hi Raj,
>  Thanks for the review. I have submitted version -05 resolving most of
>the issues you raised in this mail. Please find my responses to the open
>issues inline.
>
>
>Basavaraj.Patil@nokia.com wrote:
>> 10. Sec 5:
>>=20
>>>  As earlier, the LMA initiates LR as a response to some trigger
>>=20
>>>  mechanism.
>>=20
>> =20
>>=20
>> What trigger mechanism? Can you provide at least some examples?
>
>The earlier versions of the draft contained example triggers but there
>was some opposition to mentioning the type of triggers possible.

The statement: "As earlier, the LMA initiates LR as a response to some
trigger
   mechanism." is quite vague. What is the 'As earlier' referring to? Is
it the previous scenario? If so, reference it.

How about rephrasing it as :
"As described in Sec x .y, the LMA initiates LR as a response to a
trigger. The trigger itself is implementation dependent. "

>
>>=20
>> =20
>>=20
>> 11.
>>=20
>>>   The tunnel between the MAGs is assumed to be established by means
>>=20
>>>   outside the scope of this document.
>>=20
>> =20
>>=20
>> It would be useful to at least provide some examples of the tunnel
>>=20
>> establishment between MAGs from a completeness perspective. It looks
>>=20
>> like handwaving at the moment.
>
>I agree with you that it is handwavy, but I am not sure what to add
>here. People wanted all kinds of tunnels here, IPv6, IPv4, GRE, USP,
>IPsec etc. with either manual or dynamic creation. If you want a
>specific scenario, I could add it here but if I remember correctly we
>did not even manage to get consensus among the authors.

Without actually specifying at least one default tunneling mechanism, how
would you achieve interoperability between MAGs in a PMIP6 domain? Whether
it is IP-in-IP or GRE, it does not matter. I would recommend that the I-D
specify the details about the tunneling between the MAGs. I hope you can
discuss and get consensus among the authors and from WG members.

>
>> 18. The IANA considerations section is poorly written and does not
>>=20
>>     provide sufficient information to IANA regarding the actions
>>=20
>>     needed from them. I would recommend revisiting this section.
>
>I went through the section again and I am not sure what is missing here.
>What information required by IANA do you think is missing?

Its fine. I was thinking that maybe the format specified in I-D:
draft-ietf-netext-redirect-10.txt (IANA Considerations) would make it
easier for IANA.

-Raj

>
>Thanks
>Suresh


From jouni.nospam@gmail.com  Fri Sep 16 04:14:37 2011
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:

>=20
> Hi Jouni,
>=20
> Just one issue that still bothers me:
>=20
>>> 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.
>=20
>> I see your point. However, these texts were removed by discuss =
comments in IESG.
>=20
> 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=20
   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



>=20
> Thx.
> -Raj
>=20
> ________________________________________
> 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
>=20
> Raj,
>=20
> Thanks for the review. See my comments inline.
>=20
> On Sep 10, 2011, at 1:24 AM, <Basavaraj.Patil@nokia.com> =
<Basavaraj.Patil@nokia.com> wrote:
>=20
>>=20
>> My WGLC review comments on Rev 10 of the I-D: =
draft-ietf-netext-redirect
>>=20
>> 1. Abstract can be improved. Rather than just mentioning the scope =
you
>>  could describe briefly the feature specified in this I-D.
>=20
>   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.
>=20
>> 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)
>=20
> Hmm.. I think there is no reason to repeat that technical stuff in =
Introduction.
>=20
>> 3. s/assumed to have required Security Associations (SA)already set =
up
>>  in advance./assumed to have the required Security Associations (SA)
>>  pre-established.
>=20
> Ack.
>=20
>> 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.
>=20
> I see your point. However, these texts were removed by discuss =
comments in IESG.
>=20
>> 5. Missing the direction of the signaling flow message no 1 in fig 1.
>=20
> Ack.
>=20
>> 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.
>=20
> Ack.
>=20
>=20
>> 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.
>=20
> Ack.
>=20
> And thanks,
>        Jouni
>=20
>=20
>>=20
>> -Raj
>>=20
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>=20


From Basavaraj.Patil@nokia.com  Fri Sep 16 04:38:51 2011
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 88EA021F8BEB for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 04:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.154
X-Spam-Level: 
X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 CTHuDQdX-0a5 for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 04:38:50 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEB821F8BFE for <netext@ietf.org>; Fri, 16 Sep 2011 04:38:50 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8GBeQIL014245; Fri, 16 Sep 2011 14:41:01 +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);  Fri, 16 Sep 2011 14:40:51 +0300
Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 13:40:50 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 13:40:50 +0200
From: <Basavaraj.Patil@nokia.com>
To: <jouni.nospam@gmail.com>
Thread-Topic: [netext] Review of I-D: draft-ietf-netext-redirect-10
Thread-Index: AQHMbz9K1OOVFC+yBEKKB/AJ5YQGcZVJeSIAgABHT3OABgPFgIAAJ90d
Date: Fri, 16 Sep 2011 11:40:49 +0000
Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719A9A426@008-AM1MPN1-051.mgdnok.nokia.com>
References: <CA8FFC68.108EC%basavaraj.patil@nokia.com>, <A67081F2-344A-46F6-B02F-A9598A4E10EF@gmail.com> <21E7D9BD69CC7241AAE00F4EA183B719A967D4@008-AM1MPN1-051.mgdnok.nokia.com>, <45130380-9459-45AC-A3E7-ED2B1AFF5DF8@gmail.com>
In-Reply-To: <45130380-9459-45AC-A3E7-ED2B1AFF5DF8@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [173.74.219.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2011 11:40:51.0382 (UTC) FILETIME=[7C5BED60:01CC7465]
X-Nokia-AV: Clean
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:38:51 -0000

Thanks Jouni. Your proposed edits look good. Please go ahead and submit a r=
evise version.=20
WGLC closed yesterday and I have not seen any other comments. I will forwar=
d the I-D back to the IESG as soon as you publish a new rev of the I-D.

-Raj
________________________________________
From: ext jouni korhonen [jouni.nospam@gmail.com]
Sent: Friday, September 16, 2011 6:16 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,

On Sep 12, 2011, at 4:29 PM, <Basavaraj.Patil@nokia.com> <Basavaraj.Patil@n=
okia.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 op=
tions for MIP6 and they
> do provide a brief explanation. Having such text IMO would be useful in t=
his 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 purpose=
s.
>
>> 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 Introd=
uction.
>
>> 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 i=
n 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
>


From bill.wu@huawei.com  Thu Sep 15 18:36:20 2011
Return-Path: <bill.wu@huawei.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 9D3DA11E80AF for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 18:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.252
X-Spam-Level: 
X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[AWL=1.347,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lijMhFL9f79K for <netext@ietfa.amsl.com>; Thu, 15 Sep 2011 18:36:20 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1511E80A2 for <netext@ietf.org>; Thu, 15 Sep 2011 18:36:19 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRL007J0DW50P@szxga03-in.huawei.com> for netext@ietf.org; Fri, 16 Sep 2011 09:38:29 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRL00GW4DW5G8@szxga03-in.huawei.com> for netext@ietf.org; Fri, 16 Sep 2011 09:38:29 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADZ71896; Fri, 16 Sep 2011 09:38:28 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 16 Sep 2011 09:38:17 +0800
Received: from w53375q (10.138.41.130) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 16 Sep 2011 09:38:22 +0800
Date: Fri, 16 Sep 2011 09:38:19 +0800
From: Qin Wu <bill.wu@huawei.com>
X-Originating-IP: [10.138.41.130]
To: Basavaraj.Patil@nokia.com, suresh.krishnan@ericsson.com
Message-id: <30979506D6B247B1B28FEF71383C8767@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-CFilter-Loop: Reflected
References: <CA97DFEB.10DD9%basavaraj.patil@nokia.com>
X-Mailman-Approved-At: Fri, 16 Sep 2011 04:47:08 -0700
Cc: draft-ietf-netext-pmip-lr@tools.ietf.org, netext@ietf.org
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip-lr-04
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 01:36:20 -0000

----- Original Message ----- 
From: <Basavaraj.Patil@nokia.com>
To: <suresh.krishnan@ericsson.com>
Cc: <draft-ietf-netext-pmip-lr@tools.ietf.org>; <netext@ietf.org>
Sent: Friday, September 16, 2011 6:11 AM
Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip-lr-04


 >>> It would be useful to at least provide some examples of the tunnel
>>> 
>>> establishment between MAGs from a completeness perspective. It looks
>>> 
>>> like handwaving at the moment.
>>
>>I agree with you that it is handwavy, but I am not sure what to add
>>here. People wanted all kinds of tunnels here, IPv6, IPv4, GRE, USP,
>>IPsec etc. with either manual or dynamic creation. If you want a
>>specific scenario, I could add it here but if I remember correctly we
>>did not even manage to get consensus among the authors.
> 
> Without actually specifying at least one default tunneling mechanism, how
> would you achieve interoperability between MAGs in a PMIP6 domain? Whether
> it is IP-in-IP or GRE, it does not matter. I would recommend that the I-D
> specify the details about the tunneling between the MAGs. I hope you can
> discuss and get consensus among the authors and from WG members.

[Qin]: I think the default tunneling mechanism should be IP-in-IP, just like what it said
in the section 6.10.2 of RFC5213. e.g., RFC2473 can be used to establish IPv6-in-IPv6 tunneling.
If additional tunneling mechanisms is introduced in, Negotiation
on which tunnel mechanism is selected is required, however as described in RFC6279, this should be 
out scope of netext. 
If dynamic mechanism is used to establish tunneling, we should follow RFC6279 to establish localized
routing states on relevant MAGs.

The question is is it enough to use LRI/LRA to populate localized routing 
states to the MAGs? Do we need addtional extension to LRI/LRA
used between MAGs?

From internet-drafts@ietf.org  Fri Sep 16 06:35:53 2011
Return-Path: <internet-drafts@ietf.org>
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 F272121F8C4D; Fri, 16 Sep 2011 06:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.43
X-Spam-Level: 
X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 EJYOu3aLww+u; Fri, 16 Sep 2011 06:35:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB5221F8C40; Fri, 16 Sep 2011 06:35:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110916133552.8386.3166.idtracker@ietfa.amsl.com>
Date: Fri, 16 Sep 2011 06:35:52 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-redirect-11.txt
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 13:35:53 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Runtime LMA Assignment Support for Proxy Mobile IPv6
	Author(s)       : Jouni Korhonen
                          Sri Gundavelli
                          Hidetoshi Yokota
                          Xiangsong Cui
	Filename        : draft-ietf-netext-redirect-11.txt
	Pages           : 21
	Date            : 2011-09-16

   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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-redirect-11.txt

From Basavaraj.Patil@nokia.com  Fri Sep 16 08:42:27 2011
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 9636521F8C59 for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 08:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.649
X-Spam-Level: 
X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 jEm1jC9KhTDD for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 08:42:26 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0654121F8C45 for <netext@ietf.org>; Fri, 16 Sep 2011 08:42:19 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8GFiXfp024192; Fri, 16 Sep 2011 18:44:33 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 16 Sep 2011 18:44:16 +0300
Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 17:44:10 +0200
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 17:44:10 +0200
From: <Basavaraj.Patil@nokia.com>
To: <netext@ietf.org>
Thread-Topic: Short WGLC on I-D draft-ietf-netext-redirect-10
Thread-Index: AQHMbN8PgY6GdT+J0kiua3aYdqT8BZVPwAIA
Date: Fri, 16 Sep 2011 15:44:10 +0000
Message-ID: <CA98D899.10E7F%basavaraj.patil@nokia.com>
In-Reply-To: <CA8BFFF1.10299%basavaraj.patil@nokia.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.136]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F8574741969BF64288E134CEE1DB50AA@nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 16 Sep 2011 15:44:16.0121 (UTC) FILETIME=[7D763E90:01CC7487]
X-Nokia-AV: Clean
Cc: adrian@olddog.co.uk, draft-ietf-netext-redirect@tools.ietf.org
Subject: Re: [netext] Short WGLC on 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 15:42:27 -0000

The WG Last call on this I-D has concluded. Jouni Korhonen has revised the
I-D as a result of at least one review and comments.
The new version (Rev 11) has been posted.

We will send the I-D back to the IESG and seek approval.

-Chairs

On 9/6/11 4:50 PM, "Patil Basavaraj (Nokia-CIC/Dallas)"
<Basavaraj.Patil@nokia.com> wrote:

>
>Hello,
>
>The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6
>< draft-ietf-netext-redirect-10.txt> has undergone several edits and
>corrections as a result of implementation experience.
>Please see Jouni Korhonen's email to the ML :
>http://www.ietf.org/mail-archive/web/netext/current/msg02170.html
>which explains the changes and the rationale.
>
>Given the scope of the changes, we would like the WG to give their
>feedback through a short WG LC that is limited to one week.
>
>Please consider this email as the start of the WG LC for this I-D.
>Reviews and feedback on the changes made to the I-D should be posted to
>the netext WG ML by  Sept 15th 2011.
>
>URL for I-D: http://www.ietf.org/id/draft-ietf-netext-redirect-10.txt
>
>-Chairs
>


From behcetsarikaya@yahoo.com  Fri Sep 16 14:57:54 2011
Return-Path: <behcetsarikaya@yahoo.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 C55ED21F8CCF for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 14:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.535
X-Spam-Level: 
X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=0.001]
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 V+Txbxwvz8R4 for <netext@ietfa.amsl.com>; Fri, 16 Sep 2011 14:57:53 -0700 (PDT)
Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfa.amsl.com (Postfix) with SMTP id B8CBA21F8CC9 for <netext@ietf.org>; Fri, 16 Sep 2011 14:57:53 -0700 (PDT)
Received: from [98.139.91.62] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 22:00:05 -0000
Received: from [98.139.91.3] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 22:00:05 -0000
Received: from [127.0.0.1] by omp1003.mail.sp2.yahoo.com with NNFMP; 16 Sep 2011 22:00:05 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 414768.35094.bm@omp1003.mail.sp2.yahoo.com
Received: (qmail 43278 invoked by uid 60001); 16 Sep 2011 22:00:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316210402; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ffWfgn+INXUScjIvprbvimytAnEKEZZnPf8H06QOisHTjJ1u+dhprZUNRVJE7Mcr3uRFABm5b/pqt5vXzKi5mjcZ+/kc0EZ8FkA1dz8wrg6m0G3shufoz2eMsnZvx99GuTxlIaiwCI5sFGgsMnQLOoPxCQaKO2yvfyNdt4RTxHU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=uzkhCJ0t3FSu9SRnk7zfd91Xem8k9vZuwbeuojIU1VewkAJle1Rj+2iSJxC5Eq0uCZO+NTJIheC9T0wrH+39FMri5V4esYGZNZr9pGtrP3s96AMO8jrZVcZWq3+B/VKtmWBbNgzgMKXeu8+RwIXLwL9+6PxC7BBY8evvlmpghAI=;
X-YMail-OSG: t25PbvQVM1lk7yQr5atGCE9wumECwQ_Ifps4lRA5qRO9Ne7 1TmFFnD6y
Received: from [50.58.7.243] by web111409.mail.gq1.yahoo.com via HTTP; Fri, 16 Sep 2011 15:00:01 PDT
X-Mailer: YahooMailWebService/0.8.113.315625
Message-ID: <1316210401.40616.YahooMailNeo@web111409.mail.gq1.yahoo.com>
Date: Fri, 16 Sep 2011 15:00:01 -0700 (PDT)
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: "netext@ietf.org" <netext@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [netext] test mail, please ignore
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
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 21:57:54 -0000


From sgundave@cisco.com  Sun Sep 18 11:36:48 2011
Return-Path: <sgundave@cisco.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 65DFB21F847B for <netext@ietfa.amsl.com>; Sun, 18 Sep 2011 11:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599]
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 bGfD-AfZVF3j for <netext@ietfa.amsl.com>; Sun, 18 Sep 2011 11:36:47 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3F21F847A for <netext@ietf.org>; Sun, 18 Sep 2011 11:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=6648; q=dns/txt; s=iport; t=1316371148; x=1317580748; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=14b0uRNE7pl0NOMSaBQK+oRfC8HOWEU2fDmyzDT61GM=; b=Gs0nYegXXrQPF1jeS3IVWZYce0YqqDwDF85f4G5tSfC7QR/VZk1eVf7o zRvW6i6fadKLZyfeRnBupdLImnXB4Byin2M6vtXN4QFQUtHLBhTQf0VmK a6SFo2zsjFYIf/VoGsop6T6wUscK7imHWIxNpyf3QlZx/T9ciGK8CT9Pl g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAKo5dk6rRDoI/2dsb2JhbAA4Cqc6d4FTAQEBAQIBEgEUFQE8BQ0BCIEdAQEEAQ0FIodVlxABizeRKoNRgycEhz8wi1qFJown
X-IronPort-AV: E=Sophos;i="4.68,401,1312156800";  d="scan'208";a="2847201"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 18 Sep 2011 18:39:07 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8IId7c4032578; Sun, 18 Sep 2011 18:39:07 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 18 Sep 2011 11:39:07 -0700
Received: from 10.32.246.214 ([10.32.246.214]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ;  Sun, 18 Sep 2011 18:39:06 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sun, 18 Sep 2011 11:39:03 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: <cjbc@it.uc3m.es>, <netext@ietf.org>
Message-ID: <CA9B88D7.290A9%sgundave@cisco.com>
Thread-Topic: Review of draft-ietf-netext-bulk-re-registration-04.txt
Thread-Index: Acx2Mjz0fWXchPexUE2zCqHrtyUORw==
In-Reply-To: <1313635573.19516.111.camel@acorde.it.uc3m.es>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 18 Sep 2011 18:39:07.0426 (UTC) FILETIME=[3F97D820:01CC7632]
Cc: draft-ietf-netext-bulk-re-registration@tools.ietf.org
Subject: Re: [netext] Review of draft-ietf-netext-bulk-re-registration-04.txt
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: Sun, 18 Sep 2011 18:36:48 -0000

Hi Carlos,

Thanks for the careful review. Please see inline. Thanks !



On 8/17/11 7:46 PM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wrote:

> Hi all,
>=20
> As agreed during the last IETF meeting, I've performed a review of the
> draft.
>=20
> Overall, I think the document is in good shape and well written. I have
> some comments/question, and it might be that some of them have been
> already discussed on the ML (apologies if I missed that discussion).
>=20
> - Section 3.1: I think that the paragraph starting with "A mobile access
> gateway requests a bulk-registration..." should not appear there, as
> Section 3.2 deals specifically with that, so now it is a bit
> misleading/repetitive. It may lead the reader to believe that the MAG,
> after requesting to add an MN into a bulk re-registration set, it has to
> immediately send another PBU to set the binding. It becomes clear later
> in the doc that this is not the case, when I was reading that part it
> was not that clear to me.
>

Will fix this.

=20
> - Section 3.2.2: when the LMA decide to remove a single MN from its
> current bulk registration set, the LMA sends what is called
> "non-solicited regular PBAck message". Is that message used in any other
> spec? I think it is not a good idea to add unsolicited PBAcks, as it
> makes more complex the state machine of the implementation of the MAG. I
> think in the rest of the PMIPv6 extensions that are being developed in
> NETEXT, new messages have been preferred over overloading too much
> PBU/PBA or change its way operation significantly. It may be better to
> use instead a new message, like it is done in RFC 5846 with the BRI/BRA
> signaling.
>

Agree. This is a remnant from the previous fix. Will fix it.


=20
> - Editorial. Section 3.2.3: "the bulk registration (B) flag set" -->
> "the bulk registration (B) flag set to 1".
>=20
> - Section 3.2.3: "Such PBU message lacks any options that identify" -->
> should we use some normative text there, like "Such PBU message MUST NOT
> include any options that identify"?
>=20

We will fix this as part of the rewrite of this paragraph


> - Editorial. Section 3.2.3, second paragraph: "mobile access gateway
> MUST" --> "The mobile access gateway MUST".
>

Ok
=20
> - Section 3.2.3: In the last paragraph, I'd add some normative text
> there.
>

Ok
=20
> - Editorial, Section 3.2.4, first paragraph: I think some rewriting is
> needed, because the "(a) in the expiration..." and "(b) on the
> termination..." does not seem completely right to me.
>

Ok

=20
> - Editorial, Section 4.2: "The value of flag MUST NOT be set to the
> value of (1)" --> "The value of the flag MUST NOT be set to (1)".
>=20

Sure


> - Section 4.2: "All other fields in the Proxy Binding Acknowledgment
> message and the mobility options..." --> is that true? are not some
> additional restrictions on what options can go on the PBA, such any that
> refers to an individual MN?
>=20

The specific options for inclusion/exclusions are identified in the
processing section. Any other options are guided by the respective specs.
Its better to be loose on this, as its a moving train.


> - Section 5.1: I think some non-normative text providing hints on what
> are the extensions/changes required to the BUL would help developers of
> the spec. It is true that it is not necessary to keep all the individual
> information of the bindings, but still some needs to be kept (for
> example the one that relates to the HNP(s) assigned to each MN).
> analogous comment for Section 5.2 for the LMA and the BC.
>

I normally ensure we identify the BCE extensions (which most specs did not
do), but more than that will be debatable, given the OS variants and vendor
preferences.


=20
> - Editorial, Section 5.1.1: "to assigned" --> "to assign"
>=20

Ok

> - Editorial, Section 5.1.1, second bullet. I'd consider rewriting it a
> bit, it's a bit hard to read it.
>

Ok. Will work on it.

=20
> - Section 5,1.2: are the options listed there the only ones that cannot
> be included in the PBU? I think there are others that cannot either,
> such as the Mobile Node Link-layer Identifier Option, and I'm not sure
> about Handoff Indicator Option and Access Technology Type Option...
>

We never identify if other options should or should not be included. If not
explicitly mentioned, they can be included, based on the considerations. In
any one spec, we cannot always identify all the options.

=20
> - Editorial, Section 5.2.2, second bullet: "local mobility anchor must
> reject" --> "local mobility anchor MUST reject".
>

Ok
=20
> - Editorial, Section 5.2.2, second bullet: I'd consider moving the last
> sentence ("The local mobility anchor MUST consider..." at the beginning
> of the bullet.
>

Ok
=20
> - Editorial, Section 5.2.2, fourth bullet: "revocation request, expect
> making the scope" --> I think "expect" should be replaced with "except"
>

Sure

=20
> - Section 6.2: does the RequestBulkReg..." config option force the MAG
> to add ALL MNs in a bulk registration set? I guess there might be cases
> in which that is not desired. Therefore, I'd consider changing the first
> "MUST" there to "MAY".
>


One can surely turn off the flag and apply this selectively.

=20
> - Section 6.2: "If the flag is set to a value of (0), the mobile access
> gateway MUST set the bulk registration flag (B) in the Proxy Binding
> Update request to a value of (1)" --> "If the flag is set to a value of
> (0), the mobile access gateway MUST set the bulk registration flag (B)
> in the Proxy Binding Update request to a value of (0)".
>

Thanks !

=20
> - Reference to RFC3775 should be changed to the brand new and shinny
> RFC6275 :D
>=20

Yep


> - I'm not sure, so I leave this to native English speakers, but to me it
> sounds better "an MN" that "a MN".

So, here is the story:

So convinced was the Brazilian guy with my thick accent, sounding the
acronym "MN" as "mmmmmmm ennnnn", that his criteria for article selection
reflected my accent,. But, now I worked on the accent a bit and it sounds
like, "eh mmm enn", so we will put a "A MN" :). On a serious note, I never
payed attention to this ..., I assume what you say is right. Thanks !



>=20
> - Curiosity: where does the factor 4 come from in the expression of
> transactions/sec?
>=20

Faud must have considered the 4-sec unit parameter in the PBU. Any case,
this needs to be reworded.




> Hope this helps,
>=20
> Carlos


From internet-drafts@ietf.org  Thu Sep 22 22:45:12 2011
Return-Path: <internet-drafts@ietf.org>
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 A91C121F8B34; Thu, 22 Sep 2011 22:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 FwGUK6S7SARo; Thu, 22 Sep 2011 22:45:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356EF21F8B29; Thu, 22 Sep 2011 22:45:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110923054512.22824.26734.idtracker@ietfa.amsl.com>
Date: Thu, 22 Sep 2011 22:45:12 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-radius-pmip6-05.txt
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, 23 Sep 2011 05:45:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : RADIUS Support for Proxy Mobile IPv6
	Author(s)       : Frank Xia
                          Behcet Sarikaya
                          Jouni Korhonen
                          Sri Gundavelli
                          Damjan Damic
	Filename        : draft-ietf-netext-radius-pmip6-05.txt
	Pages           : 36
	Date            : 2011-09-22

   This document defines new attributes to facilitate Proxy Mobile IPv6
   operations using the RADIUS infrastructure.  The protocol defined in
   this document uses Radius based interfaces of the mobile access
   gateway and the local mobility anchor with the AAA server for
   authentication, authorization and policy functions.  The RADIUS
   interactions between the mobile access gateway and the RADIUS-based
   AAA server take place when the Mobile Node attaches, authenticates
   and authorizes to a Proxy Mobile IPv6 domain.  Furthermore, this
   document defines the RADIUS-based interface between the local
   mobility anchor and the AAA RADIUS server for authorizing received
   Proxy Binding Update messages for the mobile node&#39;s mobility session.
   In addition to the mobility session setup related interactions, this
   document defines the baseline for the mobile access gateway and the
   local mobility anchor generated accounting.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-radius-pmip6-05.txt

From cjbc@it.uc3m.es  Mon Sep 26 01:19:33 2011
Return-Path: <cjbc@it.uc3m.es>
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 1A38921F8B45 for <netext@ietfa.amsl.com>; Mon, 26 Sep 2011 01:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 2MKxW75zwOmC for <netext@ietfa.amsl.com>; Mon, 26 Sep 2011 01:19:32 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8561F21F8B3C for <netext@ietf.org>; Mon, 26 Sep 2011 01:19:31 -0700 (PDT)
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B2879BF085D; Mon, 26 Sep 2011 10:22:12 +0200 (CEST)
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: Sri Gundavelli <sgundave@cisco.com>
Date: Mon, 26 Sep 2011 10:22:12 +0200
In-Reply-To: <CA9B88D7.290A9%sgundave@cisco.com>
References: <CA9B88D7.290A9%sgundave@cisco.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";  boundary="=-602fpLnOaayO8sbF+jyM"
X-Mailer: Evolution 3.0.3- 
Message-ID: <1317025332.4050.8.camel@acorde.it.uc3m.es>
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18408.003
Cc: netext@ietf.org, draft-ietf-netext-bulk-re-registration@tools.ietf.org
Subject: Re: [netext] Review of draft-ietf-netext-bulk-re-registration-04.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
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, 26 Sep 2011 08:19:33 -0000

--=-602fpLnOaayO8sbF+jyM
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Sri,

I think I forgot to reply to this. Thanks for considering the comments.
I'm fine with your replies.

Carlos

On Sun, 2011-09-18 at 11:39 -0700, Sri Gundavelli wrote:
> Hi Carlos,
>=20
> Thanks for the careful review. Please see inline. Thanks !
>=20
>=20
>=20
> On 8/17/11 7:46 PM, "Carlos Jes=FAs Bernardos Cano" <cjbc@it.uc3m.es> wro=
te:
>=20
> > Hi all,
> >=20
> > As agreed during the last IETF meeting, I've performed a review of the
> > draft.
> >=20
> > Overall, I think the document is in good shape and well written. I have
> > some comments/question, and it might be that some of them have been
> > already discussed on the ML (apologies if I missed that discussion).
> >=20
> > - Section 3.1: I think that the paragraph starting with "A mobile acces=
s
> > gateway requests a bulk-registration..." should not appear there, as
> > Section 3.2 deals specifically with that, so now it is a bit
> > misleading/repetitive. It may lead the reader to believe that the MAG,
> > after requesting to add an MN into a bulk re-registration set, it has t=
o
> > immediately send another PBU to set the binding. It becomes clear later
> > in the doc that this is not the case, when I was reading that part it
> > was not that clear to me.
> >
>=20
> Will fix this.
>=20
> =20
> > - Section 3.2.2: when the LMA decide to remove a single MN from its
> > current bulk registration set, the LMA sends what is called
> > "non-solicited regular PBAck message". Is that message used in any othe=
r
> > spec? I think it is not a good idea to add unsolicited PBAcks, as it
> > makes more complex the state machine of the implementation of the MAG. =
I
> > think in the rest of the PMIPv6 extensions that are being developed in
> > NETEXT, new messages have been preferred over overloading too much
> > PBU/PBA or change its way operation significantly. It may be better to
> > use instead a new message, like it is done in RFC 5846 with the BRI/BRA
> > signaling.
> >
>=20
> Agree. This is a remnant from the previous fix. Will fix it.
>=20
>=20
> =20
> > - Editorial. Section 3.2.3: "the bulk registration (B) flag set" -->
> > "the bulk registration (B) flag set to 1".
> >=20
> > - Section 3.2.3: "Such PBU message lacks any options that identify" -->
> > should we use some normative text there, like "Such PBU message MUST NO=
T
> > include any options that identify"?
> >=20
>=20
> We will fix this as part of the rewrite of this paragraph
>=20
>=20
> > - Editorial. Section 3.2.3, second paragraph: "mobile access gateway
> > MUST" --> "The mobile access gateway MUST".
> >
>=20
> Ok
> =20
> > - Section 3.2.3: In the last paragraph, I'd add some normative text
> > there.
> >
>=20
> Ok
> =20
> > - Editorial, Section 3.2.4, first paragraph: I think some rewriting is
> > needed, because the "(a) in the expiration..." and "(b) on the
> > termination..." does not seem completely right to me.
> >
>=20
> Ok
>=20
> =20
> > - Editorial, Section 4.2: "The value of flag MUST NOT be set to the
> > value of (1)" --> "The value of the flag MUST NOT be set to (1)".
> >=20
>=20
> Sure
>=20
>=20
> > - Section 4.2: "All other fields in the Proxy Binding Acknowledgment
> > message and the mobility options..." --> is that true? are not some
> > additional restrictions on what options can go on the PBA, such any tha=
t
> > refers to an individual MN?
> >=20
>=20
> The specific options for inclusion/exclusions are identified in the
> processing section. Any other options are guided by the respective specs.
> Its better to be loose on this, as its a moving train.
>=20
>=20
> > - Section 5.1: I think some non-normative text providing hints on what
> > are the extensions/changes required to the BUL would help developers of
> > the spec. It is true that it is not necessary to keep all the individua=
l
> > information of the bindings, but still some needs to be kept (for
> > example the one that relates to the HNP(s) assigned to each MN).
> > analogous comment for Section 5.2 for the LMA and the BC.
> >
>=20
> I normally ensure we identify the BCE extensions (which most specs did no=
t
> do), but more than that will be debatable, given the OS variants and vend=
or
> preferences.
>=20
>=20
> =20
> > - Editorial, Section 5.1.1: "to assigned" --> "to assign"
> >=20
>=20
> Ok
>=20
> > - Editorial, Section 5.1.1, second bullet. I'd consider rewriting it a
> > bit, it's a bit hard to read it.
> >
>=20
> Ok. Will work on it.
>=20
> =20
> > - Section 5,1.2: are the options listed there the only ones that cannot
> > be included in the PBU? I think there are others that cannot either,
> > such as the Mobile Node Link-layer Identifier Option, and I'm not sure
> > about Handoff Indicator Option and Access Technology Type Option...
> >
>=20
> We never identify if other options should or should not be included. If n=
ot
> explicitly mentioned, they can be included, based on the considerations. =
In
> any one spec, we cannot always identify all the options.
>=20
> =20
> > - Editorial, Section 5.2.2, second bullet: "local mobility anchor must
> > reject" --> "local mobility anchor MUST reject".
> >
>=20
> Ok
> =20
> > - Editorial, Section 5.2.2, second bullet: I'd consider moving the last
> > sentence ("The local mobility anchor MUST consider..." at the beginning
> > of the bullet.
> >
>=20
> Ok
> =20
> > - Editorial, Section 5.2.2, fourth bullet: "revocation request, expect
> > making the scope" --> I think "expect" should be replaced with "except"
> >
>=20
> Sure
>=20
> =20
> > - Section 6.2: does the RequestBulkReg..." config option force the MAG
> > to add ALL MNs in a bulk registration set? I guess there might be cases
> > in which that is not desired. Therefore, I'd consider changing the firs=
t
> > "MUST" there to "MAY".
> >
>=20
>=20
> One can surely turn off the flag and apply this selectively.
>=20
> =20
> > - Section 6.2: "If the flag is set to a value of (0), the mobile access
> > gateway MUST set the bulk registration flag (B) in the Proxy Binding
> > Update request to a value of (1)" --> "If the flag is set to a value of
> > (0), the mobile access gateway MUST set the bulk registration flag (B)
> > in the Proxy Binding Update request to a value of (0)".
> >
>=20
> Thanks !
>=20
> =20
> > - Reference to RFC3775 should be changed to the brand new and shinny
> > RFC6275 :D
> >=20
>=20
> Yep
>=20
>=20
> > - I'm not sure, so I leave this to native English speakers, but to me i=
t
> > sounds better "an MN" that "a MN".
>=20
> So, here is the story:
>=20
> So convinced was the Brazilian guy with my thick accent, sounding the
> acronym "MN" as "mmmmmmm ennnnn", that his criteria for article selection
> reflected my accent,. But, now I worked on the accent a bit and it sounds
> like, "eh mmm enn", so we will put a "A MN" :). On a serious note, I neve=
r
> payed attention to this ..., I assume what you say is right. Thanks !
>=20
>=20
>=20
> >=20
> > - Curiosity: where does the factor 4 come from in the expression of
> > transactions/sec?
> >=20
>=20
> Faud must have considered the 4-sec unit parameter in the PBU. Any case,
> this needs to be reworded.
>=20
>=20
>=20
>=20
> > Hope this helps,
> >=20
> > Carlos
>=20

--=20
Carlos Jes=FAs Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

--=-602fpLnOaayO8sbF+jyM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk6ANjQACgkQNdy6TdFwT2dwlgCgk4D2yldQWgSOxJrrwLBlDKRt
laYAn3fkWxyKDeLaIxRRR8u1Y/Zjyq+v
=nVCj
-----END PGP SIGNATURE-----

--=-602fpLnOaayO8sbF+jyM--


From internet-drafts@ietf.org  Thu Sep 29 01:14:36 2011
Return-Path: <internet-drafts@ietf.org>
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 AA27221F8C19; Thu, 29 Sep 2011 01:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 DZpx7C-EDpdk; Thu, 29 Sep 2011 01:14:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3C21F8C0C; Thu, 29 Sep 2011 01:14:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110929081436.31050.87094.idtracker@ietfa.amsl.com>
Date: Thu, 29 Sep 2011 01:14:36 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-05.txt
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: Thu, 29 Sep 2011 08:14:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Bulk Re-registration Support for Proxy Mobile IPv6
	Author(s)       : Fuad Abinader
                          Sri Gundavelli
                          Kent Leung
                          Suresh Krishnan
                          Domagoj Premec
	Filename        : draft-ietf-netext-bulk-re-registration-05.txt
	Pages           : 19
	Date            : 2011-09-29

   For extending the lifetime of a mobility session, the Proxy Mobile
   IPv6 specification requires the mobile access gateway to send a Proxy
   Binding Update message to the local mobility agent on a per-session
   basis.  In the absence of signaling semantics for performing
   operations with group specific scope, it results in significant
   amount of signaling traffic on a periodic basis between a given
   mobile access gateway and a local mobility anchor.  This document
   defines an optimization to the binding update and revocation
   operations in Proxy Mobile IPv6 for performing operations with group
   specific scope with the use of a group identifier.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-=
05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-0=
5.txt

From internet-drafts@ietf.org  Thu Sep 29 07:47:19 2011
Return-Path: <internet-drafts@ietf.org>
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 6078A21F8BDC; Thu, 29 Sep 2011 07:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.591
X-Spam-Level: 
X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 dfsPPS+UWaiv; Thu, 29 Sep 2011 07:47:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956F21F8B66; Thu, 29 Sep 2011 07:47:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110929144718.15034.8723.idtracker@ietfa.amsl.com>
Date: Thu, 29 Sep 2011 07:47:18 -0700
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-bulk-re-registration-06.txt
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: Thu, 29 Sep 2011 14:47:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Network-Based Mobility Extensions Wor=
king Group of the IETF.

	Title           : Bulk Re-registration Support for Proxy Mobile IPv6
	Author(s)       : Fuad Abinader
                          Sri Gundavelli
                          Kent Leung
                          Suresh Krishnan
                          Domagoj Premec
	Filename        : draft-ietf-netext-bulk-re-registration-06.txt
	Pages           : 19
	Date            : 2011-09-29

   For extending the lifetime of a mobility session, the Proxy Mobile
   IPv6 specification requires the mobile access gateway to send a Proxy
   Binding Update message to the local mobility agent on a per-session
   basis.  In the absence of signaling semantics for performing
   operations with group specific scope, it results in significant
   amount of signaling traffic on a periodic basis between a given
   mobile access gateway and a local mobility anchor.  This document
   defines an optimization to the binding update and revocation
   operations in Proxy Mobile IPv6 for performing operations with group
   specific scope with the use of a group identifier.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-=
06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-0=
6.txt