Binding SID (BSID) is a method of steering traffic into an SR Policy. BSID is used to provide greater scalability. The BSID is bound to an SR Policy which may have a list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy. Usage of BSID decreases the number of segments imposed by the source.
According to topology and SR Policy, SR forwarding table on A1 will be;
Incoming Active Segment: 16999 Operation: PUSH 16002,16004, 16006 Egress Interface: The interface towards to A2
If any packets from a client or application comes to A1 with an MPLS label 16999 (which is the BSID of an SR Policy Red) A1 will remove BSID and push the label stack which is s SID List of SR Policy. If it was IPv6 Data Plane, it would be an SRH with Segment Lists.
Let’s assume we have a low-delay path like in the topology. All links have the cost value of 10 except the ones already mentioned in the topology.
SR Policy on R1 without BSID;
Incoming Active Segment: NULL Operation: PUSH 16002,16004, 16006, 16007, 16010 Egress Interface: The interface towards to R2
We needed to add labels to the SID List.
Now let’s assume we have a policy on R4 like below;
BSID: 16100
SID List: 16006, 16007, 16010
Data plane on R1,
Incoming Active Segment: NULL Operation: PUSH 16002,16004, 16100 Egress Interface: The interface towards to R2
Data Plane on R4,
Incoming Active Segment: 16100 Operation: POP and PUSH 16006, 16007, 16010 Egress Interface: The interface towards to R6
If the Core domain topology changes, the BSID of the intermediate SR Policy on R4 will not change.
It is also way of core domain topology information to aggregation layers, assuming core domain is some other company.
By default, BSID is dynamically allocated
BSID can be explicitly specified
BSID can be allocated for RSVP-TE tunnel. This one can be used when you are migrating a network from MPLS to SR. This is in the RFC standard and it will rely on defining a Binding SID for MPLS TE Tunnels. Currently we don’t have this option.
I believe one of the use case about BSID will be providing application to talk with network. Assume that you have 2 different SR policy with different SID lists. Let’s say;
SR Policy 1, BSID 16199, SID List is equal to lowest delay path
SR Policy 2, BSID 16299, SID List is equal to highest bandwidth path.
If the application can be programmed with SR, it just need to send traffic with related labels. If the traffic is sent with 16199, it will be automatically pushed into the lowest delay path and if it comes with 16299, it will be automatically pushed into the highest bandwidth path. If some changes happens in the network, application will not need to update anything.
