Subject: [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: Lou Berger <[email-masked]>
Date: Tue, 01 Oct 2013 12:34:49 -0400

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)

---

From: Lou Berger <[email-masked]>
Date: Tue, 22 Oct 2013 16:34:00 -0400

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

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Tue, 29 Oct 2013 10:38:27 +0000

Hi all,

> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21

We propose an encoding of ITU application codes on 64 bits of Optical Interface Class (Section 4.2), just wandering if we already had any ITU/Q6 feedback or we are just ok with proposed encoding.

I'm ok with the rest of LC documents

Cheers
G

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:25:27 -0400

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:26:03 -0400

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

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

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

- s/inputinput/input

- s/outputoutput/output

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That's it on this one,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:27:18 -0400

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: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:28:05 -0400

Authors,

- In two places
  s/These routing enhancements are required/These routing enhancements
are applicable

- Do you want to reference
draft-ietf-ccamp-gmpls-general-constraints-ospf-te? Perhaps in the intro.

- Section 2, SUB-TLV ordering
  Looks like this ordering matches rwa-info, even though the encoding
  document doesn't. (Suggest the encoding document be fixed.)

- Section 2 says:

   All sub-TLVs defined here may occur at most once in any given
   Optical Node TLV. "At most once" means that if there is sub-TLV
   related information, it should be always included.

   The second sentence reads to me to be closer to "at least once".
   "At most once" means no more than one time. Please clarify your
   intent.

- Section 2.1: title
  s/Sub-TLV Details/Resource Block Information

- Section 2.1, 1st paragraph
  Looks like this belongs at the end of the section 2 (intro)

- Section 2.1, should be sub-sub-tlv, and there are 4 not 3 or 5

   There are four nested sub-sub-TLVs defined in the Resource Block
   Information sub-TLV.

   Value          Length      sub-Sub-TLV Type

  also add lines for "Input Bit Rate List"

- Sections 2.1.1->2.1.4
  shouldn't these be sections 2.2 -> 2.5?

- Section 2.1.3
  Drop "16 bit"

- Section 3:
  Don't you want to require the use of the RFC6205 defined label format
  for interfaces advertised with  WSON-LSC?

- Section 6:
  Acee's comment on IANA applies here too. (Should look at his other
  comments too and see if they apply to this document.)

That's it on this one,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:28:01 -0400

Authors,

- You define a new top-level TLV, the Generic Node Attribute TLV.  Did
you consider using the Node Attribute TLV defined in RFC5786? Why not
use it?

- The Generic Node Attribute TLV is underspecified as is.
  - What is the sub-tlv format
  - how are unknown TLVs handled
  - are there ordering or other processing constraints
  - etc.

- Section 2.1 and 3.1:
  no need to defined the type twice, drop "(the type is TBD by IANA)"

  the TLV isn't defined in GEN-ENCODE, the format of the value field is.
  in both sections:
  s/meaning and format of this sub-TLV/meaning and format of the sub-TLV
value field

- Section 4
  OLD
   The flooding of Opaque LSAs must follow the rules
   specified in [RFC2328], [RFC5250], [RFC3630], [RFC4203].
NEW
   The flooding rules of Opaque LSAs are
   specified in [RFC2328], [RFC5250], [RFC3630], [RFC4203].

- Section 4, last paragraph
  Text should be aligned with the preexisting TE procedures as defined
  in Section 3 of RFC3630.

- Section 7
  Looks like Acee already covered this section.

- References. [RFC6205] is listed but not used.

That's it on this one,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:28:31 -0400

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

- in document
  s/Bi-Directional/Bidirectional

- Abstract
  s/Such extensions are necessary/Such extensions are applicable
  drop "bidirectional LSPs, and"

- Section 1

   These extensions build on previous work for the control of lambda
   and G.709 based networks.

  Please add appropriate references.

  It seems to that it would be worth mentioning the rwa-info document
  and the encoding document in this section.

- section 3.1
  s/MUST/needs to

