The binding segment is a local segment identifying an SR-TE policy. Each SR-TE policy is associated with a binding segment
ID (BSID). The BSID is a local label that is automatically allocated for each SR-TE policy when the SR-TE policy is instantiated.
Note |
In
Cisco IOS XR 6.3.2 and later releases, you can specify an explicit BSID for an SR-TE
policy. See the following Explicit Binding SID section.
|
BSID can be used to steer traffic into the SR-TE policy and across domain borders, creating seamless end-to-end inter-domain
SR-TE policies. Each domain controls its local SR-TE policies; local SR-TE policies can be validated and rerouted if needed,
independent from the remote domain’s head-end. Using binding segments isolates the head-end from topology changes in the remote
domain.
Packets received with a BSID as top label are steered into the SR-TE policy associated with the BSID. When the BSID label
is popped, the SR-TE policy’s SID list is pushed.
BSID can be used in the following cases:
-
Multi-Domain (inter-domain, inter-autonomous system)—BSIDs can be used to steer traffic across domain borders, creating seamless
end-to-end inter-domain SR-TE policies.
-
Large-Scale within a single domain—The head-end can use hierarchical SR-TE policies by nesting the end-to-end (edge-to-edge)
SR-TE policy within another layer of SR-TE policies (aggregation-to-aggregation). The SR-TE policies are nested within another
layer of policies using the BSIDs, resulting in seamless end-to-end SR-TE policies.
-
Label stack compression—If the label-stack size required for an SR-TE policy exceeds the platform capability, the SR-TE policy
can be seamlessly stitched to, or nested within, other SR-TE policies using a binding segment.
Explicit Binding SID
Use the binding-sid mpls
label command in SR-TE policy configuration mode to specify the explicit BSID. Explicit BSIDs are allocated from the segment routing
local block (SRLB) or the dynamic range of labels. A best-effort is made to request and obtain the BSID for the SR-TE policy.
If requested BSID is not available (if it does not fall within the available SRLB or is already used by another application
or SR-TE policy), the policy stays down.
Use the binding-sid explicit {fallback-dynamic | enforce-srlb} command to specify how the BSID allocation behaves if the BSID value is not available.
-
Fallback to dynamic allocation – If the BSID is not available, the BSID is allocated dynamically and the policy comes up:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# binding-sid explicit fallback-dynamic
-
Strict SRLB enforcement – If the BSID is not within the SRLB, the policy stays down:
Router# configure
Router(config)# segment-routing
Router(config-sr)# traffic-eng
Router(config-sr-te)# binding-sid explicit enforce-srlb
This example shows how to configure an SR policy to use an explicit BSID of 1000. If the BSID is not available, the BSID is
allocated dynamically and the policy comes up.
segment-routing
traffic-eng
binding-sid explicit fallback-dynamic
policy goo
binding-sid mpls 1000
!
!
!
Feedback