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

Leeyoung <> Wed, 13 November 2013 02:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66AFA21E8139 for <>; Tue, 12 Nov 2013 18:06:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.356
X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qoAU4zuBYMh0 for <>; Tue, 12 Nov 2013 18:06:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D91021E8131 for <>; Tue, 12 Nov 2013 18:06:07 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU98093; Wed, 13 Nov 2013 02:06:07 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Nov 2013 02:05:10 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Nov 2013 02:06:06 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 18:06:02 -0800
From: Leeyoung <>
To: Lou Berger <>, CCAMP <>, "" <>
Thread-Topic: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
Thread-Index: AQHO1NSag8RQYrwjyUubb+r8ssXAkZoiUdTw
Date: Wed, 13 Nov 2013 02:06:01 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2013 02:06:14 -0000

Hi Lou,

Please see inline for my responses to your comments. Let me know if there are still further issues. 


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

	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

YOUNG>> Done. See Terminology Section changed as follows: 

Refer to [RFC6163] for CWDM, DWDM, RWA, WDM. 
Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool.

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

YOUNG>> Moved the text from introduction to Section 3.1 and added the : 
"The For the Input and Output Link Set Fields, the Link Set Field encoding defined in [Gen-Encode] is to be used. A Label Set Field MUST carry a label as defined in [RFC6205]."

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

YOUNG>> Aligned where 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.

YOUNG>> Added "Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool." (Terminology Section).
YOUNG>> Added the following paragraph in the beginning of 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."

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

YOUNG>> sub-TLVs dropped. 

- 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
    0 1 2 3 4 5 6 7 8
    |   Reserved  |C|

YOUNG>> Your suggested encoding accepted. 

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

YOUNG>> I don't see why there are multiple sub-sub-TLVs of the same type. In case where there are multiple sub-sub-TLVs of the same type, there would be no error as these information are not order-sensitive. Is this what you have in mind? 

  - What is the sub-sub-TLV header (TL format)?

YOUNG>> Added TLV format

  - Are there any alignment requirements?

YOUNG>> Not sure what this is. 

  - 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

YOUNG>> Please see the other email response to this comment. 

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

YOUNG>> Aligned. 

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

YOUNG>> Corrected to I & O.

- Section 4.2.1

YOUNG>> Done. 

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

YOUNG>> Changed to D and F now. 

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?

YOUNG>> All corrected. [WSON-Info] is normative. 

That's it on this one,
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:
>> (Informational, IPR Disclosed)
>> -11
>> (Standards Track, IPR Disclosed)
>> (Standards Track)
>> -ospf-te-05
>> (Standards Track, IPR Disclosed)
>> -ospf-12
>> (Standards Track, IPR Disclosed)
>> (Standards
>> Track) Also has one open issue that will need to be resolved as part 
>> of LC, see
>> 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
> _______________________________________________
> CCAMP mailing list