Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
draft-ietf-pce-binding-label-sid-16

[Ballot comment]
Thank you for addressing my Discuss concerns.

I still am unhappy about the way that this document propagates the
notion of a substructure within IPV6 addresses in addition to that
expected by the IPv6 addressing architecture, adding an attempt to
imbue meaning to that substructure both within protocol flows and
in broader use in the network in question; my expectation was that
any such substructure would be local to the node holding the addresses.
That said, this topic has been well-litigated and I am balloting
Abstain to note my concern without blocking publication of the document.

And retaining one remark from my comments on the -13
====================================================
One new remark on Section 4.1 -- the phrasing "corresponding TE-PATH-BINDING-TLV MUST be
considered as an error" seems unusual in the context of PCEP extensions.  I see some
cases where a particular condition causes an error message to be sent but not anywhere
where a malformed TLV or message is "considered as an error" directly.

[Ballot comment]
FORMER DISCUSS (for the record)
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.



FORMER COMMENTs (FOR the record)
  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/

[Ballot comment]
[As described in my ballot position on the -12, I will likely Abstain after the remaining
Discuss point is resolved.]
Thank you for addressing my previous COMMENTs!

One new remark on Section 4.1 -- the phrasing "corresponding TE-PATH-BINDING-TLV MUST be
considered as an error" seems unusual in the context of PCEP extensions.  I see some
cases where a particular condition causes an error message to be sent but not anywhere
where a malformed TLV or message is "considered as an error" directly.

[Ballot discuss]
[this part of my discuss still seems to apply]

(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.

[Ballot comment]
[As described in my ballot position on the -12, I will likely Abstain after the remaining
Discuss point is resolved.]
Thank you for addressing my previous COMMENTs!

[Ballot comment]
Thanks for this document.

No comments other than to say thank you for the reference of where the associated configuration YANG will be found.

Regards,
Rob

[Ballot comment]
Thank you to Dan Harkins for the SECDIR review.

I support Ben Kaduk’s DISCUSS position.

I have concerns based on the behavior intended for Binding Type (BT) = 3.  As was balloted for draft-ietf-lsr-isis-srv6-extensions, this document also describes a TLV to carry the SID sub-structure as an addressing mechanism which seems at odds with the IPv6 addressing architecture (RFC 4291). Despite this reservation, I see that there is a significant, production implementation and for this reason I am balloting no objection.

[Ballot comment]
Thanks to Theresa Enghardt for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/IyiRN3TEd1p_yEs0UviVwhgH04Q).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1.2. , paragraph 4, nit:
-    binding label/SID, and associted error handling.
+    binding label/SID, and associated error handling.
+                                +

Section 1.2. , paragraph 2, nit:
> and PCE can use this TLV, how they can can allocate a binding label/SID, and
>                                    ^^^^^^^
Possible typo: you repeated a word.

Document references draft-ietf-pce-pcep-yang-17, but -18 is the latest
available revision.

Document references draft-ietf-spring-segment-routing-policy-14, but -16 is the
latest available revision.

