Re: [Mobopts] Poll to publish draft-irtf-mobopts-mpa-framework-07

"Charles E. Perkins" <> Tue, 29 June 2010 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AC433A6948 for <>; Tue, 29 Jun 2010 13:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.558
X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, SARE_MILLIONSOF=0.315, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tmOFwzJHBBc1 for <>; Tue, 29 Jun 2010 13:03:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0EE103A67F9 for <>; Tue, 29 Jun 2010 13:03:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=gt08Sl2mA3Km38WKBYYAZLIjdsaJaduc133nT8eE2hmRR1oV3k/Ob6i/XMdi7t5q; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <>) id 1OTh0q-0002NF-Iy; Tue, 29 Jun 2010 16:02:32 -0400
Message-ID: <>
Date: Tue, 29 Jun 2010 13:02:05 -0700
From: "Charles E. Perkins" <>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Rajeev Koodli <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527f8d27fe0b6ceec7f2c2ab0d84eab2e9350badd9bab72f9c350badd9bab72f9c
Subject: Re: [Mobopts] Poll to publish draft-irtf-mobopts-mpa-framework-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2010 20:03:50 -0000

Hello folks,

I think the document needs at least one more
revision.  Below, please find my first installment
of editorial suggestions and clarifications.
Some are more important than others.

I'll try to finish this review within the
next day.  Please excuse the delay.

- "describes a framework of Media-independent Pre-
    Authentication (MPA), a new handover optimization mechanism"
   But, a framework is not a mechanism.  Maybe it would be
   better to just delete "a framework of".

- "some of the fast-handover scheme"
   --> "some of the fast-handover schemes"

- Cite RFC 2003 instead of RFC 1853.
   And, for IPv6 cite RFC 2473.

- "An access router is a router that is responsible for the other part
    of pre-configuration"
   == I don't have a good suggestion for improvement right now, but
      "access router" is well-established terminology for something
      that doesn't necessarily have the stated responsibility.

- Figure 2 looks wrong; Core network figure typo??
   = The diagram attempts to depict the range of communication
     for the MN but (a) it's mostly confusing and
     (b) many other documents successfully depict wireless
         connectivity without employing ASCII ellipses.

- Any interaction with HMIP?

- "maybe equipped with different"
   --> "may be equipped with a different"

- "scenarios in details"
   --> "scenarios in detail"

- "not limited to MIP type
    mobility protocol only and in addition, this scheme"
    --> "not limited to Mobile IP; this scheme"
    <unless it's desired to describe what "MIP type" means>
    <note the duplication of "in addition" in existing text>

- "develop an optimization framework"
   --> This document seems to describe a mechanism, not
       a framework.  But I agree that it's not a
       protocol specification either way.

- "without any underlying constraints or security related
    --> "without any underlying constraints or security related
    But this is really debatable, if true at all.   There is
    a constraint of reachability, as a first example.
    Moreover, there is an assumption that security CAN be
    pre-established before arrival.  It would be easy to
    identify quite a few other assumptions and constraints.
    The text should be changed to identify at least one
    constraint and at least one assumption, without
    making such absolute claims.

- Relationship with HoKey?  I guess this shows up in
   more detail later in the document, but a little more
   description would be nice at the first reference.

- Section 5, first paragraph
   --- nevertheless even if prediction accuracy is 99%, it
       is still required that MPA is robust against failures
       when there are millions of mobile devices.

