Subject: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-binding-label-sid-12: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 02 Feb 2022 20:29:07 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-binding-label-sid-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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/

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

In Section 1:

   This document specifies an extension to PCEP to manage of binding
   label/SID for both SR and non-SR paths.

I can't parse this sentence.

The SHOULD in Section 8 seems strange; it offers the implementer a choice of
not allocating the binding label/SID when the PCC has met the stated
conditions.  Why the choice?  If the SHOULD is meant to cover the "unable to
allocate" case, I would argue that the SHOULD is not necessary because there's
no interoperability choice being exercised, and would instead suggest:

   *  To request that the PCE allocate the binding label/SID, a PCC MUST
      set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt
      message.  The PCE will attempt to allocate it and respond to the PCC with
      PCUpd message including the allocated binding label/SID in the TE-
      PATH-BINDING TLV and P=1, D=1 in the LSP object.  If the PCE is
      unable to allocate, it MUST send a PCErr message with Error-Type =
      TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable
      to allocate a new binding label/SID").

Thank you for including Section 9.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 11 Feb 2022 03:06:40 +0000

Hi Murray,

Sorry for my delay and thank you for your comments. Please review the updated draft to see if it works.

Thank you again!
Cheng

Link:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13

-----Original Message-----
From: Murray Kucherawy via Datatracker [mailto:[email-masked]] 
Sent: Thursday, February 3, 2022 12:29 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Murray Kucherawy's No Objection on draft-ietf-pce-binding-label-sid-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.)

In Section 1:

The SHOULD in Section 8 seems strange; it offers the implementer a choice of not allocating the binding label/SID when the PCC has met the stated conditions.  Why the choice?  If the SHOULD is meant to cover the "unable to allocate" case, I would argue that the SHOULD is not necessary because there's no interoperability choice being exercised, and would instead suggest:

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 10 Feb 2022 21:14:40 -0800

Much better, thank you!

On Thu, Feb 10, 2022 at 7:06 PM Chengli (Cheng Li) <[email-masked]> wrote:

> Subject: Murray Kucherawy's No Objection on
> draft-ietf-pce-binding-label-sid-12: (with COMMENT)
>
> The SHOULD in Section 8 seems strange; it offers the implementer a choice
> of not allocating the binding label/SID when the PCC has met the stated
> conditions.  Why the choice?  If the SHOULD is meant to cover the "unable
> to allocate" case, I would argue that the SHOULD is not necessary because
> there's no interoperability choice being exercised, and would instead
> suggest:
>