Subject: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 22 Feb 2021 10:27:58 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(0) The fact that the procedures (§5) are presented before introducing the
messages/objects (§6-7) makes reading this document harder and more complex
than it has to be.  Consider changing the order or at least adding forward
references in §5.

(1) §5.2:  Is there a reason for the messages from rfc8231 to be in parenthesis?

(2) §5.4:

   The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the
   corresponding Path Setup Type being listed in the PATH-SETUP-TYPE-
   CAPABILITY TLV.  If it is present without the corresponding Path
   Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be
   ignored.

When is it ok to use the PCECC-CAPABILITY sub-TLV without the corresponding
PST?  If the result is that it will be ignored, then I don't understand why the
use of both is not required.

(3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check
mechanism and report the status back to the PCE"  Is this (checking and
reporting) specified somewhere?  Because you're using normative language,
please add a reference.

A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any OAM
mechanism to check the status of LSP in the Data plane and MAY further send its
status in a PCRpt message to the PCE".

(4) §5.5.3: s/central controller instructions...is done/central controller
instructions...are done

(5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the PCE
using the PCRpt message."   When is it ok for the PCC to not allocate and/or
report?  IOW, why are these actions only recommended and not required?  Note
that the very next paragraph requires the behavior.

(6) §7.3/§7.3.1:  In the out-label case, "it is mandatory to encode the
next-hop information".  Should this information point at a directly connected
IP address/interface, or can it point at a remote next-hop (which may be
resolved through a routing protocol)?  What if the expected conditions are not
met?

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 26 Feb 2021 10:10:34 +0000

Hi Alvaro,

Thank you for your comments! Please find the diff and the responses in line below. Thank you!

Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-pcep-extension-for-pce-controller-12&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-13.txt 

> -----Original Message-----
> From: Alvaro Retana via Datatracker [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2021 2:28 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked];
> [email-masked]; [email-masked]; Julien Meuric
> <[email-masked]>
> Subject: Alvaro Retana's No Objection on
> draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> messages/objects (§6-7) makes reading this document harder and more
> complex than it has to be.  Consider changing the order or at least adding
> forward references in §5.

Forward references are added.

> (1) §5.2:  Is there a reason for the messages from rfc8231 to be in

No, removed parenthesis!

> When is it ok to use the PCECC-CAPABILITY sub-TLV without the
> corresponding PST?  If the result is that it will be ignored, then I don't
> understand why the use of both is not required.

Changed to MUST NOT

> A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any
> OAM mechanism to check the status of LSP in the Data plane and MAY
> further send its status in a PCRpt message to the PCE".

Removed the normative language and added "The exact mechanism is out of scope of this document."!

> (4) §5.5.3: s/central controller instructions...is done/central controller

Updated

> report?  IOW, why are these actions only recommended and not required?
> Note that the very next paragraph requires the behavior.

Updated to "The PCC MUST try to allocate the Label and MUST report to the PCE via PCRpt or PCErr message."

> next-hop information".  Should this information point at a directly
> connected IP address/interface, or can it point at a remote next-hop (which
> may be resolved through a routing protocol)?  What if the expected
> conditions are not met?

I propose to add this text - 

"The next-hop information encoded in the Address TLVs needs to be a directly connected IP address/interface information. If the PCC is not able to resolve the next-hop information, it MUST reject the CCI and respond with a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error
Value = TBD18 ("Invalid next-hop information")."

Best regards, 
Shuping

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 26 Feb 2021 08:01:43 -0800

Shuping:

Hi!

The changes look good to me.

Thanks!

Alvaro.

On February 26, 2021 at 5:10:41 AM, Pengshuping (Peng Shuping) (
[email-masked]) wrote:

Thank you for your comments! Please find the diff and the responses in line
below. Thank you!