Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

[Leeyoung <[e-mail]>]

Hi Lou,

WRT to your comment on:
Section 4.
  The definitions of sub-sub-TLVs are a bit underspecified.  Some
  specific questions to address:
  - Are there any sub-sub-TLV ordering requirements?
  - How are multiple sub-sub-TLVs of the same type to be handled?
  - What is the sub-sub-TLV header (TL format)?
  - Are there any alignment requirements?
  - What happens when a sub-sub-TLV is larger than 256 bytes?
    (There are already systems that advertise 192 wavelengths on a
    fiber and an application code takes 8 bytes, right? But
    of course this presents a problem when carried within an RSVP
    object too.)

For the last dash item, "what happens when sub-sub-TLV is larger than 256 bytes", I guess you meant that the RB Info Field (in which to contain sub-sub-TLVs) can exceed 256 bytes as opposed to individual sub-sub-TLVs in the RB Info Field? 

As for the resolution for this case, should this be addressed in the respective routing and signaling drafts? 

I am not familiar the method to resolve this kind of issues --- can you suggest some references or relevant text? I think this issue would arise both routing and signaling. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, October 29, 2013 1:27 PM
To: CCAMP; [e-mail]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

Authors,
	I have some comments on this document. Many are strictly editorial. Note that I'm the document shepherd, see RFC 4858 for more information.

- Please address my general comments on the WSON document set

- section 1
   This document makes
   use of the Label Set Field encoding of [Gen-Encode] and refers to it
   as a Wavelength Set Field.
  Why?  Why not just refer to it as Label Set?  Perhaps you mean that a
  Wavelength Set Field is a Label Set Field that MUST carry a label as
  defined in RFC6205?  If so, this needs to be made explicit. (probably
  in a section other than the introduction.)

- section2/3 section alignment with rwa-info
  It's probably a good idea to align naming and ordering wherever
  possible.

- section 2
  1st two paragraphs.  Why does this section try to introduce concepts
  that are defined in 6163 and in [WSON-INFO]?  Is something missing
  from those documents?  If so, at least wson info should be fixed.  If
  not, these paragraphs should be replaced with simple
  terminology/concept references.

- Section 2, same comment WRT TLVs as made on general-constraint-
  encode: The text reads:
   This document defines the following sub-TLVs pertaining to resources
   within an optical node:

   All references to sub-TLVs should dropped, again see related comment
   in my may on general-constraint-encode.  This doesn't hold for
   sub-sub-TLVs, and I'll get to this below.

- Section 3.1
    0 1 2 3 4 5 6 7 8
    | Connectivity  |
  Why is connectivity a byte here, but only a bit in section 2.1?
  Either it should be a bit here to, or section 2.1 should be a byte.
  Note, that this can be fixed in a compatible way by defining it here
  as:
    0 1 2 3 4 5 6 7 8
    |   Reserved  |C|


- Section 4.
  The definitions of sub-sub-TLVs are a bit underspecified.  Some
  specific questions to address:
  - Are there any sub-sub-TLV ordering requirements?
  - How are multiple sub-sub-TLVs of the same type to be handled?
  - What is the sub-sub-TLV header (TL format)?
  - Are there any alignment requirements?
  - What happens when a sub-sub-TLV is larger than 256 bytes?
    (There are already systems that advertise 192 wavelengths on a
    fiber and an application code takes 8 bytes, right? But
    of course this presents a problem when carried within an RSVP
    object too.)

  If you find you need more specifics, we can discuss / I can propose
  new text.  Feel free to discuss the details on or off list (your
  choice.)

- Section 4.1
  Title and 1st sentence don't agree on the element's name.

- Section 3.4, 4.1
  - Bits I & E are defined here, but I & O are used in parallel ways in
    Section 3.2. For consistency it should be I & O everywhere (to
    match input and output).

- Section 4.2.1
  s/[ITU-G.695.1]/[ITU-G.695]

- Section 4.2.2, 4.2.3
  Why do you use bit names that are different than the ITU-T
  definitions for p and s (rather than D and F)?

WRT Section 8:
-  [RFC3471] is an informative reference.
- [Gen-Encode] needs to be normative, this document reuses its definitions.
- I'm surprised  [WSON-Info] is informative (and not normative).  Do you think this is correct?

That's it on this one,
Lou
On 10/22/2013 4:34 PM, Lou Berger wrote:
> 
> All,
> 	Given the recent draft submission deadline and only one comment being 
> received to date, we'd like to extend the WG more time for review.
> 
> These drafts represent significant work by the authors and WG, so 
> please review and let the WG know what you think (positive or negative)!
> 
> Please have all comments in by October 29.
> 
> Thank you,
> Lou (and Deborah)
> 
> On 10/1/2013 12:34 PM, Lou Berger wrote:
>> All,
>>
>> This mail begins working group last call on the WSON documents.  As 
>> there are 6 documents in this set, the last call will be three weeks.
>> The documents included in the last call are:
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>> (Informational, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode
>> -11
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>> (Standards Track)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints
>> -ospf-te-05
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility
>> -ospf-12
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 
>> (Standards
>> Track) Also has one open issue that will need to be resolved as part 
>> of LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>
>> This working group last call ends on October 22.  Comments should be 
>> sent to the CCAMP mailing list.  Please remember to include the 
>> technical basis for any comments.
>>
>> Positive comments, e.g., "I've reviewed this document and believe it 
>> is ready for publication", are welcome!
>>
>> Please note that we're still missing some IPR statements.  Any 
>> forthcoming publication request will be delayed by late IPR 
>> statements/disclosures.
>>
>>
>> Thank you,
>> Lou (and Deborah)
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>