[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
- [Mobopts] MPA review Koodli, Rajeev
- Re: [Mobopts] MPA review Ashutosh Dutta