Subject: Re: [Gen-art] review: draft-ietf-netext-pmip6-lr-ps-05

From: Marco Liebsch <[email-masked]>
Date: Fri, 29 Apr 2011 17:43:06 +0200

Dear Joel,

thanks a lot for your valuable comments. Please find below a revised 
Abstract and Introduction.
I marked new text as follows: /+ new or revised text +/

Please let me know if the proposed revision makes the scope of the 
document clearer.

---
Abstract

   Proxy Mobile IPv6 is the IETF standard for network-based mobility
   management.  In Proxy Mobile IPv6, mobile nodes are topologically
   anchored at a Local Mobility Anchor, which forwards all data for
   registered mobile nodes. /+ The setup and maintenance of localized
   routing, which allows forwarding of data packets between two mobile
   nodes' Mobility Access Gateways without involvement of their Local
   Mobility Anchor in forwarding, is not considered. +/ This document
   describes the problem space of localized routing in Proxy Mobile
   IPv6.

---1.  Introduction

   The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the
   base protocol for network-based localized mobility management
   (NetLMM).  The scope of the base protocol covers the set up and
   maintenance of a tunnel between an MN's Mobile Access Gateway (MAG)
   and its selected Local Mobility Anchor (LMA).  Data packets will
   always traverse the MN's MAG and its LMA, irrespective of the
   location of the MN's remote communication endpoint.  Even though an
   MN may be attached to the same or a different MAG as its
   Correspondent Node (CN) within the same provider domain, packets
   being associated with their communication will traverse the MN's and
   the CN's LMA /+, which can be located topologically far away from the
   MN's and the CN's MAG or even in a separate provider domain.+/
   [RFC5213] addresses the need to enable local routing of traffic
   between two nodes being attached to the same MAG, but does not
   specify the complete procedure to establish such localized routing
   state on the shared MAG.

   The NetLMM Extensions (NetExt) Working Group has an objective to
   design a solution for localized routing in PMIPv6.  This includes the
   specification of protocol messages and associated protocol operation
   between PMIPv6 components to support the setup of a direct routing
   path for data packets between the MN's and the CN's MAG /+, both
   receiving mobility service according to the PMIPv6 protocol
   [RFC5213] +/.  As a result of localized routing, these packets will be
   forwarded between the two associated MAGs without traversing the MN's
   and the CN's LMA(s).  In case one or both nodes hand over to a
   different MAG, the localized routing protocol maintains the localized
   routing path.  Relevant protocol interfaces may include the interface
   between associated MAGs, between a MAG and an LMA as well as between
   LMAs. /+ Out of scope of the NetExt solution and this problem statement
   is the setup of localized routing with CNs, which are not registered
   with a PMIPv6 network. +/

   This document analyzes and discusses the problem space of using
   always the default route through two communicating mobile nodes'
   local mobility anchors.  Furthermore, the problem space of enabling
   localized routing in PMIPv6 is analyzed and described, while
   different communication and mobility scenarios are taken into
   account. /+ Based on the analysis, a list of key functional
   requirements is provided, serving as input to the design of the
   protocol solution.+/

Best regards,
Marco

Joel M. Halpern wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments 
> you may receive.
>
> Document: draft-ietf-netext-pmip6-lr-ps-05
>     PMIPv6 Localized Routing Problem Statement
> Reviewer: Joel M. Halpern
> Review Date: 7-March-2011
> IETF LC End Date: 14-March-2011
> IESG Telechat date: 17-March-2011
>
> Summary: This document is close to ready for publication as an 
> Informational RFC.
>
> Moderate issues:
>     The abstract is misleading.  It reads as if the problem is 
> allowing communication between a PMIP mobile node and a correspondent, 
> wherever the correspondent is.  Even the introduction is somewhat hazy 
> on its scope, sometimes referring to the generalized notion of 
> correspondent node, and sometimes seeming to mean just the sub-case of 
> two nodes, both attached to MAGs, in the same domain.  It is only in 
> the conventions and terminology that "Localized Routing" is actually 
> defined in a way to make clear what problem is of interest.
>
>
> Minor issues:
>     In the introduction, the word "problem space" is used to describe 
> what is being covered in this document.  However, the document 
> includes sections such as section 4, Functional Requirements for 
> Localized Routing which are not about the problem, but rather about 
> what mechanisms are needed for a solution.  Rather than argue about 
> what belongs in this document, or the document name, I would suggest 
> clarifying in the introduction what this document is actually doing.
>     While the arguments at the end of section 3.1 sound plausible, 
> they are, as far as I can tell, quite controversial in the mobile 
> industry. I have heard speakers make exactly opposite assertions about 
> several of these claims.  As such, I think this paragraph ought to be 
> toned down.
>     I found myself confused by the text in section 5. I think that the 
> problem is that I assume that a "Local Mobility Agent" will be in the 
> same domain as the Mobile Access Gateway handling the client the LMA 
> is supporting (otherwise it sems not to be local.)  Given the 
> discussion of Roaming, and the way it is constructed, this appears not 
> to be the case.  If there is no such domain coupling requirement, then 
> could you please add a note to that effect somewhere early in the 
> document (possibly in the introduction along with a better description 
> of the problem.)
>
> Nits/editorial comments: