Subject: [Pce] Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 02:36:32 -0800

Martin Vigoureux has entered the following ballot position for
draft-ietf-pce-binding-label-sid-12: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

thank you for this document.
I have few points I'd like to discuss. Some might simply arise from my limited
knowledge/expertise in pce. Thank you for your understanding.

Section 5 is confusing to me. In my understanding, from a PCE perspective, an
LSP can be in three different situations: state synched with PCE, delegated to
PCE, or initiated by PCE. However, maybe not all the text applies to the three
cases. So, I wonder whether organizing this section along the lines of what can
be done and not done depending on the situations would help. At least, one key
aspect which is not clear to me is whether the binding value is an attribute
over which control (change/remove) is given to pce in case of delegation.

Also, I have the impression that there are "error" conditions which are not
described:

* how should PCC react (regardless of whether it already has a binding value)
if it receives from PCE an empty TLV with R=1?

* how should PCC react if it receives from PCE a TLV with a binding value
(different from the one it has) with R=1?

* how should PCC react if it receives from PCE a single TLV with a binding
value different from the one it has and with R=0?

The draft seems silent about how to deal with multiple identical
TE-PATH-BINDING TLVs. Use any? Throw an error?

The draft allows multiple TE-PATH-BINDING TLVs to be sent but in my view falls
short to describe the associated expectations. Ultimately the binding value is
something that will end-up programmed in the data-plane (or at least reserved
in the control plane) but maybe not all systems have the same capabilities in
these domains. Since PCE doesn't know these capabilities, I think, how should
be handled the situation where PCE requests N values but the node wants to -or
can- only use M (where M < N). Should an error be thrown back, or only M values
chosen and reported back? Is the selection of the M values function of a local
policy or should they be the M first or last, or any other specific rule? These
two paragraphs could be viewed as giving elements of response to these
questions but it's not fully clear:
   If a PCE requires a PCC to allocate a (or several) specific binding
   value(s), it may do so by sending a PCUpd or PCInitiate message
   containing a TE-PATH-BINDING TLV(s).  If the value(s) can be
   successfully allocated, the PCC reports the binding value(s) to the
   PCE.  If the PCC considers the binding value specified by the PCE
   invalid, it MUST send a PCErr message with Error-Type = TBD2
   ("Binding label/SID failure") and Error Value = TBD3 ("Invalid SID").

   If the binding value is valid, but the PCC is unable to allocate the
   binding value, it MUST send a PCErr message with Error-Type = TBD2
   ("Binding label/SID failure") and Error Value = TBD4 ("Unable to
   allocate the specified binding value").  Note that, in case of an
   error, the PCC rejects the PCUpd or PCInitiate message in its
   entirety and can include the offending TE-PATH-BINDING TLV in the
   PCEP-ERROR object.

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

   To implement the needed changes to PCEP, in this document, we
   introduce a new OPTIONAL TLV that a PCC can use in order to report
   the binding label/SID associated with a TE LSP, or a PCE to request a
   PCC to allocate a specific binding label/SID value.
It can also request PCC to allocate a value of its own choosing (with an empty
TLV), correct?

   As another way to use the extension specified in this document, to
   support the PCE-based central controller [RFC8283] operation where
   the PCE would take responsibility for managing some part of the MPLS
   label space for each of the routers that it controls, the PCE could
   directly make the binding label/SID allocation and inform the PCC.
   See Section 8 for details.
I am a bit sceptical about this and Section 8. This requires a mechanism which
is, as the draft says, specified nowhere.

   If a PCE recognizes the TLV but does not support the TLV, it MUST
   send a PCErr with Error-Type = 2 (Capability not supported).
Could you elaborate on what you mean by "does not support the TLV"? For example
the BT value? Also, could the following situation exist: a node with some LSPs
which can support a binding value and other which can't. How is PCC supposed to
react to a PCE request to allocate a binding value on an LSP from the latter
set?

   Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
   LSP object.  This signifies the presence of multiple binding SIDs for
   the given LSP.  In the case of multiple TE-PATH-BINDING TLVs, the
   existing instances of TE-PATH-BINDING TLVs MAY be included in the LSP
   object.
Not sure what that last sentence means or adds compared to the previous ones.

s/associted/associated/

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 1 Feb 2022 18:39:26 +0530

Hi Martin,

Considering Cheng would be busy celebrating the Lunar new year (and
the year of the tiger), let me take a stab at your comments.

> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/

Dhruv: Regarding the formating of section 5, it is common practice in
PCE documents to list text based on PCEP messages. The use of messages
is dependent on the "situation" i.e. PCRpt for passive; PCRpt & PCUpd
for active; PCRpt, PCUpd, & PCInitiate for PCE-initiated. Since the
same message can be used for all, it makes sense to list the
operations in terms of messages.

Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can
change/remove the binding using the PCUpd message. Note that as
described in RFC 8231, PCUpd is still a request from PCE to update and
the PCC can always reject it. The same holds true for binding value.

> (different from the one it has) with R=1?

Dhruv: Thanks for noticing these, I suggest adding -

If a PCC receives a PCUpd message with TE-PATH-BINDING TLV
where the R flag is set to 1, but either the binding value is missing
(empty TE-PATH-BINDING TLV) or the binding value is incorrect,
it MUST send a PCErr message with Error-Type = TBD2
("Binding label/SID failure") and Error Value = TBD6 ("Unable to
remove the binding value").

> value different from the one it has and with R=0?

Dhruv: The existing binding values which remain unchanged are optional
to be included. The text uses MAY for them. So in this case, the PCC
would try to allocate an additional binding value.

> TE-PATH-BINDING TLVs. Use any? Throw an error?

Dhruv: I guess use any. Do you suggest adding text for this? I am not
sure if I have seen such text in similar cases.

> chosen and reported back?

Dhruv: In case the PCE sends N TE-PATH-BINDING TLVs in the message and
the PCC cannot allocate them all, the whole message is rejected with
an error message.

> Is the selection of the M values function of a local

Dhruv: Since the whole message is rejected, we don't need to select
the 'M' values.
Is some text required here?

Dhruv: Yes! s/a specific binding/any or a specific binding/

> is, as the draft says, specified nowhere.

Dhruv: RFC 9050 says this -

   For the purpose of this document,
   it is assumed that the exclusive label range to be used by a PCE is
   known and set on both PCEP peers.  A future extension could add the
   capability to advertise this range via a possible PCEP extension as
   well (see [PCE-ID]).

Maybe authors could repeat this in section 8.

> react to a PCE request to allocate a binding value on an LSP from the latter

Dhruv: Yes BT value can play a role. In general, in PCEP there is a
distinction made between unknown and (known but not supported). The
reason for not being supported could be many (including the feature is
not enabled).

Regarding the situation you mention, PCC would send the error saying
unable to allocate using the existing error codes.

> Not sure what that last sentence means or adds compared to the previous ones.

Dhruv: The second sentence focus on the existing instances of
TE-PATH-BINDING which remains unchanged.

Thanks for a comprehensive review! Much appreciated.

Regards,
Dhruv

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 10 Feb 2022 13:44:13 +0000

Hi Martin and Dhruv, 

Sorry for my delay due to the Lunar tiger new year, and many thanks to Dhruv for your help!

I have updated the draft according to the recent discussion in the mailing list. 

Hope it can address your comments:

Respect,
Cheng

There is also an htmlized version available at:
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

-----邮件原件-----
发件人: Dhruv Dhody [mailto:[email-masked]] 
发送时间: 2022年2月1日 21:09
收件人: Martin Vigoureux <[email-masked]>
抄送: The IESG <[email-masked]>; [email-masked]; pce-chairs <[email-masked]>; [email-masked]; Julien Meuric <[email-masked]>
主题: Re: Martin Vigoureux's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

Hi Martin,

Considering Cheng would be busy celebrating the Lunar new year (and the year of the tiger), let me take a stab at your comments.

On Tue, Feb 1, 2022 at 4:06 PM Martin Vigoureux via Datatracker <[email-masked]> wrote:
> 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/
> I have few points I'd like to discuss. Some might simply arise from my 
> limited knowledge/expertise in pce. Thank you for your understanding.
>
> Section 5 is confusing to me. In my understanding, from a PCE 
> perspective, an LSP can be in three different situations: state 
> synched with PCE, delegated to PCE, or initiated by PCE. However, 
> maybe not all the text applies to the three cases. So, I wonder 
> whether organizing this section along the lines of what can be done 
> and not done depending on the situations would help. At least, one key 
> aspect which is not clear to me is whether the binding value is an attribute over which control (change/remove) is given to pce in case of delegation.
>

Dhruv: Regarding the formating of section 5, it is common practice in PCE documents to list text based on PCEP messages. The use of messages is dependent on the "situation" i.e. PCRpt for passive; PCRpt & PCUpd for active; PCRpt, PCUpd, & PCInitiate for PCE-initiated. Since the same message can be used for all, it makes sense to list the operations in terms of messages.

Regarding delegation - Yes, if the LSP is delegated to PCE, PCE can change/remove the binding using the PCUpd message. Note that as described in RFC 8231, PCUpd is still a request from PCE to update and the PCC can always reject it. The same holds true for binding value.

> * how should PCC react (regardless of whether it already has a binding 
> value) if it receives from PCE an empty TLV with R=1?
>
> * how should PCC react if it receives from PCE a TLV with a binding 
> value (different from the one it has) with R=1?
>

If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where the R flag is set to 1, but either the binding value is missing (empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD6 ("Unable to remove the binding value").

> * how should PCC react if it receives from PCE a single TLV with a 
> binding value different from the one it has and with R=0?
>

Dhruv: The existing binding values which remain unchanged are optional to be included. The text uses MAY for them. So in this case, the PCC would try to allocate an additional binding value.

> TE-PATH-BINDING TLVs. Use any? Throw an error?

Dhruv: I guess use any. Do you suggest adding text for this? I am not sure if I have seen such text in similar cases.

> The draft allows multiple TE-PATH-BINDING TLVs to be sent but in my 
> view falls short to describe the associated expectations. Ultimately 
> the binding value is something that will end-up programmed in the 
> data-plane (or at least reserved in the control plane) but maybe not 
> all systems have the same capabilities in these domains. Since PCE 
> doesn't know these capabilities, I think, how should be handled the 
> situation where PCE requests N values but the node wants to -or
> can- only use M (where M < N). Should an error be thrown back, or only 
> M values chosen and reported back?

Dhruv: In case the PCE sends N TE-PATH-BINDING TLVs in the message and the PCC cannot allocate them all, the whole message is rejected with an error message.

> Is the selection of the M values function of a local policy or should 
> they be the M first or last, or any other specific rule? These two 
> paragraphs could be viewed as giving elements of response to these 

Dhruv: Since the whole message is rejected, we don't need to select the 'M' values.
Is some text required here?

> It can also request PCC to allocate a value of its own choosing (with 
> an empty TLV), correct?
>

> I am a bit sceptical about this and Section 8. This requires a 
> mechanism which is, as the draft says, specified nowhere.
>

> Could you elaborate on what you mean by "does not support the TLV"? 
> For example the BT value? Also, could the following situation exist: a 
> node with some LSPs which can support a binding value and other which 
> can't. How is PCC supposed to react to a PCE request to allocate a 
> binding value on an LSP from the latter set?
>

Dhruv: Yes BT value can play a role. In general, in PCEP there is a distinction made between unknown and (known but not supported). The reason for not being supported could be many (including the feature is not enabled).

Regarding the situation you mention, PCC would send the error saying unable to allocate using the existing error codes.

> Not sure what that last sentence means or adds compared to the previous ones.

Dhruv: The second sentence focus on the existing instances of TE-PATH-BINDING which remains unchanged.

Regards,
Dhruv