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

[Daniele Ceccarelli <[e-mail]>]

Hi Lou,

Please see in line.

We'll upload -05 when all the issues will be solved.

BR
Daniele & Sergio 

PS. The info model after christmas holidays

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: venerdì 21 dicembre 2012 0.29
>To: Daniele Ceccarelli
>Cc: [e-mail]; CCAMP
>Subject: Re: [CCAMP] I-D Action: 
>draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt
>
>Daniele / Authors,
>	Thank you for the response.  Please see below for my responses.
>
>
>On 12/20/2012 3:57 AM, Daniele Ceccarelli wrote:
>> 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
>
>Thanks.
>
>Some points:
>(Using line numbers from
>http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft
-ietf-ccamp-gmpls-ospf-g709v3-04.txt)
>
>I like your solution for the general TLV format definition.
>
>Lines 303/304: "Different sub-TLV MAY be presented in 
>ascending Type order."
>
>I suspect you mean s/Different sub-TLV/Multiple sub-TLVs
>

See below

>By "ascending Type order", are you refering to the TLV type? 
>Are multiple TLVs of the same type allowed? If not, how are 
>errors handled?

Yes and yes. Multiple TLVs of the same type are often present as each of them represents a branch of the muxing tree.
What about changing into:

      Sub-TLV SHOULD be presented
	in ascending Type order (i.e. type 1 before and type 2 after).

>
>Lines 306-322:
>
>Given that Figures 4 and 5 completely repeat the information 
>in Figure 4, I propose that you drop Figure 4. (and align the 
>preceding paragraph to match.)

Figure 4 and 5 represent TLV type1 and TLV type2 respectively, which are quite different from each other. The first 3 rows are identical but the rest of the TLV is pretty different. We would prefer to keep both of them.

>
>> 
>>>>
>>>> 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
>
>The length of each TLV type and each field should be defined. 
>(You have it for some fields, but not others).

Now all of them should have been filled.

>
>414  With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and
>415  ODUflex Generig Framing Procedure-Frame mapped (GFP-F) MUST
>416  always be advertised separately as they use different
>417  adaptation functions.  In the case both GFP-F resizable and non
>418  resizable (i.e. 21 and 22) are supported, Signal Type 21
>419  implicitely supports also signal Signal Type 22, so only 
>Signal 420  Type 21 MUST be advertised.  Signal Type 22 MUST 
>be used only
>421  for non resizable resources.
>
>Shouldn't this text be moved to after line 304?

Agree. Done.

>
>Line 416: By separately do you mean "in separate TLVs"?

Yes.changed
>
>Lines 416/7: Your reference to "different adaptation 
>functions" lacks context as it is the sole reference in the 
>document to "adaptation functions".  I think you need to 
>either define this terminology (via reference is fine) or 
>replace it some other terminology.
>

Reference to [G.805] added

