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

[Lou Berger <[e-mail]>]

Daniele,
	I think the following is the sole open point!

Some minor changes:

> How about:
>
> NEW
> With respect to ODUflex, three different signal types are allowed: 20
> - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing 
s/Generig/Generic
> Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F) non
> resizable. They MUST always be advertised in separate Type 2 TLVs as
s/They/Each
> they use different adaptation functions [G.805]. In case both GFP-F
s/they/each
s/In case/In the case that
> resizable and non resizable (i.e. 21 and 22) are supported, only
> Signal Type 21 MUST be advertised 
s/MUST/SHALL
>as resizable ODUflex implies non resizable one.
How about replace line with with:
"as, per [G.709], this type also implies support for
 type 22 adaptation."

(please confirm the reference).

>Signal Type 22 MUST be used when only non resizable
> ODUflex is supported.
> 

Much thanks,

Lou

On 1/11/2013 9:18 AM, Daniele Ceccarelli wrote:
> Hi Lou,
> 
> Please see below.
> 
> BR
> Daniele & Sergio
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: mercoledì 9 gennaio 2013 19.25
>> To: Daniele Ceccarelli
>> Cc: [e-mail]; CCAMP
>> Subject: Re: [CCAMP] I-D Action: 
>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt
>>
>> Daniele,
>>
>> see below.
>>
>>
>> On 1/8/2013 12:39 PM, Daniele Ceccarelli wrote:
>>> Hi Lou,
>>>
>>> Please find further comments in line.
>>>
>>> Since the changes from v04 start to be quite a lot we
>> published v05. Please provide further comments (if any) with respect to 
>> that version.
>>>
>>
>> Okay.  Note that you have a nit to clean up the next time you update:
>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft
> -ietf-ccamp-gmpls-ospf-g709v3-05.txt
>>
> 
> fixed
> 
>>
>>> BR
>>> Daniele & Sergio
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:[e-mail]]
>>>> Sent: venerdì 21 dicembre 2012 19.32
>>>> To: Daniele Ceccarelli
>>>> Cc: [e-mail]; CCAMP
>>>> Subject: Re: [CCAMP] I-D Action: 
>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-04.txt
>>>>
>>>> Daniele,
>>>> 	Much thanks -- I do expect that the thread might extend
>> beyond the
>>>> end of year holiday, and that many/most are off next week...
>>>>
>>>> See below for responses.
>>>>
>>>> On 12/21/2012 10:49 AM, Daniele Ceccarelli wrote:
>>>>> 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).
>>>>
>>>> Is there any technical reason for such ordering? It doesn't seem to 
>>>> add any value to me.
>>>
>>> Ok. It was meant to be just a guideline but indeed doesn't add any 
>>> value. Sentence removed.
>>>
>>>>
>>>> I actually was expecting you to say something referring back to 
>>>> signal type or number of stages represented in the TLV...
>>>
>>> WRT signal type each TLV is self-consistent, in the sense
>> that there is no need to have them in a given order. In all the example 
>> we have ordered them form the root to the leaves of the tree so to make 
>> it more "human-readable". We could suggest to follow that orded but 
>> like in the case of type 1 and type2 is does not add any value (except 
>> being more easily read).
>>>
>>> WRT to number of stage the order is important. Actually the
>> text says that they MUST be put is ascending order and an example 
>> (ODU1->ODU2->ODU3) is provided:
>>>
>>> OLD
>>>       - Stage#1 ... Stage#N : These fields are 8 bits long. 
>> Their number is variable and a field is present for
>>> 	  each of the indicated number of stages. The last one
>> MUST always indicate the server ODU container (ODUk/OTUk)
>>> 	  and they MUST be listed in ascending order from the
>> smallest to the biggest one.
>>> 	  The values of the Stage fields MUST be the same ones
>> defined for the Signal Type field. If
>>> 	  the number of stages is 0, then the Stage and Padding
>> fields MUST be omitted.
>>> 	  
>>> 	  Example: in case the ODU1->ODU2->OD3 hierarchy, the
>> Signal Type field is set to ODU1 and
>>> 	  two Stage fields are present, the first indicating
>> ODU2 and the second ODU3 (server layer). 
>>> 	  
>>> We added: "from the smallest to the biggest one." at the end
>> of the first sentence:
>>>
>>> NEW:    
>>>       [CUT]   
>>> 	The last one MUST always indicate the server ODU
>> container (ODUk/OTUk)
>>> 	and they MUST be listed in ascending order from the
>> smallest to the biggest one.
>>> 	[CUT]
>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> Ahh.  Sorry, let me try again:
>>>>
>>>> Given that Figures 4 and 5 completely repeat the information in 
>>>> Figure *4*, I propose that you drop Figure *3*. (and align the 
>>>> preceding paragraph to match.)
>>>
>>> Done
>>>
>>> OLD
>>> 	The format of the SCSI MUST be as depicted in the
>> following figure, where
>>> 	one Type 1 sub-TLV MUST be used for any fixed container
>> and one Type 2 sub-TLV
>>> 	MUST be used for any variable container. 
>>> NEW
>>> 	The SCSI MUST include one Type 1 sub-TLV for any fixed
>> container and one Type 2 sub-TLV
>>> 	for any variable container. 
>>>
>>
>> I think this new/revised text is ambiguous:
>>
>> You say "one ... for any" (twice). Is this one for each, or one for all 
>> (containers)?
> 
> Yes...One for each...corrected.
> 
>>
>> The flow into the next paragraph is a bit hard to follow.
>>
> How about:
> 
> NEW
>    With respect to ODUflex, three different signal types are allowed:
>    20 - ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generig Framing 
>    Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F)
>    non resizable. They MUST always be
>    advertised in separate Type 2 TLVs as they use different adaptation
>    functions [G.805].  In case both GFP-F resizable and non
>    resizable (i.e. 21 and 22) are supported, only Signal Type 21 MUST be
>    advertised as resizable ODUflex implies non resizable one.
>    Signal Type 22 MUST be used when only non resizable ODUflex
>    is supported.
> 
> 
>>>>
>>>> Also, just realized that figures 4 and 5 really should
>> indicate that
>>>> priorities are not always included.  And that a second
>> padding field
>>>> may be needed too! How about:
>>>>
>>>>
>>>>   0                   1                   2                   3
>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |        Type = 1 (Unres-fix)   |           Length              |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |  Signal Type  | Num of Stages |T|S| TSG | Res |   Priority    |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |    Stage#1    |      ...      |   Stage#N     |    Padding    |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |  Unreserved ODUj at Prio 0    |             .....             |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |  Unreserved ODUj at Prio 7    |       Unreserved Padding      |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>                    Figure 4: Bandwidth TLV - Type 1 -
>>>
>>> OK. Wrote padding instead of unreserved Padding
>>>
>>>>
>>>>
>>>>   0                   1                   2                   3
>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |    Type = 2 (Unres/MAX-var)   |           Length              |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |  Signal Type  | Num of Stages |T|S| TSG | Res |   Priority    |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |    Stage#1    |      ...      |   Stage#N     |    Padding    |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                Unreserved Bandwidth at priority 0             |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                              ...                              |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                Unreserved Bandwidth at priority 7             |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |               Maximum LSP Bandwidth at priority 0             |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |                              ...                              |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>   |               Maximum LSP Bandwidth at priority 7             |
>>>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>                    Figure 5: Bandwidth TLV - Type 2 -
>>>>
>>>> (Note some field names have been expanded to match descriptions)
>>>
>>> OK
>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>
>>>>
>>>> great.
>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>> great.
>>>>
>>>>>
>>>>>>
>>>>>> Line 416: By separately do you mean "in separate TLVs"?
>>>>>
>>>>> Yes.changed
>>>>
>>>> great.
>>>>
>>>>>>
>>>>>> 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
>>>>
>>>> okay. Given the signal type definitions are in [OTN-SIG], what 
>>>> additional information is added by this paragraph? What am
>> I missing?
>>>
>>> Things are quite different between signaling and routing
>> when it comes to "implication". In the case of signaling you either 
>> signal type 21 o 22, while in the case of routing if both of them are 
>> supported there is no need to advertise both of them and just signal 
>> type 21 is enough because it implies also signal type 22 support.
>>>
>>>>
>>>>>
>>>>>> Line 419/whole document: Please double check the document for 
>>>>>> spelling errors (there's one in the above paragraph.)
>>
>> you still have some errors...
> 
> No more errors seems to be there according to the spell check, if there are any left please indicate them explicitely.
> 
>>
>>>>>>
>>>>>> 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
>>
>> OLD
>>
>> 409 Value 1 MUST be used on those interfaces where the fallback 410 
>> procedure is enabled and the default value of
>> 1.25 Gbps can be
>> 411 falled back to 2.5 if needed.  Value 2 MUST be used on [RFC4328]
>> 412 interfaces while value 3 MUST be used on [G.709-2012] interfaces
>> 413 where the fallback procedure is unsupported/disabled.  Value 0
>> 414 MUST be used for non multiplexed signal (i.e. non OTN client).
>>
>> How about:
>> A value of 1 MUST be used on interfaces which are configured to support 
>> the fall back procedures defined in [G.798-a2].  A value of 2 MUST be 
>> used on interfaces that only support 2.5 Gbps time slots, such as 
>> [RFC4328] interfaces. A value of 3 MUST be used on interfaces that are 
>> configured to only support
>> 1.25 Gbps time slots. A value or 3 MUST be used for non multiplexed 
>> signal types (i.e. a non OTN client).
>>
> 
> OK but in the last sentence it's value 0, not 3.
> 
>>>>>
>>>>>>
>>>>>> The "RES" field isn't defined.
>>>>>
>>>>>  <t>- Res (3 bits): reserved bits. MUST be set to 0.</t>
>>>>
>>>> "and ignored on receipt."
>>>
>>> Ok
>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>> s/state/indicate
>>>>> advertised. The left most bit represent priority 0 
>> (highest) and the 
>>>>> right most priority 7 (lowest) And are presented in 
>> ascending orded.
>>>> s/) A/), a
>>>> s/orded/ordered
>>>>
>>>>> Each bit MUST be set when the related priority is 
>> supported and MUST
>>>> "A bit MUST be set (1) for each corresponding priority 
>> represented in 
>>>> the TLV and MUST"
>>>>
>>>>> be cleared when the related priority is not supported. 
>>>> s/be cleared/NOT be set (0)
>>>> s/supported/represented.
>>>>
>>>>> When the
>>>>> interface does not support priorities, the advertisement MUST be 
>>>>> compliant with the advertisement of priority 0.
>>>>>
>>>> Replace with
>>>> "At least one priority level MUST be advertised.  A value 
>> of zero (0) 
>>>> MUST be used when not overridden by local policy."
>>>
>>> NEW
>>> 	  <t>- Priority (8 bits): field with 1 flag for each 
>> priority.  A bit MUST be set (1) for each corresponding priority 
>>> 	  represented in the TLV and MUST NOT be set (0) when 
>> the related priority is not represented. 
>>> 	  At least one priority level MUST be advertised. A 
>> value of zero (0) MUST be used when not
>>> 	  overridden by local policy.</t>
>>
>> How about:
>> - Priority (8 bits): a bitmap used to indicate which 
>> priorities are being advertised. The bitmap is in ascending 
>> order, with the leftmost bit representing priority level 0 
>> (i.e., the highest) and the rightmost bit representing 
>> priority level 7 (i.e., the lowest).  A bit MUST be set (1) 
>> corresponding to each priority represented in the TLV, and 
>> MUST NOT be set (0) when the corresponding priority is not 
>> represented.  At least one priority level MUST be advertised 
>> that, unless overridden by local policy, SHALL be at priority level 0.
>>
> 
> OK
> 
>>>>
>>>>> - 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.
>>>>>
>>>> How about:
>>>> Stage (8 bits): Each Stage field indicates the signal type used in 
>>>> the to transport the signal indicated in the Signal Type field. The 
>>>> number of Stage fields included in a TLV MUST equal the 
>> value of the 
>>>> Number of Stages field.  The Stage fields MUST be ordered to match 
>>>> the data plane in ascending order (from the lowest order ODU to the 
>>>> highest order ODU).
>>>
>>> Saying that each stage field indicates the signal type used to 
>>> transport the signal indicated in the signal type field is 
>> not correct 
>>> because e.g. In the case of ODU1->ODU2->ODU3 it is not 
>> correct to say 
>>> that ODU2 and ODU3 are used to transport the ODU1 because the ODU2 
>>> tranports the ODU1 and the ODU3 tranports the ODU3.
>>> How about:
>>>
>>> <t>- Stage (8 bits): Each Stage field indicates the signal type 
>>> beloning to the muxing branch used to transport the signal indicated 
>>> in the Signal Type field. The number of Stage fields 
>> included in a TLV 
>>> MUST equal the value of the Number of Stages field.  The 
>> Stage fields 
>>> MUST be ordered to match the data plane in ascending order (from the 
>>> lowest order ODU to the highest order ODU). The values of the Stage 
>>> fields MUST be the same ones defined for the Signal Type 
>> field. If the 
>>> number of stages is 0, then the Stage and Padding fields MUST be 
>>> omitted.
>>>
>>
>> How about:
>> Stage (8 bits): Each Stage field indicates a signal type in 
>> the multiplexing hierarchy used to transport the signal 
>> indicated in the Signal Type field. The number of Stage fields 
>> included in a TLV MUST equal the value of the Number of Stages 
>> field.  The Stage fields MUST be ordered to match the data 
>> plane in ascending order (from the lowest order ODU to the 
>> highest order ODU). The values of the Stage field are the same 
>> as those defined for the Signal Type field. When the Number of 
>> stage field carries a 0, then the Stage and Padding fields 
>> MUST be omitted.
>>
> 
> OK
> 
>>>>
>>>>
>>>>> - 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.
>>>>>
>>>> How about:
>>>> Padding (variable): The Padding field is used to ensure the 32 bit 
>>>> alignment of stage fields. The length of the Padding field 
>> is always 
>>>> a multiple of 8 bits (1 byte).  Its length can be calculated, in 
>>>> bytes, as:
>>>>      <value of Number of Stages field> % 4 When present, 
>> the Padding 
>>>> field MUST be set to a zero (0) value on transmission and MUST be 
>>>> ignored on receipt.
>>>>
>>>
>>> In case of number of stages == 3,  "<value of Number of 
>> Stages field> % 4" is 3, correct? While the padding bytes is 1.
>>>  Wouldn't "4-<value of Number of Stages field>" be more correct?
>>
>> Woops.  4-(<value of Number of Stages field> % 4), right?
> 
> OK
> 
> 
>>
>>
>>>
>>> How about:
>>>  <t>- Padding (variable): The Padding field is used to 
>> ensure the 32 bit alignment of stage fields.
>>> 	  The length of the Padding field is always a multiple 
>> of 8 bits (1 byte).  Its length can be 
>>> 	  calculated, in bytes, as: 4- "value of Number of 
>> Stages field". 
>> see above.
>>> The Padding field MUST
>>> 	  be set to a zero (0) value on transmission and MUST 
>> be ignored on 
>>> receipt.</t>
>>
>> s/The/When present, the
> 
> OK
> 
>>
>>
>>>
>>>>>
>>>>>> 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.
>>>>>
>>>> How about:
>>>> - Unreserved ODUj (16 bits): This field indicates the Unreserved 
>>>> Bandwidth at a particular priority level.  This field MUST 
>> be set to 
>>>> the number of ODUs at the indicated the Signal Type for a 
>> particular 
>>>> priority level.  One field MUST be present for each bit set in the 
>>>> Priority field, and is ordered to match the Priority field. Fields 
>>>> MUST not be
>>
>> s/MUST not/MUST NOT
>>
>>>> present for priority levels that are not indicated in the Priority 
>>>> field.
>>
>>>> This field is REQUIRED for Type 1 (fixed
>>>> container) TLVs, and MUST NOT be used for Type 2 TLVs.
>>>>
>>
>> Actually, these lines are redundant with the format definition and can
>> be dropped.
>>
> 
> OK
> 
>>>> Also:
>>>> Unreserved Padding (variable): The Padding field is used to 
>> ensure the
>>>> 32 bit alignment of Unreserved ODUj fields. The length of the 
>>>> Unreserved Padding field is always a multiple of 16 bits (2 
>>>> byte).  Its length can be calculated, in bytes, as:
>>>>      <number of priorities indicated in Priorities field> % 2 
>>>> When present, the Unreserved Padding field MUST be set to a 
>>>> zero (0) value on transmission and MUST be ignored on receipt.
>>>>
>>>
>>> Ok, but shouldn't it be: 
>>>       "Its length can be calculated, in multiple of 2 bytes,
>>> 	as: "number of priorities indicated in Priorities field" % 2." ?
>>>
>>> When the number of priorities is odd, the unreserved padding 
>> field is 2 byte, when the number of priorities is even, the 
>> padding field is not there.
>>>
>> How about:
>>
>> - Unreserved Padding (variable): The Padding field is used to ensure
>> the 32 bit alignment of Unreserved ODUj fields.  When present the
>> Unreserved Padding field is 16 bits (2 byte) long.  When the number of
>> priorities is odd, the unreserved Unreserved Padding field MUST be
>> included. When the number of priorities is even, the Unreserved Padding
>> MUST be omitted.
>>
> 
> OK, but it's not variable. When present it's always 16 bits.
> 
>>>
>>>>> - 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.
>>>>>
>>>> How about:
>>>> 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, available at the indicated the Signal 
>>>> Type for a particular priority level.  One field 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 levels that are not indicated in the Priority 
>>>> field.This field is REQUIRED for Type 2 (variable container) 
>>>> TLVs, and MUST NOT be used for Type 1 TLVs.
>>>>
>>
>> The Unreserved Bandwidth field remains undefined in the current text.
> 
> Lost it. Now is there. 
> 
>>
>>>>> - 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:
>>>>>
>>>> How about:
>>>> Maximum LSP Bandwidth (32 bit): This field indicates the 
>>>> maximum bandwidth that can be allocated for a single LSP at a 
>>>> particular priority level. This field MUST be set to the 
>>>> maximum bandwidth,  in bits/s in IEEE floating point format, 
>>>> available to a single LSP at the indicated the Signal Type for 
>>>> a particular priority level.  One field 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 
>>>> levels that are not indicated in the Priority field.
>>
>>>> This field 
>>>> is REQUIRED for Type 2 (variable container) TLVs, and MUST NOT 
>>>> be used for Type 1 TLVs.
>>>>
>>
>> Actually, these lines are redundant with the format definition and can
>> be dropped.
> 
> Yes
> 
>>
>>>
>>> OK
>>>
>>>>
>>>>>>>
>>>>>>>> ...
>>>>>>>>> 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)
>>>>>
>>>>
>>>> Will you add text to that effect to each of those examples?
>>>
>>> OK
>>>
>>>>
>>>>>>
>>>>>>>> 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.
>>>> How about
>>>> This document defines 2 new TLVs that are carried in Interface 
>>>> Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM.
>>>>
>>>>> Each
>>>>>    TLV includes a 16-bit type identifier (the T-field).  Two
>>>> s/Two/The same
>>>>>    T-field values are applicable to the new sub-TLV.
>>> ok
>>>
>>>>>
>>>>>    IANA
>>>>>    The IANA has created a new registry and will manage TLV type
>>>>>    identifiers as follows:
>>>> How about:
>>>> Upon approval of this document, IANA will create and maintain 
>>>> a new registry, the "sub-TLVs of the OTN-TDM Interface 
>>>> Switching Capability Descriptor TLV" registry under the "Open 
>>>> Shortest Path First
>>>> (OSPF) Traffic Engineering TLVs" registry, see 
>>>> http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traf
>>> fic-eng-tlvs.xml,
>>>> with the TLV types as follows:
>>>>
>>>>>
>>>>>    - TLV Type = 1
>>>>>    - TLV Name = Unreserved Bandwidth for fixed containers
>>>>>    
>>>>>    - TLV Type = 2
>>>>>    - TLV Name = Unreserved Bandwidth for fixed containers
>>>>
>>>> The request Registration Procedures are Standards Action.
>>>>
>>
>> What case does "Whether allowed on ISCD sub-TLV" cover? The 
>> scope of the
>> registry is the OTN-TDM Interface Switching Capability Descriptor TLV.
> 
> Removed, it didn't make much sense.
> 
>>
>> Thanks,
>> Lou
>>
>>
>>>> Lou
>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>