- "In other words, MPA is most"  (doesn't parse)
   --> "In other words, MPA is the most"  (unlikely claim)
   --> "In other words, MPA is more viable as a solution..."

- Use cases?
   = describe use with MIP
   = describe use with FMIP
   = describe use with HMIP
   = describe use with SIP Mobility
   (maybe this comes later)

- "Details of discovery mechanism"
   --> "Details about discovery mechanisms"

- "several policies"
   --> several factors

- "data packet loss should not occur except for the period during
    the switching procedure in Step 5, and it is the responsibility of
    link-layer handover to minimize packet loss during this period."
    = Buffering at the target access router can alleviate this problem.
      I think this is mentioned later, but it does mean that the
      quoted sentence needs revision.

- Step 2: the same considerations hold here
	which could indicate preconfiguration
	with several target networks

- Notice also that here MPA isn't quite compatible
	with the FMIP model, because when the MN
	initiates the configures nCoA it does
	not have a tunnel with NAR

- Step 4 (secure proactive handover pre-switching phase)
    "The buffering module at the next access router buffers the packets
     once the tunnel interface is deleted."
   Shouldn't NAR be buffering packets even if the tunnel is
   not explicitly deleted, until the mobile shows up at nCoA?

- Figure 4: "TIA" == ??  <tunnel interface accessability?>

- "provide an optimized handover"
   --> "provide optimized handovers"

- "rapid subnet and domain handover"
   --> "rapid movement between subnets and/or domains"

- "These issues include ..."
   This would work a lot better as an itemized list.

- "choosing the right network to connect"
   --> "connecting to the right network"

- "in details"
   --> "in detail"

- Section 7.1:
   "Discovery ... help"
   --> "Discovery ... helps"

- "during a mobile's rapid movement"
   But: it helps even if the movement is not rapid.

- "SLP"
   Sadly, SLP seems to be mostly irrelevant these days.
   But, if included, a citation should be indicated.

- "There is some proposal"
   --> "Some proposals"

- "When the mobile's movement is imminent, it starts"
   --> "When movement is imminent, the mobile node starts"

- "although a mobile decides"
   --> "although a mobile selects"

- "time-bound tunnels"  <interesting idea!>
   --> "transient tunnels"

- "that could incur"
   --> "that could occur"

- "the mobile is provisioning resources"
   --> "the mobile is reserving resources"

- "big problem.  However, it"
   --> "big problem; it"

- "The mobile uses pre-authentication"
   --> "The mobile uses a pre-authentication"

- "MN may hold some"
   --> "the MN may retain some"

- "Two solutions can take care of this problem."
   --> "There are two solutions to this problem."

- "The mobile can take advantage of the simultaneous mobility binding
    and send multiple binding updates to the corresponding host or HA.
    Thus, the corresponding host or HA forwards the traffic to multiple
    IP addresses assigned to the virtual interfaces for a specific period
    of time."
    ... Should this document really be recommending such signaling
        to correspondent nodes during handover?  Do you have citations
        for this?  I can see it for the home agent (maybe), but
        for CNs also?

- "wakikawa-mobileip-multiplecoa" --> expired...
   Is it still in progress after expiring 4 years ago?

- Section 7.3 should also include FMIP PrRtrAdv
   From RFC 5268:
    Through the RtSolPr and PrRtAdv messages, the MN also formulates a
    prospective new CoA (NCoA) when it is still present on the PAR's
    link.  Hence, the latency due to new prefix discovery subsequent to
    handover is eliminated.  <... continuing with more details ...>

- "Most commonly a mobile can configure itself statically"
   Is this really the most common case?  I find that surprising.

- ""
   I don't think that Zeroconf addressing techniques help MPA
   at all -- at least I don't see how to make that work.

- "In a wide area networking environment, the mobile uses PPP"
   This is not true in all wide-area networks.

- "Each of these processes takes of the order of few hundred
    milliseconds to few seconds ..."
    --> "few" --> "a few"
    IPv6 stateless address autoconfiguration with optimistic
    DAD can be faster.

- "In the following paragraph we describe few ways"
   --> "In the following sections we describe a few ways"

More soon.

Charlie P.

On 5/28/2010 4:04 PM, Rajeev Koodli wrote:
> Dear IRSG,
> This is a poll requesting your vote on the ID.
> The IRSG review by Juergen Schoenwaelder resulted in a major revision,
> followed by another editorial revision.
> The tracker URL:
> Please note that the ticket says “reopened doc review”. This was due to
> my error in submitting the changes incorrectly on the wiki. The document
> was not closed earlier on.
> Appreciate your prompt consideration of the vote (after the holiday
> weekend in the US).
> Regards,
> -Rajeev
> _______________________________________________
> Mobopts mailing list