Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt

[Daniele Ceccarelli <[e-mail]>]

Hi Lou,

Below you can find the last call comments pasted with replies in line.

All nits, typos and suggested text changes without any comment in line have been accepted/modified accordingly.

BR
Daniele & Sergio


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
>On Behalf
>Of Lou Berger
>> Sent: mercoledì 26 ottobre 2011 0.37
>> To: [e-mail]
>> Cc: CCAMP
>> Subject: [CCAMP] some comments on gmpls-ospf-g709v3-00
>...
>> 2) SCSI TLV formatting
>>
>> The field descriptions are missing format related conformance
>> (RFC2119) language.
>>

Done

>>
>> 3) SCSI TLV procedures
>>
>> You have defined the formats of the TLVs in Section 4.1, but not 
>> explicitly how they are to be used. Some RFC2119 language really is 
>> needed to cover how the SCSI is to be encoded and parsed. At a 
>> minimum, any TLV inclusion, ordering requirements, and exception 
>> handling should be covered. (For example, your examples 
>always show a 
>> particular ordering relative to Stage#, is this required, 
>recommended, 
>> or just a possibility. You have some informative language, which is 
>> great, but you also need some RFC2119 language.)

Done

>...
>> 6) Finally, some nits:
>> s/[OTN-INFO], the OSPF-TE/[OTN-INFO], OSPF-TE s/list of them/list
>s/Priority :8 bits/Priority (8 bits):
>> s/infer/imply
>>
>> 
>
>- You have some very nice examples, but are inconsistent in 
>filling in field values.  I think all values that can possibly 
>be filled in in the examples should be.
>

All the relevant ones have been introduces. Some non relevant fields have been left with just the field name in. E.g. In an example showing priorities management the T, S and TSG fields have not been filled with 1 or 0 but just T,S and TSG have been left to make the reading easier.

>Detailed editorial and technical comments:
>
>- Please verify that abbreviations are defined before being used .
>There are a number of these.

Done

>
>- Please use a consistent decimal representation (sometimes 
>commas are used other times periods)
>
>- the references [G709-v1] and [G709-v3] each actually refer 
>to multiple documents, each documented needs to have it's own 
>(correct) reference, i.g., [G709-v1] and [G709-v1a1]. The 
>document text will need to be revisited to ensure the proper 
>reference is made.

Updated accordingly with latest proposal: RFC4328 when referencing "old G.709" and G709-2012 when referncing the last one (v4).

>
>-
>http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft
-ietf-ccamp-gmpls-ospf-g709v3-03.txt
>shows there are unresolved nits that need to resolved .  I'm 
>using line numbers from this url in my subsequent comments.
>
>- Line 24: drop "The recent revision of "
>
>- Line 138: "ODUk an higher order" --> "ODUk to indicate a 
>higher order"
>
>- Line 145: "iterated" --> "repeated"
>
>- Line 181/2: Drop "Some of the prominent representations are 
>captured below."
>
>- Line 202: perhaps "termed" --> "referred to"?
>
>- Line 226: I'd suggest 110, but don't feel too strongly about it.
>
>- Line 228: Start with "When supporting the extensions defined 
>in this document, the"
>
>- Lines 236-261: Replace all lines with "MUST be interpreted 
>as defined in [RFC4203]".  No need to repeat what's already specified.
>
>- Lines 265-272: Additional information is fine, but don't 
>repeat 4203 unless directly quoting.
>
>- Line 300: Need to specify what "differing characteristics" 
>means using
>RFC2119 language.
>
>- Section 4.1.
>
>I think the combine presentation of the two types is 
>confusing.  I suggest adding a section 4.1.1 right after line 
>311 covering "Switch Capability Specific Information for fixed 
>containers" followed by a section 4.1.2 covering "Switch 
>Capability Specific Information for flexible containers".  
>Field definitions will need to be reorganized as appropriate.

Rearranged as follows:
4.1.  Switch Capability Specific Information . . . . . . . . . .  7  8
       4.1.1.  Switch Capability Specific Information for fixed
               containers . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.2.  Switch Capability Specific Information for
               variable containers  . . . . . . . . . . . . . . . . . 10
       4.1.3.  Switch Capability Specific Information - Field
               values and explanation . . . . . . . . . . . . . . . . 12



