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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

> 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/
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*