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"?