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: 李振强 <[email protected]>
To: 宋力焱 <[email protected]>;idr-chairs
<[email protected]>;spring-chairs <[email protected]>;idr
<[email protected]>;spring <[email protected]>;
Cc: songguangchenjc <[email protected]>;
Date: 2026年04月13日 18:35
Subject: [spring] Re: Input requested: SR Policy state reporting requirement
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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
----邮件原文----
发件人："宋力焱" <[email protected]>
收件人：idr-chairs <[email protected]>,spring-chairs
<[email protected]>,idr <[email protected]>,spring <[email protected]>
抄 送: lizhenqiang <[email protected]>,songguangchenjc
<[email protected]>
发送时间：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
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
