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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 11:43:38 -0800

Benjamin Kaduk 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:
----------------------------------------------------------------------

(1) I don't think we're currently entirely accurate in our depection of
the properties of BT=3 TE-PATH-BINDING TLVs.  In particular, in
Section 5 we write:

   For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
   SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
   by setting the BT (Binding Type) to 3.  This enables the sender to
   have control of the SRv6 Endpoint Behavior and SID Structure.  A
   sender MAY choose to set the BT to 2, in which case the receiving
   implementation chooses how to interpret the SRv6 Endpoint Behavior
   and SID Structure according to local policy.

But this TLV can be sent in several different circumstances -- when the
PCC has allocated the BSID and is reporting it to the PCE, when the PCE is
requesting the PCC to allocate a specific value, when the PCE has already
allocated a specific value from a range controlled by the PCE, and when
the PCE is requesting the PCC to allocate some value of its own choosing
(at least).  I think that only in the "PCE is requesting a specific value"
and "PCE has already allocated a specific value" cases do these claimed
properties hold -- if the PCC is allocating the value then the
interpretation of its internal structure is local to the PCC and the PCE
does not need to know how to interpret the structure in order for the path
to function.

This also brings up a related topic (and gives me unease about
specifically recommending use of BT=3 as the quoted text does), which may
be familiar to those who participated in the processing of
draft-ietf-lsr-isis-srv6-extensions.

In particular, the relationship of SRv6 SIDs to the IPv6 addressing
architecture (RFC 4291) was quite controversial during the processing of
what since became RFC 8986.  I was able to reconcile the two at the time
by virtue of noting that the substructure of the SID can be considered to
be logically local to the node advertising the SID and therefore not an
observable part of the protocol.  In that sense, the wire-visible use and
processing of SIDs remains that of normal IPv6 addresses.  However,
introducing a TLV that specifically carries the structure of the SID
causes that reasoning to no longer apply, and seemingly re-opens the
question of whether the SID substructure is consistent with the IPv6
addressing architecture.  While this document does seem to present
somewhat more of a concrete use case for this mechanism than
draft-ietf-lsr-isis-srv6-extensions did (i.e., if the PCE is requesting or
allocating a specific value as an agent for the PCC, then the PCC needs to
know the internal structure somehow), the current framing of the mechanism
in the document leaves me uncomfortable, and once my discuss point is
resolved, I intend to change my position to Abstain.  It is possible
(though I make no commitment to future action) that if we changed the
description of the mechanism to be one where the PCC and PCE are jointly
managing the allocation of IPv6 addresses belonging to the PCC and
collaborate to manage the internal structure of the allocated values,
without exposing that internal structure to external entities in the
network or having the internal structure used in data-plane forwarding
paths, my discomfort would be reduced to a level that I could ballot No
Objection.  (I also wouldn't object to making the registry procedures
something less stringent than Standards Action and allocating the
codepoint as currently specified via some mechanism that does not involve
IETF Consensus, which would avoid reopening the controversy in the IETF
about this topic.)

(2) We are allocating a bit for the 'P' flag in the LSP Object flags, but
I only see specification of its behavior/semantics for the case when a
TE-PATH-BINDING TLV is present in the LSP object.  Section 8 says:

   *  P (PCE-allocated binding label/SID): If the bit is set to 1, it
      indicates that the PCC requests PCE to make allocations for this
      LSP.  The TE-PATH-BINDING TLV in the LSP object identifies that
      the allocation is for a binding label/SID.  [...]

The first sentence seems to indicate that the P flag is useful outside of
the scope of BSID allocation, with the general semantics of "the PCE
requests PCE to make allocations for this LSP".  This seems to be rather
under-specified for how it applies to cases without the TE-PATH-BINDING
TLV (what exactly is to be allocated by the PCE?) -- is the P flag useful
in such other cases?  If so, where are the usage details (going to be)
specified?  We do limit the use of P=1 to cases where PCECC has been
negotiated per RFC 9050, but I don't see a limitation of its use to cases
where TE-PATH-BINDING is present.  (And if there was such a limitation,
why is it a flag in the LSP Object rather than in the TLV itself?)

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

Abstract

   In order to provide greater scalability, network confidentiality, and
   service independence, Segment Routing (SR) utilizes a Binding Segment
   Identifier (BSID).  [...]

I'd consider mentioning RFC 8402 in some manner here, e.g., "as described
in RFC 8402", to emphasize that BSID is a preexisting concept and not the
new innovation of this document.

Section 1.1

I spent a while being rather confused about the example in Figure 1.  The
prose helps with some of my confusion, but there may still be some gaps
that could be improved.  In particular (per the prose), the PCE is
computing SR-TE paths in the IP/MPLS WAN (and so the PCC at gateway node 1
is the headend of that path, as expected).  But the PCE in the figure is
not shown interacting with the IP/MPLS WAN at all, other than Gateway
Node-1.  On the contrary, the PCE is explictly shown interacting with the
access node in front of the MPLS DC network, where (per the prose) paths
are managed via BGP prefix SID advertisements, without PCEP at all!  The
prose says of this interaction only that "the PCE passes the SID stack
{Y, X} where Y is the prefix SID of the gateway node-1 to the access
node", but not what protocol or mechanism is used to effectuate that
passing.  Is that supposed to be part of the BCP prefix SID advertisement
otherwise used in the MPLS DC network?  Or perhaps some other interaction
where the PCE is functioning as a central controller?  I suggest
clarifying in both the figure and the prose.

Section 4

   Section 12.1.1 defines the IANA registry used to maintain all these
   binding types as well as any future ones.  Note that multiple TE-
   PATH-BINDING TLVs with different Binding Types MAY be present for the
   same LSP.

It seems that we have defined a couple pairs of binding types that contain
redundant information, e.g., the SRv6 SID of BT=2 might be expected to be
the same SRv6 SID contained in BT=3.  If such semantically "similar"
binding types appear together in the same LSP, is there any requirement
for them to be internally consistent (when not indicating removal, at
least)?  Is a recipient allowed/required to verify such consistency?  What
is the error handling behavior if inconsistency is detected?
If the intent is that a node might usefully desire to assign multiple
distinct BSID values of the same type that correspond to the same path, we
probably want to say so explicitly, including what a potential motivation
would be.  (Is there perhaps some privacy benefit to be had by avoiding
certain types of correlation?  I do not really see one, based on my
limited knowledge of the ways in which these paths will be distributed,
but could be missing something.)

Section 4.1

   *  Endpoint Behavior: 2 octets.  The Endpoint Behavior code point for
      this SRv6 SID as per the IANA subregistry called "SRv6 Endpoint
      Behaviors", created by [RFC8986].  When the field is set with the
      value 0, the endpoint behavior is considered unknown.

If the primary purpose of the Binding SID is bind to a policy, which is
then instantiated as (usually) a list of SIDs, it seems like we might need
to say a bit more about why there is additionally a single Endpoint
Behavior value associated with the BSID.  One might surmise that there is
a combined action of imposing the new list of SIDs and also having an
endpoint behavior, e.g., to send the outgoing packet over a tunnel or
cross-connect after having imposed the new SID list, but it's a fairly
weak inference and could stand to be made explicit.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    LB Length  |    LN Length  | Fun. Length   |  Arg. Length  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should we say something (whether here or in the security considerations)
about needing to check that the sum of these lengths is less than or equal
to 128?

Section 5

   The binding value is allocated by the PCC and reported to a PCE via a
   PCRpt message.  If a PCE does not recognize the TE-PATH-BINDING TLV,

Should we forward-reference §8 as an exception to this, where the PCE is
actually doing the allocation?

   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.  [...]
[...]
   R flag set to 1.  If a PCC wishes to modify a previously reported
   binding, it MUST withdraw the former binding value (with R flag set
   in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING
   TLV containing the new binding value.  Note that other instances of
   TE-PATH-BINDING TLVs that are unchanged MAY also be included.

This implies but does not state explicitly that if the unchanged instances
are not included, they still remain associated with the LSP in the state
on the PCE.  Should it be stated explicitly?

   of the TLV to 4).  A PCE can also request a PCC to allocate a binding
   value at the time of initiation by sending a PCInitiate message with
   an empty TE-PATH-BINDING TLV.  [...]

I wonder if "empty" is really the best term, as in other contexts one
might assume that an "empty" TLV has length zero, rather than the length
four that we mean here (with just the "binding value" field being empty).

                                  Only one such instance of empty TE-
   PATH-BINDING TLV SHOULD be included in the LSP object and others
   ignored on receipt.  [...]

Is this one instance total or one instance per BT?

Separately, is a TLV with empty binding value but the R flag set invalid?

Section 8

   A new P flag in the LSP object [RFC8231] is introduced to indicate
   that the allocation needs to be made by the PCE:

Is there a mnemonic for why this flag is named 'P' vs. some other letter?

      the PCC.  Further, a PCE MUST set this bit to 0 and include a TE-
      PATH-BINDING TLV in the LSP object if it wishes to indicate that
      the binding label/SID should be allocated by the PCC as described
      in Section 5.

