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

[Adrian Farrel <[e-mail]>]

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 <[e-mail]> On Behalf Of Dhruv Dhody
Sent: 18 January 2022 13:17
To: [e-mail]
Cc: [e-mail]; pce-chairs <[e-mail]>
Subject: [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. 

 

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/