Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-general-constraint-encode

[Leeyoung <[e-mail]>]

Hi Lou,

Here's my response inline to your comments on draft-ietf-ccamp-general-constraint-encode.

Thanks.
Young

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

Authors,
	I have some comments on this document. A number 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

YOUNG>> Done. 

- I'm a bit surprised that this document does *not* reference the rwa-info draft.  Given that it provides the context for this document, it should be there, and probably as a normative reference.

YOUNG>> RWA-INFO referenced as a Normative reference in Section 2 as follows: "This section provides encodings for the information elements defined
   in [RWA-INFO] that have general applicability."


- Your references to [Switch] seem almost normative in nature. I suspect that this is not your intent as it is listed as an informative reference.  Please revisit your references and ensure that the draft does not depend on any informative references.  (Either change the text, or move the reference to normative.) Perhaps these are places where a reference to rwa-info are more appropriate.

YOUNG>> Cleaned up the reference. [Switch] is placed as a normative reference.

- An editorial comment on section ordering:  Section 2 is ordered as
follows:

   2. Encoding.......................................................6
      2.1. Link Set Field............................................6
      2.2. Label Set Field...........................................8
      2.3. Available Labels Sub-TLV.................................11
      2.4. Shared Backup Labels Sub-TLV.............................11
      2.5. Connectivity Matrix Sub-TLV..............................12
      2.6. Port Label Restriction sub-TLV...........................13

  Is there a logical order to these sections? They don't seem to be
  aligned with the rwa-info draft which has:

   4. Node Information (General).....................................8
      4.1. Connectivity Matrix.......................................9
      4.2. Shared Risk Node Group...................................10

   6. Link Information (General)....................................17
      6.6. Port Label (Wavelength) Restrictions.....................18

   7. Dynamic Components of the Information Model...................21
      7.1. Dynamic Link Information (General).......................22

   Perhaps it makes sense from a readability standpoint to realign to
   match rwa-info?


YOUNG>> Did some rearranging to match with that of rwa-info where possible as follows:

      2.1. Connectivity Matrix Field.................................5
      2.2. Port Label Restriction Field..............................7
      2.3. Link Set Field...........................................10
      2.4. Available Labels Field...................................12
      2.5. Shared Backup Labels Field...............................13
      2.6. Label Set Field..........................................14


- Section 2 says:
   A type-length-value (TLV) encoding of the general connectivity and
   label restrictions and availability extensions is given in this
   section. This encoding is designed to be suitable for use in the
   GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in
   the PCE protocol PCEP [PCEP]. Note that the information distributed
   in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs
   within TLVs and this document makes use of such constructs...

 Yet there are no types or (sub)TLVs actually defined in this  document.  As such, I think this document should not use the term  "sub-TLV" for the information elements it defines. In most cases  this just means substituting "the <XYZ_information_element> sub-TLV"
 with just "<XYZ_information_element>".

 Section 2 can be revised to read something along the lines of:
   This section provides encodings for the information elements defined
   in [RWA-INFO] that have general applicability.  The encodings are
   designed to be suitable for use in the
   GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in
   the PCE protocol PCEP [PCEP]. Note that the information distributed
   in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs
   within TLVs and this document defines elements to be used within
   such constructs...

YOUNG>> All references to sub-TLVs and sub-sub-TLVs were removed and added the following paragraphs in Section 2:

   This section provides encodings for the information elements defined
   in [RWA-INFO] that have applicability to WSON.  The encodings are
   designed to be suitable for use in the GMPLS routing protocols OSPF
   [RFC4203] and IS-IS [RFC5307] and in the PCE protocol (PCEP)
   [RFC5440]. Note that the information distributed in [RFC4203] and
   [RFC5307] is arranged via the nesting of sub-TLVs within TLVs and
   this document defines elements to be used within such constructs.
   Specific constructs of sub-TLVs and the nesting of sub-TLVs of the
   information element defined by this document will be defined in the
   respective protocol enhancement documents.



- section 2.2.
   Labels are variable in lengh and need not be 4 bytes long.  This
   needs to be represented and accounted for in the encodings defined
   in this section.

YOUNG>> Agreed. Added the following sentence in Section 2.6 (new section due to shuffling):
   "Labels are variable in length. The second 32 bit field is a part of the base label used as a
   starting point in many of the specific formats."


- Section 2.2.1 and 2.2.2 says "Num Labels (not used)" and
   "Num Labels is not used in this particular format since the Length
   parameter is sufficient to determine the number of labels in the
   list."

  Is there a reason to not set the Num Labels Field in these cases?
  Recall that labels are themselves variable length fields.

YOUNG>> The texts concerning the Num Labels are wrong. In all cases, the Num Labels are used in the new text.


- section A.2
  s/With the Grid/Using the label format defined in [RFC 6205], with the Grid...
  s/Num Wavelengths/Num Labels (multiple places)

YOUNG>> Corrected. 

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0    | Num Wavelengths = 40  |    Length = 20 bytes          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  shouldn't Num Labels either be 0 (if unused) or = 7 (assuming num
  labels used in this case)?

YOUNG>> Yes, it should be 7. Corrected.

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
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp