SR Policy Architecture

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-segment-routing-policy-06.txt

SR Policy包括什么？

1. ID of SR Policy = <headend, color, endpoint>
2. 1个Policy可以有多个Candidate Path， 一个CP可以有多个SID-lists, 可以有weight for LB
3. Protocol origin of CP 
• 10: PCEP; 
• 20: BGP SR; 
• 30: Local, CLI/Yang...
4. Originator of CP, 160b = 20B
• = 4B AS# + 16B Addr (128b) 
• 如果Addr是v4，就放在最后4B
5. Discriminator of CP, default 0, 这个是啥？一个就是seq#，作为tie-breaker
6. ID of CP = <protoOrig, originator, discrimator>
7. pref of CP = 100
8. Valid of CP, 就是SID是valid
9. Active CP
• higher origin id
• lower originator ip
• higher discriminator
10. SR policy还可以有priority，就是有topology change, 先算那个

SR Policy 例子：

• 1个policy, <headend, color, endpoint>
• 2个CP，CP1 is active 因为preference 200
• CP1有两个SID-List, 都installed in HW, 而且ECMP

验证 CP

• An explicit CP with SID-list = 应该是指静态CP
• 为空
• Weight = 0
• 1st SID不能resolve
• non-1st SID of type 3~11 into MPLS Label or SRv6 SID? 什么意思
• 挺多的，还有最后一个不是prefix SID
• Dynamic CP

Binding SID

• 非常关键的一个概念
• = CP，SR的无缝衔接？
• 可以代表任何的interface, tunnel. 

Steering:

• 这个是很关键的概念
• Headend可以steer traffic，以下方式：
• local BSID
• Per-dest, 需要BGP
• Per-flow?
• PBR
• 如果SR Policy失效，就fall back to 普通的routing
• SR Policy可以是Drop

BSID Steering

• <B, L2, L3> 变成 <S1, S2, S3, L2, L3> 如果S1不是PHP

Per-Dest Steering:

• 这个一个是最常见的
• BGP routes <prefix, N, ext-color-C, VPN-Label-V>
• Valid SR Policy - <endPt = N, color = C> of SID-list <S1, S2, S3> and BSID B
• 如果都met，NH != N, 而是=SR policy P of BSID B. 
• 收到prefix pkt, push <S1, S2, S3, V> label
• 一个BGP update里面可以有多个color, 如果有对应的policy with colors, 最终只有一个FIB，因为higher color prefered