In Section 5 we described how the use of a zero-length binding value
indicates that the PCE requests for the PCC to allocate the BSID value.
Why do we need two ways to do the same thing?  (Well, presumably "there's
nothing else to put in the field", at least for this flag bit, but we
could at least frame the discussion in the document more like "this one is
authoritative, but when we are doing PCC allocation [as indicated by the
authoritative setting], we have to also set this field accordingly in
order to remain self-consistent" or be careful to always mention both
together as a single unit.  I do note the later text that P=1 is only
valid when use of the RFC 9050 procedures has been negotiated.)

   It is assumed that the label range to be used by a PCE is known and
   set on both PCEP peers.  The exact mechanism is out of the scope of
   [RFC9050] or this document.  [...]

I note that RFC 9050 referenced draft-li-pce-controlled-id-space as a
potential future expansion that could allow advertising the range in-band
via a PCEP extension, but that draft seems to have expired in August 2021.
So maybe it's not something we should mention again here...

Section 10

   The security considerations described in [RFC5440], [RFC8231],
   [RFC8281] and [RFC8664] are applicable to this specification.  No

I think we need to add RFC 9050 to this list; the things that can go wrong
with PCE allocation definitely apply here (per §8).

   As described in [RFC8664], SR allows a network controller to
   instantiate and control paths in the network.  A rogue PCE can
   manipulate binding SID allocations to move traffic around for some
   other LSP that uses BSID in its SR-ERO.  Note that path {A, B, BSID}
   can be misdirected just by assigning the BSID value to a different
   LSP making it a lot easier to misdirect traffic (and harder to
   detect).

This could probably be made more crisp.  I propose
NEW:
% As described in [RFC9402] and [RFC8664], SR intrinsically involves an
% entity (whether head-end or a central network controller) controlling
% and instantiating paths in the network without the involvement of
% (other) nodes along those paths.  Binding SIDs are in effect shorthand
% aliases for longer path representations, and the alias expansion is in
% principle known only by the node that acts on it.  In this document,
% the expansion of the alias is shared between PCC and PCE, and rogue
% actions by either PCC or PCE could result in shifting or misdirecting
% traffic in ways that are hard for other nodes to detect.  In
% particular, when a PCE propagates paths of the form {A, B, BSID} to
% other entities, the BSID values are opaque, and a rogue PCE can
% substitute a BSID from a different LSP in such paths to move traffic
% without the recipient of the path knowing the ultimate destination.

   Note that in case of BT as 3, the manipulation of SID structure could
   be exploited by falsifying the various length values.

Similarly, I propose
NEW:
% The case of BT=3 provides additional opportunities for malfeasance, as
% it purports to convey information about internal SRv6 SID structure.
% There is no mechanism defined to validate this internal structure
% information, and mischaracterizing the division of bits into locator
% block, locator node, function, and argument can result in different
% interpretation of the bits by PCC and PCE.  Most notably, shifting bits
% into or out of the "argument" is a direct vector for affecting
% processing, but other attacks are also possible.

   and PCCs belonging to the same administrative authority, using
   Transport Layer Security (TLS) [RFC8253], as per the recommendations
   and best current practices in BCP195 [RFC7525] (unless explicitly set
   aside in [RFC8253]).

For information, the UTA WG is currently working on a "bis" of RFC 7525.
But I do not think you should make any change to this document at this
time; I just mention it for general awareness.

Section 12.2

Just to confirm my understanding: there are no unallocated flags left in
the LSP Object flag field?  Would we then be forced to either define a new
object or use sentinel (zero-length) TLVs for things that would otherwise
be treated as flags?
In particular (and related to discuss point (2)), why is a flag in the
TE-PATH-BINDING TLV flag field not suitable and a flag in the toplevel LSP
Object necessary?

NITS

Section 1

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

I think s/manage of binding/manage the binding of/.

Section 1.2

   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.  This TLV is
   intended for TE LSPs established using RSVP-TE, SR, or any other
   future method.  [...]

This sentence reads oddly to me, in that there's some kind of "type
mismatch" between RSVP-TE and SR.  That is, RSVP-TE is a protocol that I
run and it "computes" paths for me.  But I see Segment Routing as a mode
of operation that lets me use a path I already know, without maintaining
per-path state on each node in the path.  It doesn't compute the path for
me, rather, it's something I can do once I know the desired path from some
out-of-band mechanism.  So while it may be okay to say that I have a TE
LSP "established using SR" in isolation (in that the headend just asserts
the path and thereby "establishes" an LSP), to put it right next to having
a TE LSP "established using RSVP-TE" seems to lack a certain parallelism
of structure that I'm expecting.

                   Also, in the case of SR-TE LSPs, the TLV can carry a
   binding label (for SR-TE path with MPLS data-plane) or a binding IPv6
   SID (e.g., IPv6 address for SR-TE paths with IPv6 data-plane).

I am not sure what role the word "also" is intended to play here, and
think that the paragraph would make sense if it was removed.

