Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

From: Dhruv Dhody <[email-masked]>
Date: Tue, 18 Jan 2022 18:46:43 +0530

Hi WG,

This email starts a 2-weeks working group last call
for draft-ietf-pce-pcep-stateful-pce-gmpls-16 [1].  Please indicate your
support or concern for this draft. If you are opposed to the progression of
the draft to RFC, please articulate your concern. If you support it, please
indicate that you have read the latest version and it is ready for
publication in your opinion. As always, review comments and nits are most
welcome.

The WG LC will end on 1st Feb 2022.

A general reminder to the WG to be more vocal during the last-call/adoption
and help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/

---

From: Zhenghaomian <[email-masked]>
Date: Wed, 19 Jan 2022 02:41:51 +0000

Hi Folks,

I have read the latest version of the document, it is very useful for the PCEP applicability in GMPLS-based network, and we can foresee some future extensions. I believe it is ready for publication. Thank you.

Best wishes,
Haomian (as co-author)

发件人: Pce [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2022年1月18日 21:17
收件人: [email-masked]
抄送: [email-masked]; pce-chairs <[email-masked]>
主题: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

This email starts a 2-weeks working group last call for draft-ietf-pce-pcep-stateful-pce-gmpls-16 [1].  Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome.

A general reminder to the WG to be more vocal during the last-call/adoption and help us unclog our queues :)

Thanks,
Dhruv & Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Jan 2022 20:47:11 -0000

Hi,

It's been a journey for this draft! July 2012 :-)

Glad that we are finally in a place to last call it, and excellent to

know there is an implementation.

Here is my review in support of the last call. You'll see that my minor

points are essentially editorial (i.e., not asking to change the

functional behaviour described in the document). There are also some

nits. With these issues fixed, I think the document is ready to 

proceed.

Best,

Adrian

===

== Minor ==

6.

You need text in this section as...

   This section uses Routing Backus-Naur Form (RBNF) [RFC5511] to 

   describe message formats.

But note that the comments below might do away with the RBNF!

---

6.1

It is really hard to tell what this document has changed over RFC 8231.

I don't think you should repeat what is already defined, and, as far as

I can tell, nothing in the RBNF has changed.

That means the section should read...

   The format of the PCRpt message is unchanged from Section 6.1 of

   [RFC8231].  However, some of the objects are extended for use with

   this document as follows:

Then, I think you list and describe:

     <intended-path>

     <actual-attribute-list>

     SRP

But not:

     <actual-path>

     <intended-attribute-list>

However, note that you have 

     <intended-attribute-list> is the attribute-list defined in      

   Section 6.5 of [RFC5440] and extended by PCEP extensions. 

...which is meaningless! 

---

Similarly in 6.2

   The format of the PCUpd message is unchanged from Section 6.2 of

   [RFC8231].  However, some of the objects are extended for use with

   this document as follows:

Then, I think you list and describe:

      <intended-path> 

But not:

      <intended-attribute-list>

However, note that you have 

     <intended-attribute-list> is the attribute-list defined in      

   Section 6.5 of [RFC5440] and extended by PCEP extensions. 

...which is meaningless! 

I wonder why there is no pointer to SRP in 7.2.3 from this section.

---

The same applies in 6.3, but the text about what has changed is 

more complicated.

