Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling

From: Leeyoung <[email-masked]>
Date: Wed, 6 Nov 2013 18:39:39 +0000

Hi,

Thanks all of you who provided good comments to WSON related drafts. The editors will try to respond all the comments and resolve any issues pending and publish the updated drafts shortly. 

Regards,
Young on behalf of editors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, October 30, 2013 8:14 AM
To: CCAMP
Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling

The WG last call is complete.  Authors, please address all received comments.

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

---

From: Leeyoung <[email-masked]>
Date: Thu, 7 Nov 2013 21:42:06 +0000

Hi Lou,

In the update just published, all your general comments have been applied to draft-ietf-ccamp-rwa-info. 

Thanks.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, October 29, 2013 1:25 PM
To: CCAMP; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - rwa-info, general-constraint-encode, rwa-wson-encode, gmpls-general-constraints-ospf-te, wson-signal-compatibility-ospf, wson-signaling

Authors,
	I have some general comments on these documents as a set, i.e., that apply to all documents.  I also have document specific comments that I'll send separately.

Note that I'm the document shepherd, see RFC 4858 for more information.

General comments:

- Broken cross references:  The documents have a lot of pointers to each other, many of which are broken and need to be fixed.  For example (and NOT the only one!) the signaling document has:
   <RBInformation> is defined in Section 4.1 of [WSON-Encode].

1. While the section reference is correct (but check others as this isn't always the case), there is no <RBInformation> defined in the document.  The problem here is inconsistent usage of BNF and expanded style names.  I think it's fine to use both, e.g., <RBInformation> and Resource Block Information, but there needs to be consistent cross referencing and definitions.  This problem also exists within drafts too.

2. As above, please verify cross referenced section numbers

- It looks like there are still some vestigial references to "ingress"
and "egress" (noted as replaced by "input" and "output").  This also shows in abbreviations where 'E' is used rather than 'O'.

- In a number of documents s/GPID/G-PID

- Revision history should be removed at this point.

- Please ensure abbreviations are expanded on first use. See http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt for additional guidance.

- Your terminology sections include terms that are only used in this section.  This does not make sense.  The terminology section also duplicates what is already in RFC6163. I suggest eliminating such sections and adding references to RFC6163 if/where needed.

- Please double check that there are no idnits

- Please update any references that are now RFCs, e.g., RBNF

- A general discussion on security in GMPLS networks can be found in RFC5920.  I suggest adding an informative reference in your security sections.

Thanks,
Lou

On 10/1/2013 12:34 PM, Lou Berger wrote:
> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-
> 11
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-
> ospf-te-05
> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-
> ospf-12

---

From: Leeyoung <[email-masked]>
Date: Thu, 7 Nov 2013 22:32:16 +0000

Hi Lou,

Here's my response to specific comments to draft-ietf-ccamp-rwa-info. 

Thanks.
Young
-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 1:26 PM
To: CCAMP; [email-masked]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

Authors,
	I have some comments on draft-ietf-ccamp-rwa-info. Most 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.

- You say: " relatively static on the time scales of
   connection establishment."  I suspect you mean:
   " relatively static and independent of connection establishment."

YOUNG>> Yes, and replaced with your suggestion.

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

YOUNG>> [Switch] moved to normative reference section.

- s/inputinput/input

- s/outputoutput/output

YOUNG>> Done.

- Section 4.1: " ...  and path computation [Encode]."
  While a normative reference to [Encode] is certainly just fine, I
  reference is unclear in this context.

YOUNG>> [Encode] deleted.

- Why say "potentially switched" vs just "switched"?  if "potentially"
doesn't add anything please drop it, otherwise please clarify.

YOUNG>> "potentially" removed.

- Section 4.2: SRNG
  I don't see SRNG in any other documents.  Am I missing it, is SRNG used anywhere?

YOUNG>> SNRG section removed. 

- Section 5: I found it hard to parse the following:
   As resources are the smallest identifiable unit of
   processing resource, one can group together resources into blocks if
   they have similar characteristics relevant to the optical system
   being modeled, e.g., processing properties, accessibility, etc.
  Do you perhaps mean?
   A resource is the smallest identifiable unit of
   allocation. One can group together resources into blocks if
   they have similar characteristics relevant to the optical system
   being modeled, e.g., processing properties, accessibility, etc.

YOUNG>> Agreed. Changed.

-Section 5.1: States: " Note that except for <ResourcePoolState>
  all the other components of <ResourcePool> are relatively static."
  But the related definitions are:

   <ResourcePool> ::= <ResourceBlockInfo>...
   [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
   [<RBPoolState>] (section 5)

   <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>] (section 7.2)

   What's the intent here?

YOUNG>> See the cleaned text in Section 7.2:
   Currently the only node information that can be considered dynamic
   is the resource pool state and can be isolated into a dynamic node
   information element as follows:

   <DynamicNodeInfo> ::=  <NodeID> [<ResourcePool>]

   Where

   <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>] 