Section 4.1

Please make the SRv6 Binding SID field in Figure 4 taller in some fashion
to match its 16-byte nature.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 2 Feb 2022 13:54:46 +0530

Hi Ben,

Thanks for your comprehensive review and comments.

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

Dhruv: The idea of PCC reporting the structure could be useful if we
want PCE to do some sanity checks over the SID allocation scheme. But
the main motivation was to have a single recommended format for SRv6
(note that it is not MUST in any case). I see the following way
forward:

A: RECOMMENDED used only for PCE allocated value and use MAY for PCC
B: Keep the current wording but add a rationale for how PCE could use
the reported structure
C: Do nothing

What makes sense to you? Authors/WG please chime in!

> IETF Consensus, which would avoid reopening the controversy in the IETF

Dhruv: The PCE WG is simply following the SID structure as described
in RFC8986 and draft-ietf-lsr-isis-srv6-extensions (in RFC Editor
queue). The SID structure is communicated between the PCEP peers only
and not exposed externally to transit nodes, nor is this used in the
forwarding plane. That said, the WG could benefit from guidance from
the RTG ADs on how to proceed.

> why is it a flag in the LSP Object rather than in the TLV itself?)

Dhruv: The P flag is also used in Path Segment
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment#section-4.2).
We should add this text to make the presence of other cases clear to
the reader -

Note that the P flag could be used for other types of allocations
(such as path segments [I-D.ietf-pce-sr-path-segment]) in future.

Dhruv: I see the confusion. I would suggest authors simplify this as a
case of an inter-domain SR-TE path where the PCE is responsible for
both domains to highlight the use of PCEP.

> but could be missing something.)

Dhruv: Maybe add a new error for this -

Note that some binding types have similar information but different binding
value formats. For example, BT=(2 or 3) is used for the SRv6 SID and
BT=(0 or 1) is used for the MPLS Label. In case a PCEP speaker
receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or
MPLS Label but different BT values, it MUST send a PCErr message with
Error-Type = TBD2 ("Binding label/SID failure") and Error-Value =
TBD7 ("Inconsistent binding types").

and add something like this -

Note that multiple TE-PATH-BINDING TLVs with same or different Binding
Types MAY be present for the same LSP. A PCEP speaker could allocate
multiple TE-PATH-BINDING TLVs (of the same BT), and use different binding
values in different domains or use-cases based on a local policy.

> weak inference and could stand to be made explicit.

Dhruv: I was under the impression that this would be one of
binding-related endpoint behavior like End.B6.Encaps,
End.B6.Encaps.Red etc. So maybe we need to add an error check for
inconsistency. See below.

Dhruv: Good suggestion. Authors could add something on the lines of -

The total of the locator block, locator node, function, and argument
lengths MUST be lower or equal to 128 bits.  If this condition is not
met, the corresponding TE-PATH-BINDING TLV MUST be considered
as an error. Also, if the Endpoint Behavior is found to be unknown or
inconsistent, it is considered an error.  A PCErr message with
Error-Type = 10 ("Reception of an invalid object") and Error-Value =
37 ("Invalid SRv6 SID Structure") MUST be sent.

> on the PCE.  Should it be stated explicitly?

Dhruv: Good suggestion.

> four that we mean here (with just the "binding value" field being empty).

Dhruv: Maybe add this text early on -

In this document, the TE-PATH-BINDING TLV is considered to be empty if
no Binding Value is present. Note that the length of the TLV would be 4 in
such a case.

> Is this one instance total or one instance per BT?

Dhruv: per BT makes sense!

> Separately, is a TLV with empty binding value but the R flag set invalid?

Dhruv: This error needs to be added as per Martin's comment.

> Is there a mnemonic for why this flag is named 'P' vs. some other letter?

Dhruv: It was first introduced in a different document but moved to
this draft during the WG discussion. The name remained the same to
avoid confusion in the WG.

> valid when use of the RFC 9050 procedures has been negotiated.)

Dhruv: Are you suggesting something like this -

Further, if the binding label/SID is allocated by
the PCC, the PCE MUST set this bit to 0 and follow the procedure
described in Section 5.

> So maybe it's not something we should mention again here...

Dhruv: The document is in the WG adoption queue, must have expired
waiting in that queue :)

> % processing, but other attacks are also possible.

Dhruv: Thanks for the suggested text. s/RFC9402/RFC8402/ -- otherwise LGTM.

> TE-PATH-BINDING TLV flag field not suitable and a flag in the toplevel LSP

Dhruv: WG has adopted LSP-EXTENDED-FLAG TLV
[https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/]
as a way to extend flags for the LSP object.

> of structure that I'm expecting.

Dhruv: Maybe just saying SR-TE instead of SR would be better.

