Subject: [Gen-art] Gen-ART Review of draft-ietf-netlmm-nohost-ps-04

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 Jul 2006 10:39:14 -0500

I am the assigned Gen-ART reviewer for this draft, currently on an IESG
telechat agenda. For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Summary: This document is almost ready for publication as an Informational 
RFC, but two problems (larger than nits) need to be fixed. They are tagged 
as "Spencer/Problem:", and appear in Sections 1.1 and 3.1. Both should be 
fixable using RFC Editor notes, if no further revision of the document is 
produced.

Other comments are included for the document editor and RFC editor's 
convenience, but aren't part of the Gen-ART review.

Thanks,

Spencer

  Abstract

Spencer: "makes a case for network-based local mobility management" just 
seems odd in a problem statement Abstract (would have made more sense in the 
requirements draft). "and presents a "Problem Statement" based on the 
identified shortcomings of previous solutions." maybe? But the Introduction 
does a much better job of describing what's being done here.

     Localized mobility management is a well understood concept in the
     IETF with a number of solutions already available. This document
     looks at the principal shortcomings of the existing solutions, all
     of which involve the host in mobility management, and makes a case
     for network-based local mobility management.

  Contributors

Spencer: including this section is quite nice. I wish IESG would encourage 
the convention (we sure don't have "one way" of handling more than 5 authors 
in common practice).

     Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and
     Marco Liebsch all contributed major effort to this document. Their
     names are not included in the authors' section due to the RFC
     Editor's limit of 5 names.

  1.0  Introduction

     Localized mobility management has been the topic of much work in
     the IETF. The experimental protocols developed from previous work,
     namely FMIPv6 [1] and HMIPv6 [2], involve host-based solutions that
     require host involvement at the IP layer similar to or in addition
     to that required by Mobile IPv6 [3] for global mobility management.

Spencer: "or in addition to" seems distracting. I think the sentence would 
be just as helpful, and more readable, without it.

     However,  recent  developments  in  the  IETF  and  the  WLAN
     infrastructure market suggest that it may be time to take a fresh
     look at localized mobility management.

  1.1 Terminology

          Local Mobility (revised)
            Local Mobility is mobility over an access network. Note
            that, although the area of network topology over which the
            mobile node moves may be restricted, the actual geographic
            area could be quite large, depending on the mapping between
            the network topology and the wireless coverage area.