>Line 419/whole document: Please double check the document for 
>spelling errors (there's one in the above paragraph.)
>
>Line 423:
>
>By "number of multiplexing stages level below the indicated 
>signal type", do you mean "number of multiplexing stages 
>represented as transporting the indicated signal type"?
>
>Lines 424-426.  It's best not to define semantics through 
>example.  How about replacing 423-426 with:
>
>- Number of stages (8 bits): This field indicates the number 
>of multiplexing stages used to transport the indicated signal 
>type. It MUST be set to the number of stages represented in the TLV.
>
OK

>
>Line 428: s/Flags:/Flags (8 bits)

ok
>
>Lines 455-462: should be revised to use 2119 conformance 
>language (and to clarify the malformed text.)

OK

>
>The "RES" field isn't defined.

 <t>- Res (3 bits): reserved bits. MUST be set to 0.</t>  

>
>464-479: I know what you mean, but I think the text really 
>isn't clear and should be revised.  Suggest you just rewrite 
>rather then tweak (as we tried in this rev.) I'm happy to 
>discuss on list if that will help.
>

OLD
464	      - Priority (8 bits): field with 1 flag for each priority.  Each
465	      bit MUST be set when the related priority is supported and MUST be
466	      cleared when the related priority is not supported.  The priority
467	      0 is related to the most significant bit.  When no priority is
468	      supported, priority 0 MUST be advertised.

470	      - Stage#1 ...  Stage#N : These fields are 8 bits long.  Their
471	      number is variable and a field is present for each of the
472	      indicated number of stages.  The last one MUST always indicate the
473	      server ODU container (ODUk/OTUk) and they MUST be listed in
474	      ascending order.  The values of the Stage fields MUST be the same
475	      ones defined for the Signal Type field.  If the number of stages
476	      is 0, then the Stage and Padding fields MUST be omitted.

478	      - Padding: Given that the number of Stages is variable, padding to
479	      32 bits field MUST be used when needed.

NEW

- Priority (8 bits): bitmap used to state which priorities are being advertised.
The left most bit represent priority 0 (highest) and the right most priority 7 (lowest)
And are presented in ascending orded. Each
bit MUST be set when the related priority is supported and MUST be
cleared when the related priority is not supported. When the interface does not 
support priorities, the advertisement MUST be compliant with the advertisement of priority 0.

- Stage#1 ...  Stage#N : Each field is 8 bits long.  One field MUST be used in ascending order
(from the lowest order ODU to the highest order ODU) for each stage of the muxing branch being advertised.
 The last one MUST always indicate the server ODU container (ODUk/OTUk). The values of the Stage fields MUST be the same
ones defined for the Signal Type field.  If the number of stages is 0, the Stage field MUST NOT be included.

- Padding: Padding bytes MUST be inserted so that the
         subsequent field starts at a 4-byte aligned boundary.  It is
         important to note that the Length field includes the padding
         bytes.  Padding SHOULD be using zeros.


>481-493: I still find this text is really confusing.  I think 
>it would cleaner to separate out the fixed container and 
>variable container field definitions (3 definitions: Unres 
>ODUj at Prio N, Unreserved Bandwidth at priority N, and MAX 
>LSP Bandwidth at priority N). Again happy to discuss further on list.
>

OLD
481	      - Unreserved Bandwidth/Max LSP BW : In case of fixed containers
482	      (Type=1) the Unreserved Bandwidth field MUST be 16 bits long and
483	      indicates the Unreserved Bandwidth in number of available
484	      containers.  Unreserved/MAX LSP BW fields for each identified
485	      priority MUST be included, in order of increasing prioritiy (0 to
486	      7) and Unreserved/MAX LSP BW fields for other priority values MUST
487	      be omitted.  In case the number of supported priorities is odd, a
488	      16 bits all zeros padding field MUST be added.  On the other hand,
489	      in case of variable containers (Type 2) the Unreserved/MAX LSP
490	      Bandwidth fields MUST be 32 bits long and expressed in IEEE
491	      floating point format.  The advertisement of the MAX LSP bandwidth
492	      MUST take into account HO OPUk bit rate tolerance and be
493	      calculated according to the following formula:

NEW
- Unreserved ODUj at Prio N (16 bits): This field is used only in case of fixed containers (Type=1).
It MUST be 16 bits long and indicates the Unreserved Bandwidth in number of available
containers. A different field for each supported priority MUST be used. In case the number of 
supported priorities is odd, a 16 bits all zeros padding field MUST be added.

- Unreserved Bandwidth at priority N (32 bits): This field is used only in case of variable containers (Type=2).
It MUST be 32 bits long and indicates the Unreserved Bandwidth in bits/s in IEEE
floating point format. A different field for each supported priority MUST be used.

- MAX LSP Bandwidth at priority N (32 bit): This field is used only in case of variable containers (Type=2).
It MUST be 32 bits long and expressed in bits/s in IEEE floating point format.  The advertisement of the MAX LSP bandwidth
MUST take into account HO OPUk bit rate tolerance and be calculated according to the following formula:

>> 
>>> ...
>>>> 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.
>> 
>
>I think this will confuse some readers.  I think it would be 
>better  to fill in as much as possible, and if not, indicate 
>that the fields are not important to the case (or can carry a 
>specific set of values).  For example why not show that 
>reserved&padding fields are 0, that the SWCaps=OTN-TDM, etc.

Done (only T, S ans TSG left indicated as T, S and TSG when non relevant for the example)

>
>>> Detailed editorial and technical comments:
>>>
>Thank you!
>[...]
>
>
>>> - 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).
>> 
>
>Hereto, we'll see what the reviewers say...
>
>> 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.
>
>Sorry, I wasn't clear in my prior mail.  I didn't mean for the 
>text to end up in the draft unmodified.  Take a look at
>http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04
>for an example of how to ask for a new Switching Type, and
>http://tools.ietf.org/html/draft-ietf-ccamp-rfc4420bis-03 for 
>an example of how to ask for a new TLV registry.


   Upon approval of this document, IANA will make the assignment in the
   "Switching Types" section of the "GMPLS Signaling Parameters"
   registry located at http://www.iana.org/assignments/gmpls-sig-parameters: 
Value      Type                          Reference
---------  --------------------------    ----------
110 (*)     OTN-TDM capable (OTN-TDM)    [This.I-D]

(*) Suggested value
   This document defines a new sub-TLV for the ISCD sub-TLV. Each
   TLV includes a 16-bit type identifier (the T-field).  Two
   T-field values are applicable to the new sub-TLV.

   The IANA has created a new registry and will manage TLV type
   identifiers as follows:

   - TLV Type (T-field value)
   - TLV Name
   - Whether allowed on LSP_ATTRIBUTES object
   - Whether allowed on LSP_REQUIRED_ATTRIBUTES object.

   This document defines new TLV types as follows:

   - TLV Type = 1
   - TLV Name = Unreserved Bandwidth for fixed containers
   - allowed on ISCD sub-TLV
   
   - TLV Type = 2
   - TLV Name = Unreserved Bandwidth for fixed containers
   - allowed on ISCD sub-TLV
   
   New TLV type values may be allocated only by an IETF Consensus
   action.

>
>Lou
>
>>>
>>> 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
>>>
>> 
>> 
>> 
>