Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)

Daniele Ceccarelli <> Tue, 25 June 2013 09:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D72FF21E808D for <>; Tue, 25 Jun 2013 02:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.051
X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q-SalLGXf0gi for <>; Tue, 25 Jun 2013 02:59:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E22AB21E804B for <>; Tue, 25 Jun 2013 02:59:27 -0700 (PDT)
X-AuditID: c1b4fb38-b7f476d0000049c9-60-51c969fedf58
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6A.39.18889.EF969C15; Tue, 25 Jun 2013 11:59:26 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 11:59:25 +0200
From: Daniele Ceccarelli <>
To: Lou Berger <>, CCAMP <>, "" <>
Thread-Topic: 2nd WG Last Call comments on ospf-g709v3 (editorial only)
Thread-Index: AQHOaT5Cf8xlCy0KhEe413e0mrGZ+Zk5kc0QgAADdACAAAOEYA==
Date: Tue, 25 Jun 2013 09:59:25 +0000
Message-ID: <>
Accept-Language: it-IT, en-US
Content-Language: it-IT
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvre6/zJOBBn8vq1g8mXODxeJvw2sW i47mtywOzB5Llvxk8viwqZnN48vlz2wBzFFcNimpOZllqUX6dglcGXsWfmYs6Paq+L5AuoHx tWUXIyeHhICJxPnO5SwQtpjEhXvr2boYuTiEBI4ySizYtx/KWcwocWDBH/YuRg4ONgEriSeH fEDiIgLLGCUebpjIDtItLOAmsbL1AjOILSLgLvFv020o20liz8VnYDaLgKrEjzftYDavgLfE 75OXWEFsRgFZiQm7FzGC2MwC4hIvpp9gh7hIQGLJnvPMELaoxMvH/1ghbEWJnWch5jAL6Enc mDqFDcLWlli28DXUfEGJkzOfsExgFJ6FZOwsJC2zkLTMQtKygJFlFSNHcWpxUm66kcEmRmDA H9zy22IH4+W/NocYpTlYlMR5P53aFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkSVYcbvz D++dZt4bP0e3pYbfbnRR6pY3XGayMUVPY92+jddevCoo2dVUxbd2y/E1ry8+ZlDud+8u7/XM /VI8u8f/rusPm2+uB0NPn9x4MO+E4dEa4dl/j74+9TZuwdKpy+QyTu3LezHTWjf7yqXZD7mv X/m290PKvKATif23q4X75BZ9235+5golluKMREMt5qLiRADEBuxwRgIAAA==
Subject: Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2013 09:59:40 -0000

Hi Lou,

All comments addressed. Some comments in line below.


>-----Original Message-----
>From: Lou Berger []
>Sent: venerdì 14 giugno 2013 22.32
>Subject: 2nd WG Last Call comments on ospf-g709v3 (editorial only)
> The following are comments as part of my LC review of 
>draft-ietf-ccamp-gmpls-ospf-g709v3-06.  Note that I'm the document 
>shepherd, see RFC 4858 for more information.
>Please see
>for line numbers used in this message.
>The draft needs to be nit free before being passed to the IESG. The 
>following nits show in the above URL:
>  Miscellaneous warnings:
>  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 
>     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
>     use uppercase 'NOT' together with RFC 2119 keywords (if that is 
>what you
>     mean).
>     Found 'MUST not' in this paragraph:
>     - Unreserved Bandwidth (32 bits): This field indicates the
>     Unreserved Bandwidth at a particular priority level.  
>This field MUST be
>     set to the bandwidth, in bits/s in IEEE floating point format, 
>     at the indicated Signal Type for a particular priority level.  One 
>     MUST be present for each bit set in the Priority field, and is 
>ordered to
>     match the Priority field. Fields MUST not be present for priority 
>     that are not indicated in the Priority field.This field is 
>     Type 2 (variable container) TLVs, and MUST NOT be used for Type 1 
>  -- The document date (April 4, 2013) is 71 days in the past.  Is this
>     intentional?
>  Checking references for intended status: Proposed Standard
>     (See RFCs 3967 and 4897 for information about using normative 
>     to lower-maturity documents in RFCs)
>  == Outdated reference: A later version (-12) exists of
>     draft-ietf-ccamp-gmpls-g709-framework-11
>  == Outdated reference: A later version (-08) exists of
>     draft-ietf-ccamp-otn-g709-info-model-05
>  == Outdated reference: A later version (-09) exists of
>     draft-ietf-ccamp-gmpls-signaling-g709v3-05
>I also have the following editorial comments:
>As with other documents:
>- This and the other g709v3 documents should be consistent in usage of 
>"TS granularity" versus "TSG".  Sometimes one is used rather than the 
>other, sometimes both are used in the same document (as is the case in 
>this document).  Please pick either one and update the four documents 
>to be consistent.

TS granularity use. TSG used only in figures because of room.

>- Another and related comment is please define and use a consistent 
>plural form of "TS".  You initially define "TSs" to expand to "Time 
>Slots", but then use "TS" as the plural form in many (but not all 
>cases).  I personally think "TSs" in all plural cases makes the most 


>- Also same comment for TSGs.
>- Please be consistent in usage of "Gbps".  Some inconsistent examples:
> "1.25/2.5", "1.25Gps", "1.25 GBps" and "1.25 Gbps".  (I personally 
>prefer the final form, but any common form is fine.)

1.25Gbps and 2.5Gbps