- Section 3.3
  s/MAY/can
  s/MAY/need to be

- Section 3.4
  s/MAY/can

- section 3.5 title
  s/Out of Scope/Optical Impairments

- Section 4.2:
   To target a specific node, this section defines a WSON_Processing
   object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
   defined in [RSVP-RO].

   The content of this object is defined in the subsequent sections.
   (See Section 4.3 for <RBInformation> TLV and Section 4.4 for
   <WavelengthSelection> TLV, respectively.)

 Do you mean

   To target a specific node, this section defines a WSON_Processing
   HOP Attribute TLV which is processed according to the procedures
   defined in [RSVP-RO].

   The content of this TLV is defined in the subsequent sections.
   (See Section 4.3 for <RBInformation> sub-TLV and Section 4.4 for
   <WavelengthSelection> sub-TLV, respectively.)

  if yes, also need to s/WSON Processing object/WSON Processing TLV
  in rest of document.

- Section 4.2
  You need to define the Length.  Perhaps. replace the whole definition:
OLD

   The WSON Processing object encoding is defined as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Value                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEW
  The WSON Processing carries sub-TLVs of the same format as a HOP
  Attributes TLV, as defined in [RSVP-RO].

- Section 4.3. "... PathErr SHALL be generated." Which code/value?
  Are you sure? Generally malformed messages don't result in a PathErr.
  What is an upstream node expected to do with the PathErr?

  How should other parsing errors be handled?

  What about allocation errors?

- Section 4.4

  I'm really confused by this sub-tlv.  Is it intended to be an end to
end construct, information that is used/updated hop-by-hop, or used at
specific hops only?  I suspect that the desire is for this to be
communicated end to end and accessible at each hop.  If so, it looks
like then intent is for this to be carried as a TLV in the
LSP_ATTRIBUTES Object.  Is this correct?  If so the section needs to be
updated accordingly.

- Section 5

I'm really not sure that this section adds anything beyond what is
already stated in other documents/RFCs, and it doesn't match this
documenting being a protocol specification.  I can see some informative
value in the third paragraph.  I suggest moving just this paragraph to
the end of section 4.3 and dropping the rest.

- Section 6
  I think this section needs to be replaced.  Perhaps use the following
which is based on draft-ietf-ccamp-gmpls-signaling-g709v3

   This document is builds on the mechanisms defined in  [RFC3473],
   and only differs in specific information communicated. As such,
   this document introduces no new security considerations to the
   existing GMPLS signaling protocols. See [RFC3473], for
   details of the supported security measures. Additionally,
   [RFC5920] provides an overview of security vulnerabilities and
   protection mechanisms for the GMPLS control plane.

- Section 7
  This section needs a bit of work  See
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-12#section-11
for an example.  Contact me off list if you think need help with
specific text.

That's it on this one,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Oct 2013 14:27:04 -0400

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.

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

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

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

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

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

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

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

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

That's it on this one,
Lou

---

From: Leeyoung <[email-masked]>
Date: Tue, 29 Oct 2013 19:08:57 +0000

Hi Giovanni,

I thought 64 bit field has been already assigned for the application codes in Section 4.2.1 as follows: 

"In case of ITU Application Code, the mapping between the string defining the application code and the 64 bits number implementing the optical interface class is given in the following sections."

Let me know if this is good enough. 

Thanks.
Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giovanni Martinelli (giomarti)
Sent: Tuesday, October 29, 2013 5:38 AM
To: Lou Berger
Cc: 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

Hi all,

Cheers
G

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Oct 2013 08:58:27 -0400

Authors,

Sorry, I missed an important one when writing up my notes:

Somewhere you should state that the LSPs signaled per the document must use
   Switching Type = WSON-LSC [WSON-OSPF]
   Encoding Type = Lambda [RFC3471]
   Label format = per [RFC6205]

You should probably also state that this draft updates 5205 in that it
permits use of the defined label type for WSON-LSC.  This will need to
be mentioned in both the abstract and in the body.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Oct 2013 09:14:06 -0400

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

Lou