Subject: [Pce] Chair review of draft-lee-pce-flexible-grid

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 Feb 2019 22:09:34 -0000

Hi,

As this document is being polled for adoption, I thought I should review
it.  There are a considerable number of nits, but nothing that prevents
adoption in my view.  In the event that this document is adopted, I 
think the authors would do well to address the changes shortly 
afterwards.  If the document is not adopted but the authors want to 
continue with the work, they should pick up these nits.

Thanks,
Adrian

---

Please fix the RFC 2119 boilerplate to use the latest form...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

...You'll need to add a reference to RFC 8174

---

idnits shows a lot of issues with references. It is not hard to run
idnits so please get into the habit of running it before you ask for
WG adoption.

For your convenience, here are all of the issues

  == Missing Reference: 'RFC3209' is mentioned on line 318, but not
     defined                                                            

  == Unused Reference: 'RFC2863' is defined on line 654, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6566' is defined on line 683, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7420' is defined on line 687, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7446' is defined on line 692, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5521' is defined on line 708, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6205' is defined on line 712, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7689' is defined on line 719, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7688' is defined on line 722, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC7581' is defined on line 731, but no explicit
     reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 7698

The last issue is a warning, and you can keep the downwards reference if
you think it is the right thing to do.

---

Please check that all abbreviations are expanded on first use.

I see:

ERO
PCE

---

Move the first sentence of paragraph 4 of Section 3 down to the end of
that paragraph so that the use of the term "flexi-grid" comes after it
has been explained.

---

Section 3 has

   This document provides PCEP extensions to support Routing and
   Spectrum Assignment (RSA) in in Spectrum Switched Optical Networks
   (SSON)[RFC7698].

s/in in/
s/(SSON)[RFC7698]/(SSON} [RFC7698]/

The terms RSA and SSON are, of course, defined in RFC 7698. But the
terms come as a surprise in this document. Perhaps you could insert a
short paragraph above this one to say...

   The terms "Routing and Spectrum Assignment" (RSA) is introduced in
   [RFC7698] to refer to blah blah.  The term "Spectrum Switched
   Optical Networks" is also introduced in [RFC7698] and indicates a
   network that is blah blah blah.

That would leave you with

   This document provides PCEP extensions to support RSA in SSONs.

---

Section 3

s/extensions are going to be specified/extensions are specified/

---

Section 4

Bullet b) has a second sentence (beginning "This document aligns...")
that doesn't seem specific to that bullet. Maybe it belongs at the top
of the section.

---

Section 4 has

   Additionally, given a range of potential spectrums to allocate, the
   request SHOULD convey the heuristic / mechanism to the allocation.

The reader is left wondering how to meet that "SHOULD" and also why to
vary that "SHOULD".

---

Section 4 needs a reference to RFC 5511 to explain the notation.

---

Section 4

   If the SA object is present in the request, it MUST be encoded after
   the ENDPOINTS object.

I think that should be 'GENERALIZED ENDPOINTS object'

---

Section 4 has

   The following new flags SHOULD be set

But I think you are equally happy for the bit to be set or cleared.

---

4.1

   This TLV
   MUST NOT be used when the M bit is cleared.

I think you may mean...

   SHOULD NOT be present and MUST be ignored

---

I think you are going to need an IANA registry for the Frequency-Slot
Assignment (FSA) Method.

---

4.1 is going to need an explanation of what the 'n' parameter is.

---

4.1

      -  S bit not supported: a PathErr MUST be generated with the
         Error Code "Routing Problem" (24) with error sub-code
         "Unsupported Frequency slot Selection Symmetry value" (TDB).

This is a bit unclear. Presumably the issue is "S bit clear not 
supported".  You might consider reversing the meaning of the S bit and
then this would be a lot clearer.

---

Please distinguish the different TBDs as TBD1, TBD2, etc.

(And note you have several cases of "TDB")

---