I think...

   The format of the PCInitiate message is unchanged from Section 5.1 of

   [RFC8281].  However, note the following:

   o  The END-POINTS object was been extended by [RFC8779] to include a

      new object type called "Generalized Endpoint".  A PCInitiate 

      message used to trigger a GMPLS LSP instantiation MUST use that 

      extension.

   o  A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS LSP

      instantiation MUST include the END-POINTS with Generalized Endpoint

      object type (even though it is marked as optional in the message

      definition.

   o  The END-POINTS object MUST contain a "label request" TLV per 

      [RFC8779].  The label request TLV is used to specify the switching

      type, encoding type and G-PID of the LSP being instantiated by the

      PCE. 

   o  If unnumbered endpoint addresses are used for the LSP being

      instantiated by the PCE, the unnumbered endpoint TLV [RFC8779] 

      MUST be use to specify the unnumbered endpoint addresses.

   o  The END-POINTS MAY contain other TLVs defined in [RFC8779]. 

---

There is a discrepancy between 5.1, 7.2.1, and 10.1.  In 10.1, you

correctly ask IANA to allocate TBD1 and TBD2.  In 5.1 you refer to

the new bits as TBD1 and TBD2, but in 7.2.1 you:

- Do not refer to TBD1 or TBD2

- Use a figure to specifically imply values for TBD1 and TBD2

I suggest that you:

- remove the figure

- mention TBD1 and TBD2 in the text

---

7.2.2

Will you ask IANA to maintain a registry for the Flags field?

---

7.2.2

You have 

   This sub-object is OPTIONAL in the exclude route object (XRO) and 

   can be present multiple times.  When a stateful PCE receives a PCReq 

   message carrying this sub-object, it SHOULD search for the 

   identified LSP in its LSP-DB and then exclude from the new path 

   computation all resources used by the identified LSP.   

Your use of "SHOULD" here implies that an implementation has a choice to

do something different. You need to say:

- what different thing MAY a PCE do?

- why might it make that choice?

(Or make this "MUST")

---

7.2.3 refers to TBD6, but 10.3 has TBD4

---

In 8.1 and 8.2 you have that the PCE SHOULD do things without specifying

what else it might do and why.  You also have some cases of lower case

"should" which don't seem right.

---

8.3 has

   If the PCC does not support the END-POINTS Object of type 

   Generalized Endpoint, the PCC MUST send a PCErr message with Error-

   type = 3(Unknown Object), Error-value = 2(unknown object type). 

I think this is not new behaviour so you need to point to the spec that

defines this with "...per [RFC5440]..."

== Nits ==

Throughout

Please be careful with "sub-object" and "subobject"

---

1.

s/and does not cover the GMPLS/and do not cover GMPLS/

---

1. Final paragraph

Introduce a new paragraph break before "This document focuses..."

---

1.

s/Protocol extensions is included/Protocol extensions are included/

---

3.

s/PCE, PCUpd message/PCE, a PCUpd message/

s/delegated to PCE/delegated to the PCE/

s/by the PCC to PCE/from the PCC to the PCE/

---

3.

    Furthermore, the Initiation of PCEP are

Is that...

    Furthermore, the Initiation of PCEP sessions are

...or...

    Furthermore, the Initiation phase of PCEP is

...or...

    Furthermore, the PCInitiate PCEP message is

...or...

    Furthermore, the LSP Initiation function of PCEP is

---

3.

s/to initiate the LSP establishment/to initiate LSP establishment/

---

3.

OLD

   Some of these Objects/TLVs 

   may require modifications to incorporate stateful PCE where 

   applicable

NEW

   Where these Objects/TLVs 

   require modifications to incorporate stateful PCE, they are

   described in this document.

END

---

4.

s/were covered in [RFC8231]/are covered in [RFC8231]/

s/provides extension for/provides extensions for/

s/capable to indicate/capable of indicating/

s/capabilities per TE/capabilities a per TE/

---

4.

OLD

        Such information would be needed for 

        PCEP message. 

NEW

        Such information would need to be included 

        in various PCEP messages. 

END

---

4.

s/some technologies path/some technologies, path/

s/Stateful PCEP message also/Stateful PCEP messages also/

---

5. Overview of PCEP Extensions for GMPLS Networks 

I think this might be

5. Overview of Stateful PCEP Extensions for GMPLS Networks 

---

5.1

s/introduced as flag/introduced as flags/

---

5.2

s/attributes include bandwidth/attributes including bandwidth/

s/modified LSP during/modified LSPs during/

---

5.4

s/stateful PCE mechanism/stateful PCE mechanisms/

---

6.1

s/current state of LSP/current state of an LSP/

---

7.2.1

The figure seems to have superfluous blank lines

---

7.2.2

Would be nice if this section was called

7.2.2. New LSP Exclusion Subobject in the XRO

---

7.2.2

The figure calls the field "Flag" but the text has "Flags"

---

7.2.2

     Reserved: MUST be transmitted as zero and SHOULD be ignored on 

     receipt. 

There is no reserved field shown in the figure.

From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: 18 January 2022 13:17
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

Thanks,
Dhruv & Julien

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 19 Jan 2022 17:22:51 -0500

I support publication of this draft.

Looking at the Datatracker this draft has had a very long journey from 2012
and almost at the end of the tunnel.  PCEP has also evolved as well with
stateless PCE in 2017.

This draft provides a PCEP extension extension for GMPLS networks with a
stateful PCE capability bit for  S and I flag, new LSP identifier XRO sub
object, new B flag for SRP object for co-routed paths and new PCEP error
codes.

Extremely valuable specification for operators provisioning of OTN, and
very good to see one implementation.

Kind Regards

Gyan
On Wed, Jan 19, 2022 at 3:47 PM Adrian Farrel <[email-masked]> wrote:

> *From:* Pce <[email-masked]> *On Behalf Of *Dhruv Dhody
> *Sent:* 18 January 2022 13:17
> *To:* [email-masked]
> *Cc:* [email-masked]; pce-chairs <
> [email-masked]>
> *Subject:* [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16
>
>
>
> Hi WG,
>
>
>
> A general reminder to the WG to be more vocal during the
> last-call/adoption and help us unclog our queues :)
>
>
>
> Thanks,
> Dhruv & Julien
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Ramon Casellas" <[email-masked]>
Date: Thu, 20 Jan 2022 07:58:54 +0100

Hi all,

As a contributor (it’s been a while!), I also support publication of this draft

Thank you

Ramon

From: Pce <[email-masked]> On Behalf Of Gyan Mishra
Sent: miércoles, 19 de enero de 2022 23:23
To: [email-masked]
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Looking at the Datatracker this draft has had a very long journey from 2012 and almost at the end of the tunnel.  PCEP has also evolved as well with stateless PCE in 2017.  

This draft provides a PCEP extension extension for GMPLS networks with a stateful PCE capability bit for  S and I flag, new LSP identifier XRO sub object, new B flag for SRP object for co-routed paths and new PCEP error codes.  

Extremely valuable specification for operators provisioning of OTN, and very good to see one implementation.

Kind Regards 

Gyan

On Wed, Jan 19, 2022 at 3:47 PM Adrian Farrel <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

proceed.

Best,

Adrian

===

== Minor ==

6.

---

6.1

     <intended-path>

     <actual-attribute-list>

     SRP

But not:

     <actual-path>

...which is meaningless! 

---

Similarly in 6.2

      <intended-path> 

But not:

...which is meaningless! 

---

more complicated.

I think...

      extension.

      definition.

      PCE. 

---

I suggest that you:

- remove the figure

---

7.2.2

---

7.2.2

You have 

(Or make this "MUST")

---

---

---

8.3 has

 

== Nits ==

Throughout

---

1.

---

1. Final paragraph

---

1.

---

3.

---

3.

Is that...

...or...

...or...

...or...

---

3.

---

3.

OLD

   applicable

NEW

   Where these Objects/TLVs 

END

---

4.

---

4.

OLD

        PCEP message. 

NEW

END

---

4.

---

I think this might be

---

5.1

---

5.2

---

5.4

---

6.1

---

7.2.1

---

7.2.2

---

7.2.2

---

7.2.2

     receipt. 

From: Pce <[email-masked] <mailto:[email-masked]> > On Behalf Of Dhruv Dhody
Sent: 18 January 2022 13:17
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; pce-chairs <[email-masked] <mailto:[email-masked]> >
Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

Thanks,
Dhruv & Julien

_______________________________________________
Pce mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pce

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 25 Jan 2022 14:15:09 +0000

Hi WG,

In CCAMP we’re obviously very interested in this draft.
I reviewed it before the last call and expressed my support, which is still valid for the latest version.

BR
Daniele

From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: den 18 januari 2022 14:17
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

Thanks,
Dhruv & Julien

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 26 Jan 2022 06:47:14 +0000

Support the last call. This work is valuable for sure, and the content is stable, so I support to move it forward.

10 years! Respect!

Thanks,
Cheng

From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Tuesday, January 18, 2022 9:17 PM
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

Thanks,
Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 28 Jan 2022 13:52:39 +0530

Hi WG,

A gentle reminder - please get your feedback and comments by 1st Feb (Tuesday).

We are also missing the IPR declarations from Young, Oscar, and Victor.

Thanks!
Dhruv & Julien

---

From: Victor Lopez <[email-masked]>
Date: Mon, 31 Jan 2022 12:06:39 +0100

Hi,

I'm not aware of any additional IPR.

Victor

El vie, 28 ene 2022 a las 9:23, Dhruv Dhody (<[email-masked]>) escribió:

> > This email starts a 2-weeks working group last call for
> draft-ietf-pce-pcep-stateful-pce-gmpls-16 [1].  Please indicate your

---

From: Young Lee <[email-masked]>
Date: Mon, 31 Jan 2022 20:26:30 +0900

Hi,

I am not aware of any IPR that applies to this draft.

Thanks.
Young