Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt
Hidetoshi Yokota <yokota@kddilabs.jp> Fri, 04 December 2009 04:24 UTC
Return-Path: <yokota@kddilabs.jp>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED58D3A6405 for <gen-art@core3.amsl.com>; Thu, 3 Dec 2009 20:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.024
X-Spam-Level:
X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 28M9+3qyHWto for <gen-art@core3.amsl.com>; Thu, 3 Dec 2009 20:24:03 -0800 (PST)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id B37253A62C1 for <gen-art@ietf.org>; Thu, 3 Dec 2009 20:24:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 58037EC881; Fri, 4 Dec 2009 13:23:51 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (unknown [2001:200:601:402:203:baff:fe2c:bc3]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4E3AEEC8C8; Fri, 4 Dec 2009 13:23:50 +0900 (JST)
Received: from [127.0.0.1] (unknown [172.19.90.38]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 6EB3A1BFFB; Fri, 4 Dec 2009 13:22:43 +0900 (JST)
Message-ID: <4B188E94.2030209@kddilabs.jp>
Date: Fri, 04 Dec 2009 13:22:44 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@fdupont.fr>
References: <200911301512.nAUFCDtG059931@givry.fdupont.fr>
In-Reply-To: <200911301512.nAUFCDtG059931@givry.fdupont.fr>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Cc: vijay@wichorus.com, kchowdhury@starentnetworks.com, gen-art@ietf.org, basavaraj.patil@nokia.com, Jari Arkko <jari.arkko@piuha.net>, rkoodli@starentnetworks.com, xiayangsong@huawei.com
Subject: Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2009 04:24:05 -0000
Hello Francis, Now I see what gave you a pain... A series of unfamiliar abbreviations may hamper readability. Please take a look at the following style. The key words below are spelled out: MN -> mobile node P/N-AN -> previous/new access network P/NMAG-> previous/new MAG etc. If the revised style is acceptable, we will revise the whole document as such. ============ <excerpt from Section 4.1> ======================= (a) The mobile node detects that a handover is imminent and reports the identifier of itself (MN ID) and the New Access Point Identifier (New AP ID) [RFC5568] to which the mobile node is most likely to move. The MN ID could be the NAI or a Link Layer Address (LLA), or any other suitable identifier. This step is access technology specific. In some cases, the previous access network (P-AN) will determine which AP ID the mobile node is moving to. (b) The previous access network, to which the mobile node is currently attached, indicates the handover of the mobile node to the previous mobile access gateway (PMAG). Detailed definition and specification of this message are outside the scope of this document. (c) The previous MAG sends the Handover Initiate (HI) message to the new mobile access gateway (NMAG). The HI message MUST have the P flag set and include the MN ID, the HNP(s) and the address of the local mobility anchor (LMA) that is currently serving the mobile node. If there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), that information MUST also be included. With some link layers, the MN Link-local Address IID (MN LLA- IID) can also be included (see Section 6.2.3). (d) The new MAG sends the Handover Acknowledge (HAck) message back to the previous MAG with the P flag set. (e) If it is preferred that the timing of buffering or forwarding should be later than step (c), the new MAG may optionally request the previous MAG at a later and appropriate time to buffer or forward packets by setting U flag [RFC5568] or F flag in the HI message, respectively. (f) If the F flag is set in the previous step, a bi-directional tunnel is established between the previous MAG and new MAG and packets destined for the mobile node are forwarded from the previous MAG to the new MAG over this tunnel. After decapsulation, those packets may be buffered at the new MAG. If the connection between the new access network and new MAG has already been established, those packets may be forwarded towards the new access network, which then becomes responsible for them (e.g., buffering or delivering depending on the condition of the mobile node's attachment); this is access technology specific. (g) The mobile node undergoes handover to the new access network. (h) The mobile node establishes a physical link connection with the new access network (e.g., radio channel assignment), which in turn triggers the establishment of a link-layer connection between the new access network and new MAG if not yet established. An IP layer connection setup may be performed at this time (e.g., PPP IPv6CP) or at a later time (e.g., stateful or stateless auto address configuration). This step can be a substitute for the Unsolicited Neighbor Advertisement (UNA) in [RFC5568]. If the new MAG acquires a valid new MN LL-ID via the new access network and a valid old MN LL-ID from the previous MAG at step (c), these IDs SHOULD be compared to determine whether the same interface is used before and after handover. When the connection between the mobile node and new MAG is PPP and the same interface is used for the handover, the new MAG SHOULD confirm that the same interface identifier is used for the mobile node's link-local address (this is transferred from previous MAG using the MN LLA-IID option at step (c), and sent to the mobile node during the Configure-Request/Ack exchange). (i) The new MAG starts to forward packets destined for the mobile node via the new access network. (j) The uplink packets from the mobile node are sent to the new MAG via the new access network and the new MAG forwards them to the previous MAG. The previous MAG then sends the packets to the LMA that is currently serving the mobile node. (k) The new MAG sends the Proxy Binding Update (PBU) to the LMA, whose address is provided in (c). Steps (k) and (l) are not part of the fast handover procedure, but shown for reference. (l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the new MAG. From this time on, the packets to/from the mobile node go through the new MAG instead of the previous MAG. ============ Regards, -- Hidetoshi Francis Dupont wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-mipshop-pfmipv6-11.txt > Reviewer: Francis Dupont > Review Date: 2009-09-22/2009-11-30 > IETF LC End Date: 2009-09-22 > IESG Telechat date: unknown > > Summary: Ready > > Comments: the style is still at least questionable, I quote an example: > > (f) If the F flag is set in the previous step, a bi-directional > tunnel is established between the PMAG and NMAG and packets > destined for the MN are forwarded from the PMAG to the NMAG over > this tunnel. After decapsulation, those packets may be buffered > at the NMAG. If the connection between the N-AN and NMAG has > already been established, those packets may be forwarded towards > the N-AN, which then becomes responsible for them (e.g., > buffering or delivering depending on the condition of the MN's > attachment); this is access technology specific. > > IMHO if abbrevs are fine in figures and can help to keep a document > reasonably not too long, their abuse as in this document is clearly > not a good thing. Now it is a matter of taste. > > Regards > > Francis.Dupont@fdupont.fr > > >
- [Gen-art] re-review of draft-ietf-mipshop-pfmipv6… Francis Dupont
- Re: [Gen-art] re-review of draft-ietf-mipshop-pfm… Hidetoshi Yokota
- Re: [Gen-art] re-review of draft-ietf-mipshop-pfm… Francis Dupont
- Re: [Gen-art] re-review of draft-ietf-mipshop-pfm… Jari Arkko
- Re: [Gen-art] re-review of draft-ietf-mipshop-pfm… Hidetoshi Yokota