4.1

   As defined in
   [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and
   LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set
   accordingly.

It is not clear what R bit you are referring to.

---

4.1

   A Frequency Slot Selection TLV can be constructed by a node and
   added to an ERO Hop Attributes subobject in order to be processed
   by downstream nodes (transit and egress).  As defined in
   [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and
   LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set
   accordingly.

   Once a node properly parses the Spectrum Selection sub-TLV
   received in an ERO Hop Attributes subobject, the node use the
   indicated spectrum assignment method (at that hop) for the LSP.
   In addition, the node SHOULD report compliance by adding an RRO
   Hop Attributes subobject with the WSON Processing Hop Attribute
   TLV (and its sub-TLVs) that indicate the utilized method.
   Frequency-Slot Selection TLVs carried in an RRO Hop Attributes
   subobject are subject to [RFC7570] and standard RRO processing;
   see [RFC3209].

There's something odd here. 

- Doesn't this section say/imply that the Frequency-Slot Selection TLV
  belongs in the Spectrum Assignment object? Why are you talking about
  TLVs in the Hop Attribute TLV and the ERO Hop Attributes subobject?
  Maybe the first paragraph here should read...
  A Frequency Slot Selection TLV can also be constructed by a node...

- Why are you talking about the Spectrum Selection sub-TLV? Doesn't that
  belong in Section 5?

---

4.2

   For any request that contains a Frequency-slot assignment, the
   requester (PCC) MUST be able to specify a restriction on the
   frequency-slots to be used.

I think you can s/MUST/must/

---

4.2

   <Frequency-lot Restriction Constraint> ::=

                  <Action> <Count> <Reserved>

                  (<Link Identifiers> <Freq-slot Restriction>)...

I don't think you need to list every field of the frequency slot TLV
in the RBNF, and in particular you should not list the reserved field.

---

4.2

   Note that a PCC MAY add a spectrum restriction that applies to all
   links by setting the Count field to zero and specifying just a set
   of spectrums.

I think s/spectrum/frequency slot/   twice

---

4.2

   and Section 3.3.1 for the Spectrum Restriction Field encoding,
   respectively.

Why do you point us at the definition of this field?

---

4.2.1 broken reference

---

5.

   The Spectrum Allocation TLV type is TBD, recommended value is TBD.

No need to recommend a value of TBD :-)

---

5.

   The type
   value of the Spectrum Restriction Constraint TLV is TBD by IANA.

This seems out of place and is the first mention of this TLV.

---

Section 7 could use some external references.

---

Section 8

   IANA maintains a registry of PCEP parameters. IANA has made
   allocations from the sub-registries as described in the following
   sections.

Hmmm, I think IANA has not actually made these allocations. You should
say "IANA is requested to make allocations..."

---

I think the titles of 9.1 and 9.2 may be reversed.

---

From: Leeyoung <[email-masked]>
Date: Mon, 18 Feb 2019 23:31:18 +0000

Hi Adrian,

Thanks for your thorough review of this draft.  The authors will definitely address the changes your pointed out. The best scenario is the adoption and then update these changes. 

Thanks.
Young 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, February 18, 2019 4:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Chair review of draft-lee-pce-flexible-grid

Hi,

As this document is being polled for adoption, I thought I should review it.  There are a considerable number of nits, but nothing that prevents adoption in my view.  In the event that this document is adopted, I think the authors would do well to address the changes shortly afterwards.  If the document is not adopted but the authors want to continue with the work, they should pick up these nits.

Thanks,
Adrian

---

---

idnits shows a lot of issues with references. It is not hard to run idnits so please get into the habit of running it before you ask for WG adoption.

The last issue is a warning, and you can keep the downwards reference if you think it is the right thing to do.

---

I see:

ERO
PCE

---

Move the first sentence of paragraph 4 of Section 3 down to the end of that paragraph so that the use of the term "flexi-grid" comes after it has been explained.

---

Section 3 has

s/in in/

The terms RSA and SSON are, of course, defined in RFC 7698. But the terms come as a surprise in this document. Perhaps you could insert a short paragraph above this one to say...

---

Section 3

---

Section 4

Bullet b) has a second sentence (beginning "This document aligns...") that doesn't seem specific to that bullet. Maybe it belongs at the top of the section.

---

Section 4 has

The reader is left wondering how to meet that "SHOULD" and also why to vary that "SHOULD".

---

---

Section 4

---

Section 4 has

---