>- RFC 4203 uses the field name "Switching Capability-specific
>  information" while the document uses "Switch Capability Specific
>  Information", so throughout the document please
>  s/Switch Capability/Switching Capability
>- per RFC4203, fix capitalization when referring to the filed name:
>  s/MAX LSP bandwidth/MAX LSP Bandwidth
>lines 2-5:
>  Shouldn't this document be identified as an update to 4203?

>Lines 24-32:
>  The Abstract is really in need of a make over.  How about something
>  like the following:
>   This document describes Open Shortest Path First - Traffic
>   Engineering (OSPF-TE) routing protocol extensions to support
>   Generalized MPLS (GMPLS) control of Optical Transport Networks
>   (OTN) specified in ITU-T Recommendation G.709 as published in 2012.
>   It extends mechanisms defined in RFC4203.
>Line 102:
>   Expand ODU
>Lines 105/6:
>   Drop "which is being standardized in ITU-T"
>Line 107:
>   s/the routing process/routing
>Lines 108:
>   You should mentioned the base OSPF TE document here.  How about:
>   s/OSPF-TE/use in GMPLS OSPF-TE as defined in [RFC4203].
>Line 115:
>  s/The routing/Routing
>Line 143-145:
>  I think this text reads a bit backwards, it is the need for the ISCD
>  that drives the new type/swcap, not the other way around  I also
>  suggest adding informative reference to
>  draft-ietf-ccamp-swcaps-update, perhaps something like:
>  OLD
>   This
>   leads to the need to define a new Switching Capability value and
>   associated new Switching Capability for the Interface Switching
>   Capability Descriptor (ISCD).
>  NEW
>   These capabilities are carried in the Interface Switching
>   Capability Descriptor (ISCD) Switching Capability-specific
>   information field using formats defined in this document.
>   As discussed in [swcaps-update], the use of a technology specific
>   Switching Capability-specific information field necessitates
>   the definition of a new Switching Capability value and
>   associated new Switching Capability.


>Line 178:
>  Drop "on this traffic card"
>Lines 192/3:
>  "The TE-Link is referred to as OTUk-TE-Link."
>  This term is used just once in the document.  Suggest dropping it.


>Lines 193/4:
>  Doesn't the TE link for an OTUk physical Link always provide ODUk
>  capacity? Either way this text needs to be fixed/clarified.

What about dropping all of this text:
The TE-Link is
193    referred to as OTUk-TE-Link.  The OTUk-TE-Link advertises ODUj
194    switching capacity.  The advertised capacity could include ODUk
195    switching capacity. 

>Lines 196, 206:
>  Is this an OTUk or ODUk TE link? You first says the former then the
>  latter.  I suspect you mean former, i.e., s/ODUk/OTUk


>Line 209/10:
>  "Such TE-Links are also termed ODUk-TE-Links."
>  This term is used just once in the document.  Suggest dropping it.

>Lines 210-212,221:
>  ODUj vs ODUk.  Isn't it the case that a multi hop TE link could
>  represent either ODUj or ODUk resources?  This isn't clear from the
>  current text/usage of ODUj/k.

New text:

       It is possible to create TE-Links that span more than one hop by creating
 FA between non-adjacent nodes. 
 As in the one hop case, these types of ODUk-TE-Links also advertise ODU switching

>Line 229:
>  s/[RFC4202]/and is defined in [RFC4203]
>Lines 249-257:
>  The document already says 4203 MUST be followed, so no need to 
>  normative language for 4203-defined behavior.  Specifically:
>  s/field MUST be used/field is used
>  s/MUST be in/is in
>Lines 286/7:
>  Isn't this sentence redundant with the prior sentence?  Suggest
>  dropping.


>Line 291:
>Line 293/4:
>  Types are defined in this document.
>  Suggest adding:
>   Note that type values are defined in this document and not 
>Line 301:
>  SCSI acronym not defined.
>Line 301,302:
>  s/any/each
>Line 302:
>  To clarify and to add a transition to the next paragraph, I suggest
>  adding something along the lines of:
>   Each container type is identified by a Signal Type.  Signal Type
>   values are defined in [OTN-SIG].

>Line 469/470:
>   The sentence starting "This field is ..." isn't used consistently
>   (i.e., not present for Unreserved ODUj, Unreserved Padding, and
>    Maximum LSP Bandwidth).  It should be dropped, or parallel
>   statements should be added for the other cases.


>Line 1112:
>  I think the first sentence is a bit hard to follow.  How about:
>  OLD
>   This document, as [RFC4203], specifies
>  NEW
>   This document extends [RFC4203]. As with[RFC4203], it specifies


>Line 1133:
> s/Type/Name
>Line 1145:
> How about the following as the registry name:
>   "Types for sub-TLVs of OTN-TDM SCSI (Switch Capability Specific 
>Lines 1153-1159
>  To be aligned with what you want to see with the registry, and fix 
>type 2 description:
>  Value  Sub-TLV    Reference
>  0  Reserved    [This.I-D]
>  1             Unreserved Bandwidth     [This.I-D]
>     for fixed containers
>  2             Unreserved/Max Bandwidth  [This.I-D]
>     for flexible containers


>Lines 1161/2
>  You some parts of the IANA "formula", how about:
>  OLD
>    New TLV type values may be allocated only by an IETF Consensus
>    action.  The request Registration Procedures are Standards Action.
>  New
>    Types are to be assigned via Standards Action as defined in
>    [RFC5226].
>Lines 1247-1249:
>  Shouldn't [G.709-2012] be normative?


>That's it,