> to match its 16-byte nature.

Thanks for these suggestions. I request the authors to update accordingly.

Thanks!
Dhruv

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 2 Feb 2022 16:18:44 -0800

Hi Dhruv,

> What makes sense to you? Authors/WG please chime in!

I think both A or B could be workable, depending on the specifics; I'd
prefer to avoid C, obviously :)
Of those three I'd probably pick A myself, but the authors+WG are better
place to make an informed decision.

> queue). The SID structure is communicated between the PCEP peers only

I balloted on both of those documents, yes :)

> the RTG ADs on how to proceed.

Right, I think the actual mechanics of what's going on here are not
particularly objectionable.  As I understand it, it's basically always
going to be that the PCC has delegated some responsibility for allocating
its IPv6 addresses to the PCE or that the PCC and PCE are jointly
collaborating to manage the allocation of IPv6 addresses within a prefix
that is controlled by the entity that manages both PCC and PCE.  In effect,
the use of PCEP is just an internal matter to the IPv6 address allocation
strategy of the node that owns the prefix in question, which is
unobjectionable.  The core of my concern is that we're normalizing the use
of a protocol element to convey this structure without a disclaimer of why
it's "okay" -- someone reading this document without the extra context I
allude to above might take away an impression that it's normal to convey
such information about IPv6 address sub-structure in a protocol and try to
design it into something else, which would/could be problematic.

> (such as path segments [I-D.ietf-pce-sr-path-segment]) in future.

That would be a big help.  I think we should probably also say that it
shouldn't be used (set to 1) without some form of specification for the
semantics, and note that as a practical matter (or maybe even as a
normative requirement) there needs to be some sort of negotiation to "opt
in" to the use of the new flag/functionality for each specific case.  E.g.,
use of the TE-PATH-BINDING TLV would indicate that an implementation
supports use/comprehension of P=1 for in the context of BSID allocation,
and use of the PATH-SEGMENT TLV from draft-ietf-pce-sr-path-segment would
indicate use/comprehension of P=1 in that context, but a new document
should not assign semantics to P=1 without some indication of the scope of
those semantics and a mechanism for both parties to agree that the new
semantics are in use.

> both domains to highlight the use of PCEP.

Sure, that is an easy way to resolve the confusion (there are no doubt
others).

> values in different domains or use-cases based on a local policy.

These both sound good to me.

> inconsistency. See below.

More text would be quite welcome; I was pretty unconfident that I
understood what this was to be used for from reading the current text.

> 37 ("Invalid SRv6 SID Structure") MUST be sent.

Sounds good.

> no Binding Value is present. Note that the length of the TLV would be 4 in

Ok.

> Dhruv: per BT makes sense!

I thought so too, so it was weird to see the text say otherwise!

> Dhruv: This error needs to be added as per Martin's comment.

Oops, I failed to note Martin's comment in time.

> avoid confusion in the WG.

Okay.  Probably best to not say anything about the naming in this document,
then.

> the PCC, the PCE MUST set this bit to 0 and follow the procedure

I don't think that's quite the direction I was envisioning, but it seems
like a good way to react to my comment.

> > with PCE allocation definitely apply here (per §8).

Please don't forget this part :)

> Dhruv: Thanks for the suggested text. s/RFC9402/RFC8402/ -- otherwise LGTM.

Yes, 8402, sorry for the typo.

> as a way to extend flags for the LSP object.

Ah, thanks for the pointer.

> Dhruv: Maybe just saying SR-TE instead of SR would be better.

That would help a lot.  There might be room for further improvement, but it
would not stick out at me so much.

Thanks,

Ben

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 14 Feb 2022 06:51:57 +0000

Hi Benjamin,

Thank you for your comments and sorry for my delay. We have updated the draft based on the discussion between you and Dhruv.

Regarding the TE-PATH-BINDING TLVs, we think it will be better to keep it and add a rationale for how PCE could use. That is Option B in the discussion.
We have added the following text to describe the motivation of needing this TLV.

   The SRv6 SID Structure could be used by the PCE for ease of
   operations and monitoring.  For example, this information could be
   used for validation of SRv6 SIDs being instantiated in the network
   and checked for conformance to the SRv6 SID allocation scheme chosen
   by the operator as described in Section 3.2 of [RFC8986].  In the
   future, PCE could also be used for verification and the automation
   for securing the SRv6 domain by provisioning filtering rules at SR
   domain boundaries as described in Section 5 of [RFC8754].  The
   details of these potential applications are outside the scope of this
   document.

Is it OK for you?

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-binding-label-sid-13.txt

