Hi Gunter, Please review the update, hope it can address your comments.
HTML: https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-24.html HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6 Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-24 Thanks, Cheng Also, pasted the cut email of the reply from Dhruv below, please see my further reply inline. ============================== 143 [RFC8231] specifies extensions to PCEP that allow a stateful PCE to 144 compute and recommend network paths in compliance with [RFC4657] and 145 defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions I am unclear what 'recommend' means in this context? Can this be better explained and clarified? In RFC8231 there is no mentioning of recommended paths. Dhruv: In RFC 8231 you will note "LSP Update Request" i.e. PCE is requesting the PCC to update and PCC can report that the update is rejected. Also RFC 8664 uses similar framing. This could be updated to "compute and update" but it then loses the point that the PCC is free to reject. I will let this be... [Cheng]I am ok with let it be now. Gunter please see if this is ok for you. 157 account various constraints and objective functions. Once a path is 158 chosen, the stateful PCE can initiate an SR-TE path on a PCC using 159 PCEP extensions specified in [RFC8281] and the SR-specific PCEP “Once a path is chosen” seems to imply that there are multiple paths calculated and the best one is selected or chosen. Is this what is implied with this? Dhruv: Yes, 'computed' is better than 'chosen'! [Cheng]Done, see modifications. 161 extensions for supporting a SR-TE LSP for the MPLS data plane. This 162 document extends [RFC8664] to support SR for the IPv6 data plane. 163 Additionally, using procedures described in this document, a PCC can 164 request an SRv6 path from either a stateful or stateless PCE. This 165 specification relies on the PATH-SETUP-TYPE TLV and procedures 166 specified in [RFC8408]. This section is explaining what this draft is standardizing. It is a bit hidden and tucked all the way in the back of the introduction, a bit less trivial for the reader to discover. Dhruv: This can be put in its own paragraph. [Cheng]no comment here 168 This specification provides a mechanism for a network controller 169 (acting as a PCE) to instantiate candidate paths for an SR Policy 170 onto a head-end node (acting as a PCC) using PCEP. For more Before there was mentioning of a “network planning tool”. Maybe instead the term network controller can be used? Dhruv: agree [Cheng]Agree 212 Basic operations for PCEP speakers are as per [RFC8664]. SRv6 Paths 213 computed by a PCE can be represented as an ordered list of SRv6 214 segments Reading this gives wrong indication that RFC8664 computes SRv6 paths. In the RFC8664 is explicitly written that “This document is relevant to the MPLS forwarding plane only.” Dhruv: maybe "built on" instead of "as per". [Cheng]No problem 250 In SR networks, an SR source node encodes all packets being steered 251 onto an SR path with a list of segments. “SR source node”. I am unsure what this refers towards. Would this be the segment routing ingress node? In Segment Routing (SR), the ingress node is known by the fact that it is the node where the packet enters the Segment Routing domain. When a packet enters a network that employs Segment Routing, it is typically tagged with a Segment List at the ingress node. Dhruv: RFC 8754 and RFC 8986 use the term. Maybe we can reframe this as - "In SR networks, an SR source node [RFC8754] steers a packet into an SR Policy resulting in a segment list." 363 order to indicate that the path is for SRv6, any RP or SRP object These acronyms are not specified in the terminology section: Request Parameters (RP) [RFC5440] and the Stateful PCE Request Parameters (SRP) Dhruv: They are expanded on first use in section 3.2 [Cheng] Gunter's proposal looks good to me. 398 The 'L' Flag: Indicates whether the subobject represents a loose-hop 399 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 400 overwrite the SID value present in the SRv6-ERO subobject. 401 Otherwise, a PCC MAY expand or replace one or more SID values in the 402 received SRv6-ERO based on its local policy. The exact meaning of L-flag is confusing for SRv6. When looking at RFC3209 it reflects upon nodes, however with SRv6 this may be an adj-SID or some other instruction. Maybe the L-flag can be enhanced to described what this means in the context of SRv6 SID. Dhruv: The text is the same as RFC 8664 (SR-MPLS) and within the context of PCEP it means that PCC should use the SID as it is v/s PCC being able to apply suitable changes. If the intention is that the path as computed by PCE should be used as it is, it is expected that the L flag would be set accordingly. [Cheng]I agree with Dhruv, it seems the same with SR-MPLS. From RFC3209: The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node. 438 Flags: Used to carry additional information pertaining to the 439 SRv6-SID. This document defines the following flag bits. The other 440 bits MUST be set to zero by the sender and MUST be ignored by the 441 receiver. There is mentioning of S/F/T/V. is there a reason they are called like that? I suspect I am missing the history of naming of these flags and it just looks mostly random at this stage Dhruv: The trend that started from RFC 8664 :) [Cheng]it looks to me interesting as well in the early beginning. But we may leave it aside? 475 SRv6 SID: SRv6 Identifier is an 128-bit value representing the SRv6 476 segment Any special considerations for csid? Dhruv: As stated in the compression draft, no change is needed in PCEP. [Cheng]Yes 481 At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO 482 subobject, and both MAY be included. Is there any checking or processing to check if the NAI and SRV6-SID belong to the same node? Can they belong to different nodes? Dhruv: Note that such a such is not done in SR-MPLS either, I would assume that the SID value trumps NAI. [Cheng]that may be done by other drafts, if some people think this is a problem to be solved, till now, we might not need to mention that. 731 If a PCC receives an SRv6 path that exceeds the SRv6 MSD 732 capabilities, it MUST send a PCErr message with Error-Type = 10 733 ("Reception of an invalid object") and Error-Value = 43 ("Unsupported 734 number of SRv6-ERO subobjects") as per [RFC8664]. I assume this is about exceeding the local PCC capabilities? A local PCC router may have enough intelligence to understand the capability of all nodes through which the datapacket will be steered. In theory the encoded payload may traverse a node that is not capable to process the SRH pushed by the SR PCC ingress router. Dhruv: Yes, this is about local. [Cheng]ACK 738 The SRv6-ERO contains a sequence of subobjects. According to 739 [RFC9256], each SRv6-ERO subobject in the sequence identifies a 740 segment that the traffic will be directed to, in the order given. 741 That is, the first subobject identifies the first segment the traffic 742 will be directed to, the second SRv6-ERO subobject represents the 743 second segment, and so on Is there expectation that the node of a NAI corresponds with the node owning a SRv6-SID Dhruv: Yes [Cheng]Yes 771 Note that this specification enables a network controller to 772 instantiate an SRv6 path in the network. This creates an additional Would it be more correct to indicate that it enables both to initiate and to monitor an SRv6 path? Dhruv: The security vulnerability is more about instantiation. [Cheng]Agree Authors, please feel free to add your comments especially if you disagree with my responses here. Thanks! Dhruv _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
