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:
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf