[spring] Discussion on draft-ietf-spring-srv6-policy-sid-list-opt-00

[陈宏彦 <[e-mail]>]

Dear Authors,

I have carefully reviewed draft-ietf-spring-srv6-policy-sid-list-opt-00 and would like to share several technical comments and suggestions. Overall, I find the document concise, practical, and technically well motivated. The draft addresses a very specific but meaningful inefficiency in SRv6 policy realization: when the SID list already ends at the policy endpoint in terms of forwarding intent, carrying an additional endpoint node SID can result in back-to-back local node-SID processing and unnecessary overhead. In that sense, the document focuses on a small optimization, but one with clear operational relevance.

From my understanding, the central contribution of the draft is to make inclusion or exclusion of the policy endpoint’s node SID an explicit policy attribute during SRv6 policy installation. This is a useful framing. Rather than treating the last SID as something that is always implicitly required, the draft recognizes that the need for that node SID depends on the forwarding context of the traffic steered over the policy. If the overlay SID already ensures that the traffic reaches the same endpoint with the same intent, suppressing the endpoint node SID can improve compression efficiency and reduce unnecessary local processing.

I also appreciate that the document addresses both PCEP-based and BGP-based policy creation workflows. This is important because the optimization is not only a local forwarding decision; it affects policy computation, signaling, installation, and advertisement. The discussion of MSD consideration is particularly useful, since excluding the endpoint node SID effectively reduces the installed SID-list length by one, which can matter when headend capabilities are constrained.

Another strong point is the explicit separation between service traffic and OAM traffic. The draft states that the optimization applies to service traffic steered over the policy, while OAM probes such as ping, traceroute, BFD, and STAMP should continue to include the last SID. That distinction is operationally sensible, because it preserves the full policy definition for OAM purposes while still allowing efficiency gains for service packets.

That said, I also have several questions and suggestions that may help strengthen the document further.

First, the core applicability condition—whether the traffic being steered over the policy already takes the traffic to the policy endpoint with the same intent—is intuitive but may benefit from more precise formulation. In practice, determining that two endpoint semantics are sufficiently aligned may not always be trivial, especially when service SIDs, binding SIDs, or other overlay constructs are involved. I think the draft would become stronger if it more clearly defined the decision criteria or at least provided a structured set of examples that distinguish safe exclusion cases from cases where exclusion must not be used.

Second, while the optimization is operationally attractive, it also introduces a subtle asymmetry between the computed SRv6 TE path and the actually installed SID list for service traffic. The PCE computes a list to the endpoint node SID, yet the headend may install one fewer SID. This is perfectly reasonable, but it may create ambiguity in telemetry, visualization, and troubleshooting tools unless clearly handled. The draft already points to BGP-LS advertisement extensions, which is good, but I think the operational implications of this “computed path versus installed path” distinction deserve more explicit treatment.

Third, the difference between data traffic and OAM traffic is well motivated, but it may also deserve more discussion from an operator perspective. The draft states that both will follow the same route because both are ultimately routed by the locator of the policy endpoint node. That is a valuable point. Still, there may be cases where operators expect packet captures, path verification tools, or telemetry exports to reflect identical SID stacks between service and OAM packets. Since the proposal intentionally breaks that visual symmetry, additional guidance on observability and troubleshooting expectations could be helpful.

Fourth, I think the document could discuss failure and boundary cases in more depth. The draft already notes that exclusion is not always possible, for example when the SRv6 policy carries MPLS traffic. This is important. However, there may be other edge cases as well, such as mixed service types on the same headend, partial capability support across control-plane peers, or policies ending with adjacency semantics rather than node semantics. A slightly richer treatment of such cases would make the proposal easier to apply safely in real deployments.

Fifth, capability negotiation is clearly important, especially in PCEP-based workflows, but the draft may benefit from more explicit discussion of mixed-capability environments. If some components understand SID-list optimization and others do not, operators will need predictable rules regarding fallback behavior, installation consistency, and controller/headend expectations. In multi-vendor or staged-upgrade networks, this may become a practical issue rather than a theoretical one.

Sixth, I think the optimization could be framed a bit more broadly in terms of overall SRv6 efficiency design. The removal of one SID may seem modest in isolation, but its value grows in environments where SID compression, MSD constraints, and hardware processing efficiency all matter. A short discussion of the cumulative operational benefit—especially in conjunction with other SRv6 optimization techniques—could help readers better appreciate why this apparently small change is worth standardizing.

Seventh, the security section is intentionally brief, and I agree that the draft does not introduce a fundamentally new threat model. Still, suppressing the last SID does make the installed data-plane encoding diverge from a more literal interpretation of the computed policy path. Even if this is fully intentional and safe, it may be useful to mention that correctness depends on trusted policy construction and correct signaling of the inclusion/exclusion attribute. In other words, the security story may remain unchanged at a high level, but the operational correctness story becomes slightly more subtle.

Finally, I think the draft would benefit from one or two end-to-end examples that compare the non-optimized and optimized cases in a more explicit way. For example, a simple SRv6 L3VPN or binding-SID-over-policy example showing the computed SID list, the installed SID list, and the OAM SID list side by side would make the procedures much easier to digest and review.

In summary, I believe this draft addresses a small but meaningful inefficiency in SRv6 policy realization and does so in a practical way. Its main strength lies in turning endpoint node-SID suppression into an explicit, controllable policy attribute rather than an implicit local optimization. At the same time, the document would be even stronger with sharper applicability criteria, clearer discussion of computed-versus-installed path semantics, more operational guidance for OAM and troubleshooting, and richer treatment of mixed-capability and boundary cases. With those refinements, I think the draft could provide very useful guidance for efficient SRv6 policy deployment.

Thank you for your work on this draft. I hope these comments are helpful and constructive.

Best regards,
Hongyan Chen