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

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 25 Nov 2006 22:42:39 -0600

I am the assigned Gen-ART reviewer for this draft, currently on an IESG 
telechat agenda.

Summary: This draft is ready for publication as an Informational RFC.

Comments: the two "Spencer/Problem:" items from my 04 review have been 
fixed. I don't think any of the other items from that review have been 
accepted, but they weren't showstoppers, and the RFC Editor can catch items 
like "Existing solutions for localized mobility management fall into three 
classes:" with only two items in the list that follows, I guess.

Thanks,

Spencer

From: "Spencer Dawkins" <[email-masked]>
Subject: [Gen-art] Gen-ART Review of draft-ietf-netlmm-nohost-ps-04

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

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