Spencer/Problem: I wish this definition explicitly said whether there was 
any relationship between an access network and an IP subnet - this is pretty 
fundamental to understanding the problem being targeted in this document, 
and at this point in the document, I'm guessing - so if I guess wrong, I may 
be confused for a while. I think I can figure this out based on the 
"Intra-Link Mobility" definition further down, but again - I'm guessing.

  2.0  The Local Mobility Problem

     The local mobility problem is restricted to providing IP mobility
     management for mobile nodes within an access network. The access
     network gateways function as aggregation routers. In this case,
     there is no specialized routing protocol (e.g. GTP, Cellular IP,
     Hawaii, etc.) and the routers form a standard IP routed network
     (e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1,
     where the access network gateway routers are designated as "ANG".
     Transitions  between  service  providers  in  separate  autonomous
     systems or across broader topological "boundaries" within the same
     service provider are excluded.

Spencer: again, I'm not yet sure of the relationship between subnets and 
access networks, so struggling with "topological" in this sentence.

  3.1 Large Campus

     One  scenario  where  localized  mobility  management  would  be
     attractive is a large campus wireless LAN deployment.  Having a
     single broadcast domain for all WLAN access points doesn't scale
     very well.  Also, sometimes parts of the campus cannot be covered
     by one VLAN for other reasons (e.g., some links are other than
     802.3).

Spencer/Problem: extremely confused here. (1) is it 802.3, or 802.1 (where 
VLANs live)? (2) is it 802.3, or 802.11/16/other wireless? (3) Are you 
telling me something about VLAN support across 802 MAC variations, or 
something else? I'm just too scrambled to suggest text, but something needs 
help here.

  3.2 Advanced Cellular Network

     Next generation cellular protocols such as 802.16e [8] and Super
     3G/3.9G [9] have the potential to run IP deeper into the access
     network than the current 3G cellular protocols, similar to today's
     WLAN networks. This means that the access network can become a
     routed IP network. Interoperable localized mobility management can
     unify local mobility across a diverse set of wireless protocols all
     served by IP, including advanced cellular, WLAN, and personal area
     wireless  technologies  such  as  UltraWide  Band  (UWB)  [10]  and
     Bluetooth [11]. Localized mobility management at the IP layer does
     not  replace  Layer  2  mobility  (where  available)  but  rather
     complements it. A standardized, interoperable localized mobility

Spencer: the "Localized mobility management" sentence just previously is 
VERY helpful, and should appear much sooner in the document.

     management protocol for IP can remove the dependence on IP layer
     localized mobility protocols that are specialized to specific link
     technologies or proprietary, which is the situation with today's 3G
     protocols. The expected benefit is a reduction in maintenance cost
     and deployment complexity. See [6] for a more detailed discussion
     of the goals for a network-based localized mobility management
     protocol.

  4.0  Problems with Existing Solutions

     Existing solutions for localized mobility management fall into
     three classes:

Spencer: but only two are listed - which way is the counting mistake?

     The dedicated localized mobility management IETF protocols for
     Solution 1 are not yet widely deployed, but work continues on
     standardization.  Some  Mobile  IPv4  deployments  use  localized
     mobility management. For Solution 1, the following are specific
     problems:

Spencer: It's not obvious that this section has subsections, but it does 
(one for Solution 1, another for Solution 2). Suggest adding headings like 
"4.1 Problems with Host-based Localized Mobility Management", '4.2 Problems 
with Link-specific Localized Mobility Management", and "4.3  Rationale for 
an Interoperable, Standardized Localized Mobility Management Protocol" for 
ease of scanning. But it does not help that both Solution 1 and Solution 2 
are "buried" in the leadoff paragraphs (in this case, not mentioned until 
the third sentence).

     1) Interoperable IP level protocols that require changes to the
        mobile node's IP stack and handle localized mobility management
        as a service provided to the mobile node by the access network,
     2) Link specific or proprietary protocols that handle localized
        mobility for any mobile node but only for a specific type of
        link layer, namely 802.11 running on an 802.3 wired network
        backhaul.

     The dedicated localized mobility management IETF protocols for
     Solution 1 are not yet widely deployed, but work continues on
     standardization.  Some  Mobile  IPv4  deployments  use  localized

Spencer: a reference for "work continues on standardization" would be 
helpful here.

     mobility management. For Solution 1, the following are specific
     problems:

     1) The host stack software requirement limits broad usage even if
        the modifications are small. The success of WLAN switches
        indicates that network operators and users prefer no host stack

Spencer: "users prefer" seems way overstated. "deploy solutions that do not 
require host stack software modifications more quickly and easily"?

        software modifications. This preference is independent of the
        lack of widespread Mobile IPv4 deployment, since it is much
        easier to deploy and use the network.
     2) Future mobile nodes may choose other global mobility management
        protocols, such as HIP or MOBIKE. The existing localized
        mobility management solutions all depend on Mobile IP or
        derivatives.
     3) Existing localized mobility management solutions do not support
        both IPv4 and IPv6.
     4) Existing host-based localized mobility management solutions
        require setting up additional security associations with network
        elements in the access domain.

  6.0  Security Considerations

     Localized mobility management has certain security considerations,
     one of which - need for access network to mobile node security -
     was touched on in this document. Host-based localized mobility
     management protocols have all the security problems involved with
     providing a service to a host. Network-based localized mobility
     management requires security among network elements equivalent to
     what is needed for routing information security, and security
     between the host and network equivalent to what is needed for
     network access, but no more. A more complete discussion of the
     security goals for network-based localized mobility management can
     be found in [6].

Spencer: Hmm. The corresponding section in [6] is just a little longer than 
this one, so I'm not sure I see the point of having two security 
considerations sections that are both so short, with one pointing to the 
other, but not saying the same things, in two documents that are going 
through approval at roughly the same time. My suggestion is to pick one 
document, put all the text in it, and have the other point to it without 
editorializing. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art