doc/srv6: Add HLD for SR-Policy support with SRv6 dataplane

[manoharan-nexthop]

Adds HLD document for SRv6 traffic engineering features on SONiC:

sr_policy.md — SR-Policy (SR-TE)
Covers static SR-Policy provisioning: segment-lists, explicit candidate-paths, and policies identified by (Color, Endpoint). Includes the sonic-sr-te.yang model, CONFIG_DB/APPL_DB/ASIC_DB schema, frrcfgd → pathd integration, and traffic steering via static Color:Endpoint routes and BGP Color extended-community. Includes a complete end-to-end example with failure/recovery debugging.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[ahsalam]

@manoharan-nexthop i have two initial comments:

• I would suggest splitting this HLD into two separate PRs (SR Policy and Full SID are two orthogonal things)
• What is the use-case where we need a full SID. SRv6 uSID supports any use-case with much lower overhead and is now the industry standard deployed by all operators (please also refer to MRC + SRv6)
  https://cdn.openai.com/pdf/resilient-ai-supercomputer-networking-using-mrc-and-srv6.pdf

[mssonicbld]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[manoharan-nexthop]

@manoharan-nexthop i have two initial comments:

• I would suggest splitting this HLD into two separate PRs (SR Policy and Full SID are two orthogonal things)
• What is the use-case where we need a full SID. SRv6 uSID supports any use-case with much lower overhead and is now the industry standard deployed by all operators (please also refer to MRC + SRv6)
  https://cdn.openai.com/pdf/resilient-ai-supercomputer-networking-using-mrc-and-srv6.pdf

we have separated the full SID HLD to #2439. Regarding the question on why, we do have a customer for this. If needed, we can discuss more on this on the other HLD (or during review)

[chenxu-af]

@manoharan-nexthop It's this design didn't consider SRv6 VPN cases(refer https://github.com/sonic-net/SONiC/blob/master/doc/srv6/srv6_vpn.md), it's looks some differences, will the two designs be merged in future SRV6 VPN scenarios?

[manoharan-nexthop]

@manoharan-nexthop It's this design didn't consider SRv6 VPN cases(refer https://github.com/sonic-net/SONiC/blob/master/doc/srv6/srv6_vpn.md), it's looks some differences, will the two designs be merged in future SRV6 VPN scenarios?

Hi @chenxu-af , thanks for going through the HLD. Are there more information on how the SR-Policies are populated in SONiC. I didnt see any code PRs for these HLDs. Can you please point me to them. I will look into them more.

The critical difference I see is,

segment = SRV6_SID_LIST.key ; Optional field. List of segment names, separated by ','
policy = policy ; Optional field to add a list of policy names, separated by ','

Since this predates using nexthop-group, are there more changes to the design? If not, wondering how the change in policy reachability be handled.