4.1

   This TLV

I think you may mean...

---

I think you are going to need an IANA registry for the Frequency-Slot Assignment (FSA) Method.

---

---

4.1

This is a bit unclear. Presumably the issue is "S bit clear not supported".  You might consider reversing the meaning of the S bit and then this would be a lot clearer.

---

---

4.1

   As defined in

---

4.1

---

4.2

---

4.2

I don't think you need to list every field of the frequency slot TLV in the RBNF, and in particular you should not list the reserved field.

---

4.2

---

4.2

---

4.2.1 broken reference

---

5.

---

5.

   The type

---

---

Section 8

Hmmm, I think IANA has not actually made these allocations. You should say "IANA is requested to make allocations..."

---

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 20 Feb 2019 04:50:01 +0000

Hi Authors, 

Most of the comments that we received for the WSON RWA I-D [https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/] during the IESG reviews are also applicable to this document. I would request the authors to also update this I-D and incorporate those comments while it is fresh in your minds. I am fine with this being done post WG adoption is resolved.

Thanks! 
Dhruv

--

Dhruv Dhody 
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru, Karnataka - 560066 
Tel: + 91-80-49160700 Ext 71583 II Email: [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

> From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 19 February 2019 03:40
> To: [email-masked]
> Subject: [Pce] Chair review of draft-lee-pce-flexible-grid
> 
> Hi,
> 
> adoption in my view.  In the event that this document is adopted, I think
> the authors would do well to address the changes shortly afterwards.  If
> the document is not adopted but the authors want to continue with the work,
> they should pick up these nits.
> 
> Thanks,
> Adrian
> 
> ---
> 
> ....You'll need to add a reference to RFC 8174
> 
> ---
> 
> idnits shows a lot of issues with references. It is not hard to run idnits
> so please get into the habit of running it before you ask for WG adoption.
> 
> that paragraph so that the use of the term "flexi-grid" comes after it has
> been explained.
> 
> ---
> 
> Section 3 has
> 
> The terms RSA and SSON are, of course, defined in RFC 7698. But the terms
> come as a surprise in this document. Perhaps you could insert a short
> paragraph above this one to say...
> 
> Bullet b) has a second sentence (beginning "This document aligns...") that
> doesn't seem specific to that bullet. Maybe it belongs at the top of the
> section.
> 
> ---
> 
> Section 4 has
> 
> This is a bit unclear. Presumably the issue is "S bit clear not supported".
> You might consider reversing the meaning of the S bit and then this would
> be a lot clearer.
> 
> ---
> 
> I don't think you need to list every field of the frequency slot TLV in
> the RBNF, and in particular you should not list the reserved field.
> 
> ---
> 
> 4.2
> 
> Hmmm, I think IANA has not actually made these allocations. You should say
> "IANA is requested to make allocations..."
> 
> ---
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Leeyoung <[email-masked]>
Date: Wed, 20 Feb 2019 16:23:17 +0000

Hi Dhruv,

Yes, that is great idea. As soon as pce-wson draft is finalized, we will address Adrian's WG chair's comment and make it stable. 

Thanks.
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Tuesday, February 19, 2019 10:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Chair review of draft-lee-pce-flexible-grid

Hi Authors, 

Thanks! 
Dhruv

--

Dhruv Dhody
Lead Architect
Network Business Line
Huawei Technologies India Pvt. Ltd.
Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield Bengaluru, Karnataka - 560066
Tel: + 91-80-49160700 Ext 71583 II Email: [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

> As this document is being polled for adoption, I thought I should 
> review it.  There are a considerable number of nits, but nothing that 
> prevents adoption in my view.  In the event that this document is 
> adopted, I think the authors would do well to address the changes 
> shortly afterwards.  If the document is not adopted but the authors 
> want to continue with the work, they should pick up these nits.
> 
> Thanks,
> Adrian
> 
> ---
> 
> idnits so please get into the habit of running it before you ask for WG adoption.
> 
> The last issue is a warning, and you can keep the downwards reference 
> if you think it is the right thing to do.
> 
> ---
> 
> You might consider reversing the meaning of the S bit and then this 
> would be a lot clearer.
> 
> ---
>