Thank you again for the help!
Cheng

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Thursday, February 3, 2022 8:19 AM
To: Dhruv Dhody <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; pce-chairs <[email-masked]>; [email-masked]; Julien Meuric <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-pce-binding-label-sid-12: (with DISCUSS and COMMENT)

Hi Dhruv,

On Wed, Feb 02, 2022 at 01:54:46PM +0530, Dhruv Dhody wrote:
> > (1) I don't think we're currently entirely accurate in our depection 
> > of the properties of BT=3 TE-PATH-BINDING TLVs.  In particular, in 
> > Section 5 we write:
> >
> > But this TLV can be sent in several different circumstances -- when 
> > the PCC has allocated the BSID and is reporting it to the PCE, when 
> > the PCE is requesting the PCC to allocate a specific value, when the 
> > PCE has already allocated a specific value from a range controlled 
> > by the PCE, and when the PCE is requesting the PCC to allocate some 
> > value of its own choosing (at least).  I think that only in the "PCE is requesting a specific value"
> > and "PCE has already allocated a specific value" cases do these 
> > claimed properties hold -- if the PCC is allocating the value then 
> > the interpretation of its internal structure is local to the PCC and 
> > the PCE does not need to know how to interpret the structure in 
> > order for the path to function.
> >
> 

I think both A or B could be workable, depending on the specifics; I'd prefer to avoid C, obviously :) Of those three I'd probably pick A myself, but the authors+WG are better place to make an informed decision.

> > specifically recommending use of BT=3 as the quoted text does), 
> > which may be familiar to those who participated in the processing of 
> > architecture (RFC 4291) was quite controversial during the 
> > processing of what since became RFC 8986.  I was able to reconcile 
> > the two at the time by virtue of noting that the substructure of the 
> > SID can be considered to be logically local to the node advertising 
> > the SID and therefore not an observable part of the protocol.  In 
> > that sense, the wire-visible use and processing of SIDs remains that 
> > of normal IPv6 addresses.  However, introducing a TLV that 
> > specifically carries the structure of the SID causes that reasoning 
> > to no longer apply, and seemingly re-opens the question of whether 
> > the SID substructure is consistent with the IPv6 addressing 
> > architecture.  While this document does seem to present somewhat 
> > more of a concrete use case for this mechanism than 
> > draft-ietf-lsr-isis-srv6-extensions did (i.e., if the PCE is 
> > requesting or allocating a specific value as an agent for the PCC, 
> > then the PCC needs to know the internal structure somehow), the 
> > current framing of the mechanism in the document leaves me 
> > uncomfortable, and once my discuss point is resolved, I intend to 
> > change my position to Abstain.  It is possible (though I make no 
> > commitment to future action) that if we changed the description of 
> > the mechanism to be one where the PCC and PCE are jointly managing 
> > the allocation of IPv6 addresses belonging to the PCC and 
> > collaborate to manage the internal structure of the allocated 
> > values, without exposing that internal structure to external 
> > entities in the network or having the internal structure used in 
> > data-plane forwarding paths, my discomfort would be reduced to a 
> > level that I could ballot No Objection.  (I also wouldn't object to 
> > making the registry procedures something less stringent than 
> > Standards Action and allocating the codepoint as currently specified 
> > via some mechanism that does not involve IETF Consensus, which would 
> > avoid reopening the controversy in the IETF about this topic.)
> >
> 

> the RTG ADs on how to proceed.

Right, I think the actual mechanics of what's going on here are not particularly objectionable.  As I understand it, it's basically always going to be that the PCC has delegated some responsibility for allocating its IPv6 addresses to the PCE or that the PCC and PCE are jointly collaborating to manage the allocation of IPv6 addresses within a prefix that is controlled by the entity that manages both PCC and PCE.  In effect, the use of PCEP is just an internal matter to the IPv6 address allocation strategy of the node that owns the prefix in question, which is unobjectionable.  The core of my concern is that we're normalizing the use of a protocol element to convey this structure without a disclaimer of why it's "okay" -- someone reading this document without the extra context I allude to above might take away an impression that it's normal to convey such information about IPv6 address sub-structure in a protocol and try to design it into something else, which would/could be problematic.

> 
> > (2) We are allocating a bit for the 'P' flag in the LSP Object 
> > flags, but I only see specification of its behavior/semantics for 
> > the case when a TE-PATH-BINDING TLV is present in the LSP object.  Section 8 says:
> >
> > The first sentence seems to indicate that the P flag is useful 
> > outside of the scope of BSID allocation, with the general semantics 
> > of "the PCE requests PCE to make allocations for this LSP".  This 
> > seems to be rather under-specified for how it applies to cases 
> > without the TE-PATH-BINDING TLV (what exactly is to be allocated by 
> > the PCE?) -- is the P flag useful in such other cases?  If so, where 
> > are the usage details (going to be) specified?  We do limit the use 
> > of P=1 to cases where PCECC has been negotiated per RFC 9050, but I 
> > don't see a limitation of its use to cases where TE-PATH-BINDING is 
> > present.  (And if there was such a limitation, why is it a flag in 
> > the LSP Object rather than in the TLV itself?)
> >
> >
> 

