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

["Chengli (Cheng Li)" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, February 3, 2022 8:19 AM
To: Dhruv Dhody <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; pce-chairs <[e-mail]>; [e-mail]; Julien Meuric <[e-mail]>
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:
>  Hi Ben,
> 
> Thanks for your comprehensive review and comments.
> 
> On Wed, Feb 2, 2022 at 1:14 AM Benjamin Kaduk via Datatracker 
> <[e-mail]> wrote:
> >
> >
> > 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.
> >
> 
> 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!

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.

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

I balloted on both of those documents, yes :)

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

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:
> >
> >    *  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?)
> >
> >
> 
> 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.

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.

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

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

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

These both sound good to me.

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

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.

> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |    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?
> >
> 
> 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.

Sounds good.

> > 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?
> >
> 
> Dhruv: Good suggestion.
> 
> >    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).
> >
> 
> 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.

Ok.

> >                                   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?
> >
> 
> Dhruv: per BT makes sense!

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

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

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

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

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

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

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

> >    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...
> >
> 
> Dhruv: The document is in the WG adoption queue, must have expired 
> waiting in that queue :)
> 
> > 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).

Please don't forget this part :)

> >    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.
> >
> 
> Dhruv: Thanks for the suggested text. s/RFC9402/RFC8402/ -- otherwise LGTM.

Yes, 8402, sorry for the typo.

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

Ah, thanks for the pointer.

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

> >                    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.
> >
> >
> >
> 
> Thanks for these suggestions. I request the authors to update accordingly.
> 
> Thanks!
> Dhruv