[Ballot 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.

[Ballot comment]
[S4.1; question]

* For clarity, when the locator prefix is a /48 and the nodes are each
  allocated a /64, which of these is expected:

    [a] {LB=48, LN=64, FUN=..., ARG=...}, or

    [b] {LB=48, LN=16, FUN=..., ARG=...}

    (where LB + LN = 64)?

[Ballot 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?)

[Ballot 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.

[Ballot 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.

[Ballot 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.

[Ballot 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.

[Ballot 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.

[Ballot discuss]
Hi,

thank you for this document.
I have few points I'd like to discuss. Ssome 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.

[Ballot 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/

[Ballot comment]

Thank you for the work put into this document. It explains a lot how RFC 8986 'network programming' can be used in a PCE/PCC environment and it is welcome. Even if parts of the document is difficult to read (e.g., the use case example).

Please find below one non-blocking COMMENT point.

Special thanks to Julien Meuric for the shepherd's write-up including the section about the WG consensus (even if I would have appreciated a justification for the PS status).

I hope that this helps to improve the document,

Regards,

-éric

There are still many typos in the document; even if the RFC editor will fix them, let's try to avoid them.

-- Abstract --
Introducing "(SID)" after Segment Identifier would help the reader to understand the content of this document.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-binding-label-sid-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the temporary registration for

Value: 55
Description: TE-PATH-BINDING

will be made permanent and its reference changed to [ RFC-to-be ].

Second, a new registry will be created called the TE-PATH-BINDING TLV BT field on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

Value Description Reference

0 MPLS Label [ RFC-to-be ]
1 MPLS Label Stack Entry [ RFC-to-be ]
2 SRv6 SID [ RFC-to-be ]
3 SRv6 SID with Behavior and Structure [ RFC-to-be ]
4-255 Unassigned [ RFC-to-be ]

Third, a new registry will be created called the TE-PATH-BINDING TLV Flag field on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:

Bit Description Reference

0 R (Removal) [ RFC-to-be ]
1-7 Unassigned [ RFC-to-be ]

Fourth, in the LSP Object Flag Field registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the temporary registration for

Bit: 0
Description: PCE-allocated binding label/SID

will be made permanent and its reference changed to [ RFC-to-be ].

Fifth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a new Error-type and associated Error-values will be registered as follows:

Error-Type Meaning Error-value Reference

TBD2 Binding label/SID failure
0: Unassigned [ RFC-to-be ]
TBD3: Invalid SID [ RFC-to-be ]
TBD4: Unable to allocate the specified binding value [ RFC-to-be ]
TBD5: Unable to allocate a new binding label/SID [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-01-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-binding-label-sid@ietf.org, jgs@juniper.net, julien.meuric@orange.com, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Carrying Binding Label/Segment Identifier in PCE-based Networks.) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Carrying Binding Label/Segment Identifier
in PCE-based Networks.'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-01-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In order to provide greater scalability, network confidentiality, and
  service independence, Segment Routing (SR) utilizes a Binding Segment
  Identifier (BSID).  It is possible to associate a BSID to an RSVP-TE-
  signaled Traffic Engineering Label Switched Path or an SR Traffic
  Engineering path.  The BSID can be used by an upstream node for
  steering traffic into the appropriate TE path to enforce SR policies.
  This document specifies the binding value as an MPLS label or Segment
  Identifier.  It further specifies an approach for reporting binding
  label/Segment Identifier (SID) by a Path Computation Client (PCC) to
  the Path Computation Element (PCE) to support PCE-based Traffic
  Engineering policies.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-pce-segment-routing-ipv6: PCEP Extensions for Segment Routing leveraging the IPv6 data plane (None - Internet Engineering Task Force (IETF))

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
- Proposed Standard

Why is this the proper type of RFC?
- It's a protcol extension.

Is this type of RFC indicated in the title page header?
- Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  In order to provide greater scalability, network confidentiality, and service
  independence, Segment Routing (SR) utilizes a Binding Segment
  Identifier (BSID).  It is possible to associate a BSID to an RSVP-TE-
  signaled Traffic Engineering Label Switch Path or an SR Traffic
  Engineering path.  The BSID can be used by an upstream node for
  steering traffic into the appropriate TE path to enforce SR policies.
  This document specifies the binding value as an MPLS label or Segment
  Identifier.  It further specifies an approach for reporting binding
  label/SID by a Path Computation Client (PCC) to the Path Computation
  Element (PCE) to support PCE-based Traffic Engineering policies.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
- No

Document Quality:

Are there existing implementations of the protocol?
- Yes, 2 implementations are mentioned in the I-D.

Have a significant number of vendors indicated their plan to implement the specification?
- There are 4 different vendors among the authors.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?
- Adrian Farrel did a careful review of the document and Olivier Dugeon suggested to add a flag which resulted in a more robust and consistent extension.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
- N/a

Personnel:

Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
- This document looks ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
- No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
- No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
- N/a

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
- Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
- No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
- There is consensus behind this document, with several vendors involved, a few reviews and links with some work in 2 WGs (PCE & Spring). Early allocation was requested for some of the code points.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
- No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
- Done

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- N/a

(13) Have all references within this document been identified as either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
- N/a

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
- N/a

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
- No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
- Checked (some part of the IANA section already triggered an early code point allcoation).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
- N/a

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
- N/a

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
- N/a

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
- Proposed Standard

Why is this the proper type of RFC?
- It's a protcol extension.

Is this type of RFC indicated in the title page header?
- Yes

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  In order to provide greater scalability, network confidentiality, and service
  independence, Segment Routing (SR) utilizes a Binding Segment
  Identifier (BSID).  It is possible to associate a BSID to an RSVP-TE-
  signaled Traffic Engineering Label Switch Path or an SR Traffic
  Engineering path.  The BSID can be used by an upstream node for
  steering traffic into the appropriate TE path to enforce SR policies.
  This document specifies the binding value as an MPLS label or Segment
  Identifier.  It further specifies an approach for reporting binding
  label/SID by a Path Computation Client (PCC) to the Path Computation
  Element (PCE) to support PCE-based Traffic Engineering policies.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
- No

Document Quality:

Are there existing implementations of the protocol?
- Yes, 2 implementations are mentioned in the I-D.

Have a significant number of vendors indicated their plan to implement the specification?
- There are 4 different vendors among the authors.

Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?
- Adrian Farrel did a careful review of the document and Olivier Dugeon suggested to add a flag which resulted in a more robust and consistent extension.

If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
- N/a

Personnel:

Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- John Scudder

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
- This document looks ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
- No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
- No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
- N/a

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
- Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
- No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
- There is consensus behind this document, with several vendors involved, a few reviews and links with some work in 2 WGs (PCE & Spring). Early allocation was requested for some of the code points.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
- No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
- Done

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
- N/a

(13) Have all references within this document been identified as either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
- N/a

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
- N/a

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
- No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
- Checked (some part of the IANA section already triggered an early code point allcoation).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
- N/a

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
- N/a

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
- N/a

Request for posting confirmation emailed to previous authors: Cheng Li , Clarence Filsfils , Jeff Tantsura , Jonathan Hardwick , Siva Sivabalan , Stefano Previdi , pce-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Stefano Previdi , Clarence Filsfils , pce-chairs@ietf.org, Jonathan Hardwick , Siva Sivabalan , Jeff Tantsura , Cheng Li

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Jonathan Hardwick , Siva Sivabalan , pce-chairs@ietf.org, Cheng Li , Stefano Previdi , Jeff Tantsura

Request for posting confirmation emailed to previous authors: Jeff Tantsura , pce-chairs@ietf.org, Cheng Li , Siva Sivabalan , Clarence Filsfils , Stefano Previdi , Jonathan Hardwick

Request for posting confirmation emailed to previous authors: pce-chairs@ietf.org, Cheng Li , Siva Sivabalan , Stefano Previdi , Jeff Tantsura , Clarence Filsfils , Jonathan Hardwick

Request for posting confirmation emailed to previous authors: Siva Sivabalan , Jonathan Hardwick , pce-chairs@ietf.org, Jeff Tantsura , Clarence Filsfils , Stefano Previdi , Cheng Li