That would be a big help.  I think we should probably also say that it shouldn't be used (set to 1) without some form of specification for the semantics, and note that as a practical matter (or maybe even as a normative requirement) there needs to be some sort of negotiation to "opt in" to the use of the new flag/functionality for each specific case.  E.g., use of the TE-PATH-BINDING TLV would indicate that an implementation supports use/comprehension of P=1 for in the context of BSID allocation, and use of the PATH-SEGMENT TLV from draft-ietf-pce-sr-path-segment would indicate use/comprehension of P=1 in that context, but a new document should not assign semantics to P=1 without some indication of the scope of those semantics and a mechanism for both parties to agree that the new semantics are in use.

> > I'd consider mentioning RFC 8402 in some manner here, e.g., "as 
> > described in RFC 8402", to emphasize that BSID is a preexisting 
> > concept and not the new innovation of this document.
> >
> > Section 1.1
> >
> > I spent a while being rather confused about the example in Figure 1.  
> > The prose helps with some of my confusion, but there may still be 
> > some gaps that could be improved.  In particular (per the prose), 
> > the PCE is computing SR-TE paths in the IP/MPLS WAN (and so the PCC 
> > at gateway node 1 is the headend of that path, as expected).  But 
> > the PCE in the figure is not shown interacting with the IP/MPLS WAN 
> > at all, other than Gateway Node-1.  On the contrary, the PCE is 
> > explictly shown interacting with the access node in front of the 
> > MPLS DC network, where (per the prose) paths are managed via BGP 
> > prefix SID advertisements, without PCEP at all!  The prose says of 
> > this interaction only that "the PCE passes the SID stack {Y, X} 
> > where Y is the prefix SID of the gateway node-1 to the access node", 
> > but not what protocol or mechanism is used to effectuate that 
> > passing.  Is that supposed to be part of the BCP prefix SID 
> > advertisement otherwise used in the MPLS DC network?  Or perhaps 
> > some other interaction where the PCE is functioning as a central controller?  I suggest clarifying in both the figure and the prose.
> >
> 

Sure, that is an easy way to resolve the confusion (there are no doubt others).

> > It seems that we have defined a couple pairs of binding types that 
> > contain redundant information, e.g., the SRv6 SID of BT=2 might be 
> > expected to be the same SRv6 SID contained in BT=3.  If such semantically "similar"
> > binding types appear together in the same LSP, is there any 
> > requirement for them to be internally consistent (when not 
> > indicating removal, at least)?  Is a recipient allowed/required to 
> > verify such consistency?  What is the error handling behavior if inconsistency is detected?
> > If the intent is that a node might usefully desire to assign 
> > multiple distinct BSID values of the same type that correspond to 
> > the same path, we probably want to say so explicitly, including what 
> > a potential motivation would be.  (Is there perhaps some privacy 
> > benefit to be had by avoiding certain types of correlation?  I do 
> > not really see one, based on my limited knowledge of the ways in 
> > which these paths will be distributed, but could be missing 
> > something.)
> >
> 
> Note that some binding types have similar information but different 
> binding value formats. For example, BT=(2 or 3) is used for the SRv6 
> SID and
> receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS 
> Label but different BT values, it MUST send a PCErr message with 
> multiple TE-PATH-BINDING TLVs (of the same BT), and use different 
> binding values in different domains or use-cases based on a local policy.

> > If the primary purpose of the Binding SID is bind to a policy, which 
> > is then instantiated as (usually) a list of SIDs, it seems like we 
> > might need to say a bit more about why there is additionally a 
> > single Endpoint Behavior value associated with the BSID.  One might 
> > surmise that there is a combined action of imposing the new list of 
> > SIDs and also having an endpoint behavior, e.g., to send the 
> > outgoing packet over a tunnel or cross-connect after having imposed 
> > the new SID list, but it's a fairly weak inference and could stand to be made explicit.
> >
> 

More text would be quite welcome; I was pretty unconfident that I understood what this was to be used for from reading the current text.

> > Should we say something (whether here or in the security 
> > considerations) about needing to check that the sum of these lengths 
> > is less than or equal to 128?
> >
> 
> met, the corresponding TE-PATH-BINDING TLV MUST be considered as an 
> error. Also, if the Endpoint Behavior is found to be unknown or 

Sounds good.

