Early Review of draft-ietf-idr-bgp-ls-sr-policy-10
review-ietf-idr-bgp-ls-sr-policy-10-opsdir-early-tsou-2024-12-28-00

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.