- Section 5.2: What is the asterisk "*" all about.

YOUNG>> That means whatever within () can be repeated. 

- Section 5.3.3 says
      <client-signal-list>::=[<GPID>]...
   should <client-signal-list> be <ClientSignalList> as defined in
   section 5.2?

YOUNG>> Yes; Changed to ClientSignalList.

- Section 5.3.4 repeats section 5.2.  replace:
  " as follows:

     <ProcessingCapabilities> ::= [<NumResources>]
     [<RegenerationCapabilities>] [<FaultPerfMon>] [<VendorSpecific>]"
  with "."

YOUNG>> Done.

- Section 6.5: I found the following language confused:
   This allows for the
   definition of one additional link metric value for traffic
   engineering separate from the IP link state routing protocols link
   metric.
  How about:
   This allows for the
   identification of a data channel link metric value for traffic
   engineering that is separate from the metric used for
   path cost computation of the control plane.

YOUNG>> Accepted the new text.

- Section 6.6: Drop "(Wavelength)" from the title, this can be confused with the "WSON" indication in section headings

YOUNG>> agreed. 

- Section 6.6.: You just say (Wavelength) and leave it to the reader to infer the relationship between it and a label. I suggest you make the relationship explicit.

YOUNG>> See the new text in the beginning of section 6.6: "Port label restrictions could be applied generally to any label
   types in GMPLS by adding new kinds of restrictions. Wavelength is a type of label."

- Section 6.6.  I think you have a BNF problem here.  The BNF says restriction parameters are always optional, but your text says that there are requirements based on <RestrictionTypes>.  I think the BNF needs to be aligned with the text and reflect the requirements.

YOUNG>> Made all mandatory element. 

- Section 7: You say " An example usage of this
   information in a WSON setting is given in [Shared]."

  References to URLs should be avoided (particularity when they aren't
  valid even at the time of publication, i.e., now).

YOUNG>> URL Reference removed. 

That's it on this one,
Lou

---

From: Leeyoung <[email-masked]>
Date: Tue, 12 Nov 2013 22:12:40 +0000

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:[email-masked]] 
Sent: Tuesday, October 29, 2013 1:27 PM
To: CCAMP; [email-masked]
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.

- 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

---

From: Leeyoung <[email-masked]>
Date: Wed, 13 Nov 2013 02:06:01 +0000

Hi Lou,

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

Thanks.
Young

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

Authors,

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

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

YOUNG>> Aligned where possible. 

- section 2

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

YOUNG>> sub-TLVs dropped. 

- Section 3.1
    0 1 2 3 4 5 6 7 8
    | Connectivity  |

YOUNG>> Your suggested encoding accepted. 

- Section 4.

YOUNG>> No.

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? 

YOUNG>> Added TLV format

YOUNG>> Not sure what this is. 

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

- Section 4.1

YOUNG>> Aligned. 

- Section 3.4, 4.1

YOUNG>> Corrected to I & O.

- Section 4.2.1

YOUNG>> Done. 

- Section 4.2.2, 4.2.3

YOUNG>> Changed to D and F now. 

WRT Section 8:

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

That's it on this one,
Lou

---

From: Leeyoung <[email-masked]>
Date: Wed, 13 Nov 2013 22:09:04 +0000

Hi Lou,

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

Thanks.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, October 29, 2013 1:27 PM
To: CCAMP; [email-masked]
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.

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