Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Binding SID (BSID) for Static SRv6 TE Tunnels

The SRv6 binding SID (BSID) is an instruction to a transit router to steer an incoming SRv6 packet down a traffic-engineered path. This is achieved by pushing a new IPv6 header onto the packet, potentially with a new SRH, containing an SRv6 SID stack that defines the TE path. This has many uses regarding network stability, such as enabling hardware with shallow SID stack capabilities to send traffic down a large TE path, or helping to isolate or decouple different source-routed domains. The BSID allows the segregation of the network into multiple TE tunnels, each comprising its own SID stack and compute model. This feature enables the static SRv6 TE tunnels with transit functionality.

Binding SID Overview

When an ingress router is configured with Segment Routing over IPv6 with Traffic Engineering (SRv6-TE) feature, an incoming service payload is encapsulated in an IPv6 tunnel, optionally with an SRH that directs the traffic to take a specific TE path in the network, based on the configured SRv6 policy.

Often the SID stack can grow in size resulting in packet overhead. Some devices in the network might not be able to write, pop, or process packets with large SRv6 SID stacks. In addition to this, it might sometimes be impractical for the ingress node to encode the whole stack for inter-domain networks, because the ingress router might not have knowledge of remote topologies and SIDs in its Traffic Engineering Database (TED). Leaking this information between routing domains comes with its own trade-offs, including overhead and convergence issues. If there is a transit MPLS domain, the labels and SRv6 SIDs might result in a lot of overhead as well.

The SRv6 binding SID (BSID) provides a solution by segregating an end-to-end path into multiple TE tunnels. Binding SIDs are a segment type where one incoming SID acts as an instruction to encapsulate the existing IPv6 transport header with a brand new IPv6 header that contains a stack of outgoing SIDs.

A transit router, configured with a binding SID, gains the ability to act as an ingress router for a shorter TE tunnel on the larger path. This is formally described as steering the incoming packet into an SR policy. When a packet is steered into an SR policy with a BSID, the node that owns the BSID expands that SID into the full segment list of the associated policy.

In a binding SID implementation, an ingress router no longer needs to push the entire end-to-end stack of SIDs onto a packet. Instead, it is enough to strategically push a smaller number of binding SIDs onto a packet. Therefore, rather than having full knowledge of the entire wider network, the ingress node only needs knowledge of the binding SIDs in the network to create a TE path. The wider network convergence is taken care of at the transit node that is provisioned with the binding SID.

Remote transit routers remove these SIDs from the IPv6 Destination Address (DA) field, and push the additional TE segments in a new IPv6 header. In this respect, each TE tunnel on the path can be comprised of its own stack, its own choice of whether or not to use backup paths, and its own compute model.

When a transit node, configured with a binding SID, receives an incoming packet with its IPv6 DA matching the BSID through longest prefix match, the transit router first pops the binding SID. In the case of classic SRv6, this involves writing the next address in the SRH to the IPv6 DA. In the case of SRv6 with micro-SIDs, this involves popping the active micro-SID from the IPv6 DA, and then either rewriting the IPv6 DA as appropriate, or writing the next address in the SRH to the IPv6 DA. The transit router then encapsulates the packet with a new IPv6 header that contains the SIDs for the onward TE path. In the case of classic SRv6, this IPv6 header will likely contain an SRH with additional segments. In the case of SRv6 with micro-SIDs, the DA in the new IPv6 header might be enough to carry all the required SIDs. If not, the new IPv6 header can carry a new SRH. This results in a comparatively reduced stack size at the ingress node, because the additional SIDs are written to the packet by the transit router.

Four types of SRv6 binding SIDs are supported:

  • Classic SRv6 binding SID

    • END.B6.Encaps: When the transit node, configured with a binding SID, processes a matching packet, it always encapsulates the outgoing packet with a new IPv6 header and SRH that contains the SID stack of the new TE tunnel. This is a non-reduced mode implementation and thus the address in the new IPv6 DA is also written to the SRH.
    • END.B6.Encaps.Red: This is the reduced mode implementation where the first SRv6 address in the stack is only written to the DA of the new IPv6 address and not to the SRH. When the transit node, configured with a binding SID, processes a matching packet, it encapsulates the outgoing packet with a new IPv6 header and optionally, an SRH. There may not be an SRH for the outer IPv6 encapsulation if the SRv6 policy only contains one SID. This is the default mode.
  • Micro SRv6 binding SID

    • END.B6.Encaps with Next-C-SID: When the transit node, configured with a binding SID, processes a matching packet, it encapsulates the outgoing packet with a new IPv6 header and SRH that contains the SID stack of the new TE tunnel. This is a non-reduced mode implementation and thus the DA in the new IPv6 header is also written in the SRH. This is true even if the micro-SID stack can be contained inside one single IPv6 DA.

    • END.B6.Encaps.Red with Next-C-SID: When the transit node, configured with a binding SID, processes a matching packet, it encapsulates the outgoing packet with a new IPv6 header and optionally, an SRH. The DA of the outer IPv6 header is not added to the SRH. If the SRv6 policy contains a stack of micro-SIDs that can be written to one single IPv6 DA, or if the SRv6 policy only contains one SID, then the packet will not contain an SRH. This is the default mode.

