[spring] Re: Input requested: SR Policy state reporting requirement

[[e-mail]]

Hi Zhenqiang,

I think the point you raised from the operator's perspective is very interesting. 
As I commented before, one thing I didn't quite understand is that compared with BGP SR Policy for provisioning + BGP-LS for state reporting , why using BGP SR Policy for both provisioning and state reporting can reduce OPEX complexity and operational burden? For the former case, we can use the same BGP session for BGP and BGP-LS, without managing extra BGP sessions for BGP-LS. 
Could you describe a little bit more about this point?

Regards,
Yao



Original


From: 李振强 <[e-mail]>
To: 宋力焱 <[e-mail]>;idr-chairs <[e-mail]>;spring-chairs <[e-mail]>;idr <[e-mail]>;spring <[e-mail]>;
Cc: songguangchenjc <[e-mail]>;
Date: 2026年04月13日 18:35
Subject: [spring] Re: Input requested: SR Policy state reporting requirement

_______________________________________________
spring mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Dear SPRING Chairs, IDR Chairs and all,

As a coauthor of this draft, I look forward to inputs from both the SPRING and IDR working groups.

The problem addressed by this draft is important for network operators, especially large-scale operators such as China Mobile, which runs networks with thousands of devices and has widely deployed SRv6 Policies in production networks.
We need to collect real-time state information for deployed SR policies. If we use BGP-LS for this purpose, it would require establishing BGP-LS sessions between every headend node and the SDN controller. Although BGP-LS is being extended to report SR policy state, we believe that BGP SR Policy provides an alternative approach that is more suitable for large-scale networks with widespread SR policy deployments. OPEX complexity and operational burden can be significantly reduced, since the same protocol used for SR policy distribution can also be used for state reporting.

Regarding the first question raised by Liyan, I think it is primarily for SPRING. In my view, the answer is clearly yes, as solutions for SR policy state reporting are already being developed in BGP-LS, YANG push, and PCEP.
For the second question, I believe it falls primarily within IDR’s scope once the requirements are confirmed by SPRING. The rationale for proposing BGP SR Policy to report SR policy state is elaborated in the draft and summarized above.

Further comments and discussion are welcome. Thank you all in advance.


Zhenqiang
China Mobile

 ----邮件原文----
 发件人："宋力焱" <[e-mail]>
 收件人：idr-chairs <[e-mail]>,spring-chairs <[e-mail]>,idr <[e-mail]>,spring <[e-mail]>
 抄　送: lizhenqiang <[e-mail]>,songguangchenjc <[e-mail]>
 发送时间：2026-03-30 14:08:39
 主题：Input requested: SR Policy state reporting requirement
 
 


Dear WG chairs and all,


Following discussions in IDR (including feedback from the IDR chairs), we would like to seek input from SPRING on the requirement and direction for SR Policy state reporting.


We observe that there is currently no standard mechanism to report SR Policy operational state (Policy / Candidate Path / Segment List) from headend nodes to a controller in a structured and hierarchical manner. Existing approaches (e.g., BGP-LS, YANG) either require additional protocol mechanisms or do not align well with SR Policy constructs. In particular, they may require controllers to establish additional sessions (e.g., YANG) with headend nodes.


To address this, we are working on a draft: https://datatracker.ietf.org/doc/draft-li-idr-bgp-sr-policy-state-report/ . The draft extends BGP SR Policy (as defined in RFC 9830) to carry state information, allowing both policy provisioning and state reporting within the same framework, thereby reducing protocol overhead and simplifying operations.


Before proceeding further, we would like to confirm:
1. Is such a requirement considered valid in SPRING?
2. Is extending BGP SR Policy an appropriate direction for this problem?


The authors and the IDR WG chairs would greatly appreciate feedback and guidance from the SPRING WG. Any additional comments are also very welcome.


Best regards,
Liyan Song