> > Should we forward-reference §8 as an exception to this, where the 
> > PCE is actually doing the allocation?
> >
> > This implies but does not state explicitly that if the unchanged 
> > instances are not included, they still remain associated with the 
> > LSP in the state on the PCE.  Should it be stated explicitly?
> >
> 
> Dhruv: Good suggestion.
> 
> > I wonder if "empty" is really the best term, as in other contexts 
> > one might assume that an "empty" TLV has length zero, rather than 
> > the length four that we mean here (with just the "binding value" field being empty).
> >
> 
> no Binding Value is present. Note that the length of the TLV would be 
> 4 in such a case.

Ok.

> avoid confusion in the WG.

Okay.  Probably best to not say anything about the naming in this document, then.

> > Why do we need two ways to do the same thing?  (Well, presumably 
> > "there's nothing else to put in the field", at least for this flag 
> > bit, but we could at least frame the discussion in the document more 
> > like "this one is authoritative, but when we are doing PCC 
> > allocation [as indicated by the authoritative setting], we have to 
> > also set this field accordingly in order to remain self-consistent" 
> > or be careful to always mention both together as a single unit.  I 
> > do note the later text that P=1 is only valid when use of the RFC 
> > 9050 procedures has been negotiated.)
> >
> 
> Further, if the binding label/SID is allocated by the PCC, the PCE 
> MUST set this bit to 0 and follow the procedure described in Section 
> 5.

I don't think that's quite the direction I was envisioning, but it seems like a good way to react to my comment.

> > I note that RFC 9050 referenced draft-li-pce-controlled-id-space as 
> > a potential future expansion that could allow advertising the range 
> > in-band via a PCEP extension, but that draft seems to have expired in August 2021.
> > I think we need to add RFC 9050 to this list; the things that can go 
> > wrong with PCE allocation definitely apply here (per §8).

> > % As described in [RFC9402] and [RFC8664], SR intrinsically involves 
> > an % entity (whether head-end or a central network controller) 
> > controlling % and instantiating paths in the network without the 
> > involvement of % (other) nodes along those paths.  Binding SIDs are 
> > in effect shorthand % aliases for longer path representations, and 
> > the alias expansion is in % principle known only by the node that 
> > acts on it.  In this document, % the expansion of the alias is 
> > shared between PCC and PCE, and rogue % actions by either PCC or PCE 
> > could result in shifting or misdirecting % traffic in ways that are 
> > hard for other nodes to detect.  In % particular, when a PCE 
> > propagates paths of the form {A, B, BSID} to % other entities, the 
> > BSID values are opaque, and a rogue PCE can % substitute a BSID from 
> > a different LSP in such paths to move traffic % without the recipient of the path knowing the ultimate destination.
> >
> > % The case of BT=3 provides additional opportunities for 
> > malfeasance, as % it purports to convey information about internal SRv6 SID structure.
> > % information, and mischaracterizing the division of bits into 
> > locator % block, locator node, function, and argument can result in 
> > different % interpretation of the bits by PCC and PCE.  Most 
> > notably, shifting bits % into or out of the "argument" is a direct 
> > vector for affecting % processing, but other attacks are also possible.
> >
> 

> > But I do not think you should make any change to this document at 
> > this time; I just mention it for general awareness.
> >
> > Section 12.2
> >
> > Just to confirm my understanding: there are no unallocated flags 
> > left in the LSP Object flag field?  Would we then be forced to 
> > either define a new object or use sentinel (zero-length) TLVs for 
> > things that would otherwise be treated as flags?
> > In particular (and related to discuss point (2)), why is a flag in 
> > the TE-PATH-BINDING TLV flag field not suitable and a flag in the 
> > toplevel LSP Object necessary?
> >
> 

> > mismatch" between RSVP-TE and SR.  That is, RSVP-TE is a protocol 
> > that I run and it "computes" paths for me.  But I see Segment 
> > Routing as a mode of operation that lets me use a path I already 
> > know, without maintaining per-path state on each node in the path.  
> > It doesn't compute the path for me, rather, it's something I can do 
> > once I know the desired path from some out-of-band mechanism.  So 
> > while it may be okay to say that I have a TE LSP "established using 
> > SR" in isolation (in that the headend just asserts the path and 
> > thereby "establishes" an LSP), to put it right next to having a TE 
> > LSP "established using RSVP-TE" seems to lack a certain parallelism of structure that I'm expecting.
> >
> 

That would help a lot.  There might be room for further improvement, but it would not stick out at me so much.

Thanks,

Ben

> > I am not sure what role the word "also" is intended to play here, 
> > and think that the paragraph would make sense if it was removed.
> >
> > Section 4.1
> >
> > Please make the SRv6 Binding SID field in Figure 4 taller in some 
> > fashion to match its 16-byte nature.
> >
> >
> >
>