[Mobopts] MPA review

"Koodli, Rajeev" <rkoodli@starentnetworks.com> Wed, 04 June 2008 18:46 UTC

Return-Path: <mobopts-bounces@ietf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AD728C1EA; Wed, 4 Jun 2008 11:46:55 -0700 (PDT)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9560D28C1EA for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5vs9V3169HP for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:46:48 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5FAE928C1E7 for <mobopts@irtf.org>; Wed, 4 Jun 2008 11:46:46 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 03611C8033 for <mobopts@irtf.org>; Wed, 4 Jun 2008 14:46:47 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00611-04 for <mobopts@irtf.org>; Wed, 4 Jun 2008 14:46:45 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for <mobopts@irtf.org>; Wed, 4 Jun 2008 14:46:45 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 14:46:45 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 04 Jun 2008 14:47:31 -0400
Message-ID: <4D35478224365146822AE9E3AD4A266602AA1EF3@exchtewks3.starentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: MPA review
thread-index: AcjGcKCkGmHQ0VXpSSmoMaKvqrHxMAAAlNoQ
From: "Koodli, Rajeev" <rkoodli@starentnetworks.com>
Importance: normal
Priority: normal
To: mobopts@irtf.org
X-OriginalArrivalTime: 04 Jun 2008 18:46:45.0736 (UTC) FILETIME=[56A6A680:01C8C673]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Subject: [Mobopts] MPA review
X-BeenThere: mobopts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@ietf.org>
List-Help: <mailto:mobopts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mobopts-bounces@ietf.org
Errors-To: mobopts-bounces@ietf.org

	 
Hi,

my high-level comment is that the document captures many things. While
this is a good thing in one way, it diminishes the focus as a bye
product, unfortunately. So, I am suggesting that it should be
streamlined to make it crisp to better retain its focus on pre-auth
related issues, framework and procedures for inter-domain handovers.

More comments below:

Regards,

-Rajeev


The paragraph starting with "An end-to-end delay consists of several.."
is too dense and long. I am not sure if all of the text is needed.
Please consider making this brief, and keep only the parts which are
essential. In general, detailed descriptions of the previous work should
be referenced out, and not be repeated here.

"This type of Inter-technology handover is often
   called as Vertical Handover since the mobile makes movement between
   two different cell sizes."
                      ^^^^^^^^^^ ??
Section 2 is titled "Inter-domain handover", but it includes the
definitions for different types of handovers. Perhaps revise the section
heading to something like "Handover Types". Also, please provide more
succinct definitions. You may move details which may be useful (but not
crucial) to an Appendix.
(I am trying to see if we can make the presentation little more
crisper).

Section 3 provides a good survey. You may want to revise the title to
"Related Work"

Section 4 - Applicability should be no more than two paragraphs I think

Shouldn't the Terminology Section be earlier, say right after
Introduction?

 Section 6.1:
"MPA provides four basic procedures to provide this functionality.
   The first procedure is referred to as "pre-authentication", the
   second procedure is referred to as "pre-configuration", the
   combination of the third and fourth procedures are referred to as
   "secure proactive handover"."

Either state 4 procedures or 3 procedures.

Section 6.1, paragraph 3 is important for people to get a high-level
overview. It is too condensed. Please try to make the steps clear. And,
do no use acronyms (such as MMP) that are not defined earlier.

PHT (Proactive Handover Tunnel) -> Proactive Handover Tunnel (PHT)

Section 6.2:

"..securely executing a configuration protocol to
   securely deliver an IP address .."

too many 'securely'

"An access router is a router that is responsible for the other part
   of pre-configuration, i.e., securely executing a tunnel management
   protocol to establish a proactive handover tunnel to the mobile node.
   The signaling messages of the configuration protocol MUST be
   protected using a key derived from the key corresponding to the
   MPA-SA."

May be I missed it.. How does the AR get the corresponding keys? You
describe it later, but please make a reference

Section 6.3:

Step 2: "It then performs pre-configuration,
   with the configuration agent using the configuration protocol to
   obtain an IP address, say nCoA (new care-of address), and other
   configuration parameters from the CTN, and with the access router
   using the tunnel management protocol to establish a proactive
   handover tunnel.  "

There are two distinct steps here: pre-configuration, tunnel set up.
You should not combine them into a single sentence (this applies as a
general rule). Also, specify what "other configuration parameters"
mean; it should be clear.

Step 4:
"The mobile may execute the tunnel
   management protocol to delete or disable the proactive handover
   tunnel and cache nCoA after deletion or disabling of the tunnel. "

 Do you allow tunnel deletion prior to link switching? If so, what does
the AR do for packets arriving for nCoA, once tunnel interface is
deleted? "Caching" an address does not sound right.

 "An example call flow for MPA is shown in Figure 3 and Figure 4."

Why is this an example call flow? This is _the_ call flow right?

Section 7:

Please focus on the parts essential to the MPA, and move rest of the
description to the Appendix.

Section 7.3.5. is perhaps not crucial, and can be moved to the appendix

Section 7.4 is not necessary I think. You have created a tunnel
interface between the MN and AR. There are references on how to ue ND
over tunnel interfaces. You can also disable it.

Sections 7.6 and 7.9 are related, and should be condensed into one
section I think.

Section 7.8 does not belong to the main body of the document

Section 8 on Deployment Issues: IMHO, this may be a little early for the
framework. I would consider a separate document once enough experience
is obtained. If there are parts you consider worth documenting now,
please move them to the Appendix.

Section 9 is important since it is supposed to capture the Inter-domain
Handover, which is the primary focus of this ID.
I would consider the key issues that come up, and move multicast
mobility out, or considerably condense it.

In sum, please revise the ID keeping the essential parts in the main
body, referencing known work (without too much description) and moving
the adjoining and descriptive material you consider necessary to
appendix.


General presentation:

please revise phrases such as "A mobile may like to.." to "A mobile may
wish to.." And, please avoid sentences such as "..should not be a big
problem".

"Third, a mobility optimization mechanism needs to support not only
multi-interface terminals where multiple simultaneous connectivity
through multiple interfaces can be expected, but also single-interface
terminals."

RKo> I assume you mean single interface connectivity right? Even with
multiple interfaces, you could still have a single interface
connectivity.

"References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the
measurement techniques for delay and
   jitter."

RKo> "Measurement techniques for delay and jitter are described in [],
[].."


"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
_______________________________________________
Mobopts mailing list
Mobopts@ietf.org
https://www.ietf.org/mailman/listinfo/mobopts