>
>Also the common format and rules related to the OTN-TDM SCSI 
>container should be defined before going into the type 
>specific definitions. (at the 4.1) level.
>
>- Lines 405-417: How about replace all with:
>  "Signal Type: Indicates the ODU type being advertised. 
>Values are defined in [OTN-SIG]"
>
>- Line 428: after "level" suggest adding something like "below 
>the indicated signal type"
>
>- Line 442: "00" --> "0"
>
>- Lines 447, 454, 463, 464: I find the "don't care" case a bit 
>odd.  How about make 0 "unused" or "ignored" and use it instead of 4?
>
>- Lines 472/3: Replace "stage of the muxing hierarchy" --> "of 
>the indicated Number of stages"
>
>- Line 476: "then no Stage fields MUST be included." --> "then 
>the Stage and Padding fields MUST be omitted."
>
>- Lines 484/5: "Only Unreserved/MAX LSP BW fields for 
>supported" --> "Unreserved/MAX LSP BW fields for each identified"
>
>- Line 486: After "to 7)" add ", and Unreserved/MAX LSP BW 
>fields for other priority values MUST be omitted."
>
>- Line 497: Drop "Only", "for supported" --> "for each supported"
>
>- As mentioned above need processing rules/procedures, for 
>multiple ISCDs, SCSI information, e.g., use and ordering of 
>multiple containers.
>
>- Line 503: "infer" -> "imply"
>
>- Fill in all example field values
>
>- Section 7 -- update to reference 4203 and 5920.  Discuss 
>implications / added risk of additional information provided 
>in this document.
Reference to 4203 added and this piece of text added at the end:

   For security threats, defensive techniques, monitoring/detection/
   reporting of security attacks and requirements please refer to
   [RFC5920] .

>
>Section 8.  This section needs some work.  (I'm assuming your 
>familiar with rfc5226).

What about:

8.  IANA Considerations

   Upon approval of this document, IANA will make the assignment of a
   new registry, the "OTN-TDM Container Registry" under a new GMPLS
   Routing Parameters" with two new types (1 and 2)


   Switching Type           Description                Reference
   ----------------------  --------------------------  ----------
   110 (suggested)          OTN-TDM capable (OTN-TDM)  [This.I-D]

   This document defines the following sub-TLVs of the ISCD TLV:

   Value  Sub-TLV
   -----  -------------------------------------------------
     1      Unreserved Bandwidth for fixed containers
     2      Unreserved/MAX LSP bandwidth for flexible containers

>
>- Switching types are assigned in
>http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-
>parameters.xml#gmpls-sig-parameters-3
> (Again I suggest 110, not 101, but this isn't a big deal)
>
>- I think you are actually asking for IANA to establish a new registry.
> Perhaps something like "OTN-TDM Container Registry" under a 
>new "GMPLS Routing Parameters" with two new types.
>
>That's it on this document.
>
>Lou
> 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Lou Berger
>Sent: giovedì 20 dicembre 2012 0.28
>To: [e-mail]; CCAMP
>Subject: Re: [CCAMP] I-D Action: 
>draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt
>
>Authors?
>
>On 12/4/2012 4:34 PM, Lou Berger wrote:
>> Authors,
>> 	Please review any changes and how LC comments are addressed.
>> 
>> Thank you,
>> Lou
>> 
>> On 11/28/2012 2:37 AM, [e-mail] wrote:
>>>
>>> A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>>>  This draft is a work item of the Common Control and 
>Measurement Plane Working Group of the IETF.
>>>
>>> 	Title           : Traffic Engineering Extensions to 
>OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 
>OTN Networks
>>> 	Author(s)       : Daniele Ceccarelli
>>>                           Diego Caviglia
>>>                           Fatai Zhang
>>>                           Dan Li
>>>                           Sergio Belotti
>>>                           Pietro Vittorio Grandi
>>>                           Rajan Rao
>>>                           Khuzema Pithewan
>>>                           John E Drake
>>> 	Filename        : draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt
>>> 	Pages           : 33
>>> 	Date            : 2012-11-27
>>>
>>> Abstract:
>>>    ITU-T Recommendation G.709 [G.709-2012] has introduced 
>new fixed and
>>>    flexible Optical Data Unit (ODU) containers, enabling optimized
>>>    support for an increasingly abundant service mix.
>>>
>>>    This document describes Open Shortest Path First - Traffic
>>>    Engineering (OSPF-TE) routing protocol extensions to support
>>>    Generalized MPLS (GMPLS) control of all currently defined ODU
>>>    containers, in support of both sub-lambda and lambda 
>level routing
>>>    granularity.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-04
>>>
>>> A diff from the previous version is available at:
>>> 
>http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-ospf-g709v3-0
>>> 4
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>> 
>> 
>> 
>> 
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>