Summary

I have reviewed draft-ietf-idr-bgp-ls-sr-policy, which specifies BGP Link-State (BGP-LS) extensions for advertising Segment Routing (SR) Policies. The draft helps controllers or other consumers gain real-time visibility into SR Policies, enabling more granular traffic-engineering and policy verification.

The document is logically structured and mostly clear about how SR Policy data (color, endpoints, binding SID, candidate paths, segment lists) should be advertised within BGP-LS. However, I identified a few operational areas that warrant further clarification or improvement, summarized below. These issues do not constitute a “showstopper” but should be addressed before proceeding.

Major Observations and Issues
1.	Operational Scaling Guidance
•	While the draft acknowledges that SR Policies could grow in number and frequency of updates, it does not provide concrete guidance for operators on mitigating potential BGP-LS route churn or controlling the scope of advertisement.
•	Recommendation: Add explicit guidelines (e.g., rate-limiting, peer scoping) to help operators manage BGP-LS sessions carrying large volumes of SR Policy updates.
2.	Examples and Clarity
•	The encoding definitions are comprehensive, but the text would benefit from additional examples—especially for multi-candidate-path scenarios and SRv6 use cases.
•	Recommendation: Provide at least one worked example of BGP-LS messages for SR-MPLS and SRv6, illustrating typical TLV structures and preference/tie-breaking among candidate paths.
3.	Interoperability with Legacy BGP-LS Speakers
•	The draft relies on the standard “ignore unknown attributes” approach to ensure backward compatibility, which is good practice. Nonetheless, it would help to explicitly restate any BGP capability procedures and clarify whether partial adoption can lead to incomplete data at older nodes.
•	Recommendation: Briefly reiterate the BGP capability advertisement approach and confirm that ignoring new TLVs will not cause inconsistent behavior in multi-vendor or partially upgraded networks.
4.	Security and Privacy
•	Segment Routing Policies can reveal detailed traffic-engineering decisions. The draft references general BGP security (TCP-AO, MD5) and standard best practices (filtering, ACLs), but a more explicit statement on restricting advertisement to authorized peers (and what data might be sensitive) would be valuable.
•	Recommendation: Include a short operational note explaining that SR Policy advertisements could be limited to trusted peers only and that strong authentication measures should be mandatory in production environments.
5.	Alignment with SR Policy Definitions in SPRING
•	The draft references SR Policy definitions from the SPRING working group. Any minor differences in field naming or usage could cause confusion.
•	Recommendation: Ensure references to SPRING documents are up to date and highlight any differences (if they exist) to avoid ambiguity for implementers.

Conclusion

Has Issues – The document is fundamentally solid and aligns with broader Segment Routing efforts. However, a handful of clarifications (particularly around scaling, examples, and detailed security considerations) would significantly improve its operational utility. I recommend the authors address these items before moving forward in the publication process.

Thank you for the opportunity to review this document. I am happy to discuss any questions or clarifications.