The binding SID configuration is performed on the transit router. You define the binding SID directly inside the SR policy that it is bound to. This immediately associates that binding SID with the correct TE path.

The following options are available to configure binding SID under the [edit protocols source-packet-routing source-routing-path] hierarchy. You can either configure a classic SRv6 binding SID or a micro SRv6 binding SID. The locator must be preconfigured under the [edit routing-options source-packet-routing srv6 locator] hierarchy. The static SID is mandatory and must be from within the local micro SID static SID range defined for the block under the [edit routing-options source-packet-routing srv6 block] hierarchy.

  • You can either configure a classic SRv6 binding SID or a micro SRv6 binding SID:

    When configuring the classic SRv6 SID, the entire classic BSID must be provided along with the locator name. For example:

    When configuring the micro SRv6 SID, only the functional part needs to be provided along with the locator name. For example:

  • The ingress router is configured with the first segment list hop as the binding SID. In the configuration snippet below, 5f00:0:200:fc58:: is the micro binding SID configured on the transit router. Notice that the configuration does not mention that this is a binding SID, because this information is not important to the ingress router. The SRv6 micro service SID 5f00:0:2020:: is the last hop in the segment list. For example:
  • The feature supports multiple transit routers with binding SID in a TE path. The ingress router must be configured with every binding SID transit router as a segment list hop. In the example below P2 and P4 are two transit routers on the TE path with binding SID configured.

  • You can enable traces specific to SRv6 binding SID.

Benefits of Binding SRv6 SID

  • The Ingress node requires only a subset of TE database of other domains.

  • Convergence is taken care of at each transit nodes provisioned with binding SID

  • You can deploy a cross-data plane switch (SRv6 to MPLS) by configuring a binding SID to pop the outer IPv6 header, and then push one or more outgoing MPLS labels.

Limitations and Caveats

  • Endpoint behavior flavors like USD, USP or PSP associated with an SRv6 BSID are not supported for binding SID.
  • No support for insert mode SRv6 binding SID endpoint behaviors such as END.B6.Insert, END.B6.Insert with Next-C-SID and END.BM.
  • Only default length SID structure is supported for END.B6.Encaps with Next-C-SID and END.B6.Encaps.Red with Next-C-SID (BL: 32, NL: 16, FL:16, AL:64).

  • A change in locator configuration requires a routing restart for the change to take effect.

  • Support for transport class and colored SR-TE only.

  • Support for BGP-LS distribution of SRv6 classic binding SID and micro binding SID.

  • Support for binding SID configuration with its segment list ending at egress node of the SRv6 tunnel.

See Also

Configure Binding SID (BSID) for Static SRv6 TE with Micro-SIDs

Note: The configuration provided in this topic is only specific to binding SID with SRv6 TE and assumes interfaces, IGP and Segment Routing have been preconfigured. An extensive configuration example for static SRv6 TE is covered here.
Consider the network topology illustrated in Figure 1 that implements micro END.B6.Encap BSID with segment instantiated at a transit router.
At ingress node PE1, the SRv6-TE ingress policy is configured with a segment list, which has one of its hops configured with an SRv6 micro binding SID. The BSID is instantiated at P2.
PE1 encapsulates the payload with an IPv6 header DA comprising the next hop SID (100), P2's SRv6 micro BSID (200:ffd1) and PE2's micro service SID (2020:ff01).

In total, PE1 has written five micro-SIDs to the IPv6 DA. In practice, some platforms may only be able to write a limited number of SRv6 micro-SIDs to the IPv6 DA, and therefore this SID stack would require an SRH. The implementation varies between platforms. However, the general behavior described in this example is universal.

When P2, configured with a binding SID, receives the packet matching the END.B6.Encaps with Next-C-SID or END.B6.Encaps.Red with NEXT-C-SID local SID through longest prefix match, it first pops its binding SID from the IPv6 DA, and rewrites the IPv6 DA accordingly. P2 then it encpasulates the outgoing packet with a segment list comprising P4's SRv6 micro-SID and P6's SRv6 micro-SID in the DA of the new IPv6 header. This new header may or may not contain an SRH, depending on whether the SID is configured for reduced or non-reduced mode behavior.

