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

[Lou Berger <[e-mail]>]

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

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?

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.)

> 
>>>
>>> 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).

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?

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

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.

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.


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

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

The "RES" field isn't defined.

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.

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.

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

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

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