Re: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02
"Adrian Farrel" <adrian@olddog.co.uk> Sun, 18 May 2008 10:57 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315903A6852 for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 18 May 2008 03:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.332
X-Spam-Level: **
X-Spam-Status: No, score=2.332 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001]
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 dTXitc7EqlDg for <ietfarch-ccamp-archive@core3.amsl.com>; Sun, 18 May 2008 03:57:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1054D3A6A58 for <ccamp-archive@ietf.org>; Sun, 18 May 2008 03:57:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1JxgRc-000IJ4-Es for ccamp-data@psg.com; Sun, 18 May 2008 10:48:48 +0000
Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1JxgRR-000IHL-9w for ccamp@ops.ietf.org; Sun, 18 May 2008 10:48:42 +0000
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m4IAmWe5017246; Sun, 18 May 2008 11:48:32 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m4IAmShG017226; Sun, 18 May 2008 11:48:30 +0100
Message-ID: <027401c8b8d4$b2902db0$0200a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, ccamp@ops.ietf.org
References: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> <449B2580D802A443A923DABF3EAB82AF111C79A8@OCCLUST04EVS1.ugd.att.com>
Subject: Re: Working Group Last Call complete: draft-ietf-ccamp-pc-and-sc-reqs-02
Date: Sun, 18 May 2008 11:46:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
Hi, I have done a chair review on this draft and found some small editorial updates that should be made before the I-D goes forward. If the editors could resolve these and submit an update, we will be ready for Deborah to take the I-D to the IESG. Thanks, Adrian idnits == It seems as if not all pages are separated by form feeds - found 1 form feeds but 12 pages == Unused Reference: 'RFC 3473' is defined on line 406, but no explicit reference was found in the text === General points - I think you should decide whether management plane, control plane, and data plane are capitalized or not, and apply this to the whole document. - Conventionally, references (such as [RFC1234]) do not include spaces (i.e., not [RFC 1234]) === 1. Introduction s/endpoints/end-points/ OLD At least some control plane initiated aspects of a connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. NEW At least some aspects of a control plane initiated connection must be capable of being queried by the management plane. These aspects should be independent of how the connection was established. === 2. Motivation s/or SC interoperation is achieved/or before SC interoperation is achieved/ s/is proposed as/is stated as/ s/is seen as a nice to have, or desirable, feature/is a desirable feature/ s/should be scoped as/is scoped as/ === 3. Label Switched Path Terminology s/(such as Path and Resv state)/(such as RSVP-TE [RFC3473] Path and Resv state)/ I think you should note that control plane LSPs may be visible and controlable through the management plane. That is, the control plane LSP may have been requested through a management plane operation, and can be reported and inspected by/at the transit LSR. Further, it is generally the case that management plane operations can be carried out on the resources of active control plane LSPs even at transit LSRs. You can then say that this is not the function that you are talking about. === 4. LSP within GMPLS Control Plane Include a refernce to RFC 3945 as you are talking about GMPLS architecture. === 4.1. Resource Ownership At the end of the first paragraph, you have... Note that the management plane assigns resources to the control plane. I think this is confusing in the context of the rest of the text in the paragrpah that defines 'ownership' of resources in relation to the setup of an LSP. Doesn't the sentence actually belong in the next paragraph? I.e., Note that the management plane assigns resources as available for ownership by the control plane. Or even just delete this sentence. === 4.2. Setting Up a GMPLS Controlled Network You have... When converting from an SC to a PC, the management plane must change the owner of each hop. Somehow, then the instance in the control plane must be removed without affecting the data plane. This may best be done via a make before break operation. This last sentence is odd! There is no "make-before-break operation" to be performed as there is no change in the data plane. I suggest that you simply remove this sentence which, in any case, is pre-judging the solution (which this document should avoid doing). === 5.1. PC to SC/SPC Conversion s/Next step in such conversion/The next step in this conversion/ You have... In this case a network upgrade by a Control Plane coverage extension may be required. Huh? The phrase "Control Plane coverage extension" didn't mean anything to me (although I can make some guesses). Can you clarify in the text, please. === 6. Requirements Suggest you add... Notation from [RFC2119] is used to clarify the level of each requirement. === 6.2. No Disruption of User Traffic SC to PC conversion and vice-versa shall occur without generating s/shall/SHALL/ ? === 6.5. Synchronization of state among nodes during conversion Please capitalize the section heading It MUST be assured that the state of the LSP is synchronized among all nodes traversed by it before proceeding to the conversion. Does "before proceeding to the conversion" mean "before the conversion is considered complete"?
- Working Group Last Call: draft-ietf-ccamp-pc-and-… BRUNGARD, DEBORAH A, ATTLABS
- Working Group Last Call complete: draft-ietf-ccam… BRUNGARD, DEBORAH A, ATTLABS
- Re: Working Group Last Call complete: draft-ietf-… Adrian Farrel