P6 is the egress router for the new tunnel that began at P2. When the packet arrives at P6, the outer header is decapsulated along with any SRH. The packet is then forwarded to the egress node PE2 where the inner header is decapsulated and resolved using a longest prefix match. The payload is then forwarded to its destination.

Figure 1: Packet forwarding with Micro END.B6.Encap BSID with segments instantiated at P2 Packet forwarding with Micro END.B6.Encap BSID with segments instantiated at P2
  1. Before configuring a binding SID on the transit router, ensure you have configured a named SRv6 block and a reserved a portion of this block for allocation to static SIDs for local locators.
  2. Define a micro-SID locator tied to the SRv6 block to derive SIDs. Ensure the micro-SID is advertised in IS-IS.
    Note:
    • The endpoint behavior flavors such as USD, USP or PSP do not apply to binding SID.

    • When the no-reduced-srh option is configured globally, it must also be configured with the binding SID configuration.
  3. Still on the transit router, configure a segment list to define the list of SIDs that will determine the onward TE path. When encapsulating the outgoing packet, the transit router will use this segment list to construct the DA of the new IPv6 header with the SRH, based on no-reduced-srh implementation.
  4. Still on the transit router, configure the micro-SID based colored SRv6-TE path with binding SID.
    1. Configure the new micro-SID based SRv6-TE path that the incoming packet should be steered into. Refer to the segment list that you just created, and tag the SR-TE path with the appropriate color value.
    2. Define the incoming binding SID that should be associated with this SR-TE path. Choose an unused SID value from the range that you have allocated for static use. You can verify the static SID range using the show srv6 block block_name command. The no-reduced-srh is optional but must be configured with the binding SID configuration if configured globally. By default reduced mode is implemented. When the router receives a packet matching the micro binding SID, it encapsulates the packets based on the instructions of the primary path. Only one binding SID per source routing path is supported.
  5. Now on the ingress router configure the SRv6 block and micro-SID locator.
  6. Still on the ingress router, configure segment lists to define the list of SIDs that will determine the onward TE path. Ensure the first hop is the SRv6 micro BSID of the transit node. PE1 encapsulates the payload with an IPv6 header DA comprising the first SID in the engineered path, followed by P2's SRv6 micro BSID. The SRv6 micro service SID may be a part of the DA or a separate micro-SID container in the SRH.
  7. Configure the micro-SID based SRv6-TE path on the ingress router.

Verify Binding SID Configuration

Purpose

These verification commands trace the lifecycle of a Binding SID (BSID) and an SR-TE Policy through the router's control plane.

Action

  • Verify the binding SID allocation from the locator on the transit router using the show srv6 locator loc_name command. In the output below, you can observe the BSID is allocated from the locator prefix. The SID behavior is configured as End.B6.Encaps with Next-CSID, which means upon receiving a matching packet, the router will encapsulate it with an SRH.

  • Verify the SRv6 binding SID information in the SR-TE database of the transit router using the show spring-traffic-engineering srv6-binding-sid database command. In the output below, you can verify the BSID is installed in the SR-TE policy database and it is mapped with the configured policy and tunnel.

  • Verify the SR-TE ingress LSP detail for the source routing path on the transit router using the show spring-traffic-engineering lsp detail name path_name. In the output below, you can verify the LSP state, BSID association and the actual segment list (SR-ERO). This implies that the router is aware of the policy path and segments used for traffic steering.

  • Verify SR-TE router information for the binding SID and micro service SID on the transit router using the show spring-traffic-engineering route detail command. The output below confirms there are routes pointing to the BSID and to the endpoint. It also shows the associated LSP forwarding.

  • Verify the SRv6 policy information in the traffic engineering database on the transit router using the show ted spring-te-policy extensive command. The output below shows the origin, color and segment list for the SRv6 policy.

  • Verify the SR-TE ingress LSP detail for the source routing path on the ingress router using the show spring-traffic-engineering lsp detail name path_name command. In the output below, Hop 1 is the BSID that the ingress pushes in the new IPv6 header DA, with or without SRH. Hop 2 is the service micro-SID.

  • Verify the traffic flow through the SR-TE path. Note that 2001:db8:1000::100, 2001:db8:1000:200 and 2001:db8:1000::2020 are ingress interface IPs for routers P1, P2 and PE2. 2001:db8:6::6 is the loopback address for P6 router.

    Additional Verification

  • If your router has BGP-LS enabled, you can verify the BGP-LS distribution table on the transit router using the show route table lsdist.0 te-policy-spring-te-color color extensive command. The output below confirms the policy is exported via BGP-LS for a controller or network-wide distribution. The policy is advertised with color, endpoint, BSID and segment list information.