BIER

BIER FRR uses basic LFA only; it cannot use TI-LFA or remote-LFA. Also, currently BIER FRR only supports ISIS.

Use the commands in the following context to configure LFA:

• MD-CLI

  configure router isis loopfree-alternate

• classic CLI

  configure router isis loopfree-alternates

When FRR is enabled, link protection is enabled for all BIER neighbors that can find an underlay LFA. The neighbor BFR label is pushed first. Use the following command to enable BIER FRR.

configure router bier fast-reroute

Use the following command to display BIER routing information for the sub-domain.

show router bier routing sub-domain 0

In the following output example, next-hop 10.20.1.4 is protected through 10.20.1.2 using a basic LFA.

===============================================================================
Destination Prefix                          Bfr-ID          Age
  Neighbor
    Nexthop
    Interface
-------------------------------------------------------------------------------
===============================================================================
BIER Routing Database Sub-Domain 0 BSL 256
===============================================================================
    10.20.1.1                                   1               0d 01:17:21
      10.20.1.2 (Backup)
        10.180.3.2
        ip-10.180.3.3
      10.20.1.4
        10.180.11.4
        ip-10.180.11.4
 
    10.20.1.2                                   2               0d 01:17:21
      10.20.1.2
        10.180.3.2
        ip-10.180.3.3
      10.20.1.4 (Backup)
        10.180.11.4
        ip-10.180.11.4
 
    10.20.1.4                                   0               0d 01:17:21
      10.20.1.4
        10.180.11.4
        ip-10.180.11.3
===============================================================================
Total (Sub-Domain 0): 3
===============================================================================
Total BIER Routing entries : 3
===============================================================================

show router bier forwarding sub-domain 0

===============================================================================
  Neighbor
    Nexthop
    Interface
    [SI]: Label
       Forwarding Bit Mask
         BFR-ID : Prefix
-------------------------------------------------------------------------------

Each BIER domain can be divided into sub-domains. A BIER domain supports sub-domains numbered from 0 to 255. Each BIER domain must contain at least one sub-domain, and sub-domain 0 is the default. If a BIER domain contains more than one sub-domain, each BFR in the domain must be provisioned with the set of sub-domains to which it belongs.

A BIER domain is an IGP area, and sub-domains are the different topologies within that area. In IS-IS and OSPF, each topology must also have its own sub-domain ID. For example, in IS-IS a sub-domain is an IS-IS multitopology. SR OS supports two sub-domains in IS-IS: IPv4-multicast and IPv4-unicast MTs. A sub-domain creates the least traffic engineering in a BIER domain. A user can use separate L3 interfaces into IPv4-unicast MT and a set of disjointed interfaces into the IPv4-multicast MT. This creates separation and traffic engineering for different multicast streams.

For each sub-domain to which a specific BFR belongs, if the BFR is capable of acting as a BFIR or a BFER, it must be provisioned with a BFR ID that is unique within the sub-domain. If a given BFR belongs to more than one sub-domain, it may have a different BFR ID for each sub-domain but this is not required.

To increase scalability of BIT String Length (BSL), routers can be grouped into BIER sets.

The BSL dictates how many BFRs can be represented in a BIER set. Each BIER set can contain as many routers as the length of BSL, and it is represented by a BIER Set ID (SI). The Set ID is part of the packet and represented as <SI:Bit Position>. BIER set shows an example set with a BSL of 4.

The BFR ID is programmed into <SI, Bit Position> based on the network BSL.

SI = (BFR-ID – 1)/BSL

BP = ((BFR-ID – 1) mod BSL)+1

For example: BSL 4 and BFR-ID 6 = <SI=1, BP=2>.

BIER works well in an IP TV deployment where the network is in a spine and leaf deployment. SR OS supports 16 set IDs in this type of deployment where there is no packet duplication at the spine.

• The SHO can be connected to as many as 16 VHOs.

• Each tree can have 256 LEAFs without packet duplication.

• Each leaf can have as many hosts on it as the number of supported IGMP/MLD hosts.

SR OS supports BIER MPLS encapsulation.

A BIER forwarding table is built based on the combination of:

• Set ID (SI)

• BIER String Length (BSL)

• Sub Domain (SD)

and saved in the format <SD, BSL, SI>. BIER forwarding tables shows an example of how forwarding tables are built.

For example, if there are 2 SDs and there are 256 PEs in each SD, there are two forwarding tables, one for each SD. One for <SD=0, BSL=256, SI=0> and the other for <SD=1, BSL=256, SI=0>.

Similarly, if there are 512 PEs in an SD and the BSL is 256, there are two forwarding tables, one for <SD=0, BSL=256, SI=0> and the other for <SD=0, BSL=256, SI=1>.

An MPLS label is assigned locally for each BIER routing table, and advertised.

BFRs establish BIER adjacencies through IS-IS and exchange their BFR prefixes and BIER IDs as well as transport-related information. IS-IS can be used to exchange the information. BIER IGP sub-TLV shows the IS-IS extensions for BIER and BIER MPLS sub-sub-TLV shows a BIER MPLS sub-sub-TLV.

In IS-IS, a new BIER sub-TLV is advertised as part of extended prefix opaque LSA carrying the BFR IP address (loopback) and supported BIER bitmask length for this BFR (multiple TLVs are used to convey support for multiple bitmask lengths). In addition, when MPLS encapsulation is used, a BIER MPLS encapsulation sub-TLV is included that contains the label range used for BIER. The label ranges advertised within the area are unique to a BFR and are used to identify the BIER forwarding context.

Based on the information exchanged, IGP creates a BIER routing table (unicast SPF) to reach each BFER that can be used to route BIER packets. The routing table specifies the shortest unicast path to reach each BFER through (BFERs bitmask, next-hop BFR)-tuples.

BIER sub-TLVs having the wrong length or illegal encoding are ignored and no error is raised. All other sub-TLV or sub-sub-TLV validation is done by the BIER module.

IS-IS supports multiple levels and BIER is supported under each level using the following rules:

• If the ABR is not a BFIR or BFER, the BIER sub-TLV must be leaked between different levels (areas) at the ABR. A BIER template without a BFR ID must be on both levels.

• The ABR can support BFIR and BFER functionality. ABR does not support BIER header stitching.

• A single area can have level 1 and level 2. In this case, the same template can be programmed on both levels.

IS-IS supports multitopologies (MT), such as ipv4-unicast, ipv4-multicast, ipv6-unicast, and ipv6-multicast. SR OS supports ipv4-unicast and ipv4-multicast MTs for BIER.

A sub-domain is supported within only one topology. The mapping is indicated by the pair <MT, SD>.

For example, the following combination of <MT, SD>, where MT 0 is IPv4 unicast and MT 3 is IPv4 multicast, are valid:

<MT=0, SD=0>

<MT=0, SD =1>

<MT=0, SD =2>

However, the following combination, where MT 0 is IPv4 unicast and MT 3 is IPv4 multicast, is invalid because an SD belongs to more than one MT:

<MT=0, SD=0>

<MT=3, SD=0>

IPv4-multicast imports routes into the multicast RTM and ipv4-unicast imports routes into the unicast RTM.

A BIER forwarding table (BIFT) is identified using a label. A BIER label is assigned per (<MT, SD>, SI, BSL) and therefore, different MTs point to different BIFTs.

The MT can be used to engineer multicast and BIER routes separately from unicast routes.

For intra-AS solutions, ensure that the ABR loopback interface used as the BIER prefix is included in both Level 1 and Level 2, otherwise the BIER prefix is not resolved at the level into which the route was leaked.

Nokia recommends having the loopback interface used as the BIER prefix in Level1/Level2 for intra-AS solutions, which is the default configuration for SR OS.

SR OS supports the BIER TLV for OSPF. Each node uses the TLVs described in RFC 8444 to propagate the BIER information to the entire network. The peer nodes use this information to build their BIER Index forwarding table (BIFT).

OSPF does not support MT. Single BIER sub-domain per area is supported. Inside an area, BIER and virtual links are mutually exclusive.

configure router ospf area bier template

BIER forwarding shows that IGP builds the BIFT using IGP BIER TLVs. Each node also builds its LTN table based on IGP-advertised MPLS labels.

The BIER routing table is constructed based on the combination of:

• Set ID (SI)

• BIER String Length (BSL)

• Sub Domain (SD)

This information is presented as <SD, BSL, SI>. An MPLS label is assigned locally for each BIER routing table and is advertised using IGP to peers.

For example, if there are 512 PEs and the BSL is 256 there are two forwarding tables with each table having its own label as follows:

• <SD=0, BSL=256, SI=0> represented with a unique local label

• <SD=0, BSL = 256, SI=1> represented with a second unique local label

Each node is presented in the BIER header using its BFR-ID. It is recommended to assign the BFR-IDs sequentially and in a tight order for the PEs so that no bits in the BIER header remain unused.

After all BFRs forward their BIER information using IGP BIER TLV, each BFR builds its own BIER RIB and BIER FIB. In the BIER forwarding example, PE A is represented using BFR-ID 1 (0:0001) and PE B is represented using BFR-ID 2 (0:0010) and so on. Therefore, on BFR F, the routing table is built based on this information. In the BIER forwarding example, BFR A (0:0001) has a destination of A/32 and its neighbor also has a destination of A/32 because of it directly being attached to BFR F. BFR B (0:0010) has destination of B/32 but is reachable using BFR E.

Therefore, the routing table for each PE is built based on its BFR-ID, destination IP address and the direct neighbor which it is attached.

The FIB is built based on the summation of the routes in the RIB that have the same neighbor. In the BIER forwarding example, BFER B and C have the same neighbor/peer BFR E. As a result, their FIB entry is identical BFR-ID 2 (0:0010) Forwarding bit mask 0110 neighbor/peer E/32; where the forwarding bit mask is a summation of BFR-ID nodes B and C (bit 2 and 3).

BIER MVPN uses MP-BGP as an overlay to signal MVPN. It uses RFC 6514 the same way P2MP RSVP-TE.

BIER MVPN introduces a new tunnel type of BIER (0x0B).

BIER PMSI replaces PIM, mLDP, and RSVP-TE P2MP in the core. There is no PMSI per (C-S, C-G), PMSI is used to reach all PE nodes interested in the C-Flow.

The VC label represents the VRF. Within the VRF, the payload IP header (C-S,C-G) finds the OIF based on PIM, IGP, and MLD states.

When a root PE (BFIR) receives a multicast packet and determines that the packet needs to be forwarded to the appropriate BFERs, the source PE encapsulates the multicast packet in a BIER header as described in BIER encapsulation. The root PE adds the appropriate VC label advertised by MP-BGP and PTA and forwards it to the BIER domain.

BIER MVPN packet format shows the BIER MVPN packet format.

The original packet has a VC label identifying the VRF added first, then the packet (MPLS payload) is forwarded using BIER PMSI by adding a BIER header identifying the BFERs and BIER label learned using IGP from the next-hop router, as described in BIER forwarding. Finally, when the packet arrives on the BFER, the BIER label is stripped, the BIFT is used to identify whether the packet needs to be handled by a corresponding VRF (because the bit in the header corresponds to the BFER BFR-ID). The BFER strips the BIER header, uses the VC label to identify the VRF instance, strips the VC label, and forwards the packet according to the legacy multicast protocols configured on the SAPs of the MVPN (for example, PIM, IGMP, and MLD OIFs).

SR OS supports BIER as I-PMSI and S-PMSI. By default, all (C-S, C-G) are forwarded using I-PMSI. If a throughput threshold is configured in MVPN and that threshold is surpassed by a (C-S, C-G), then the traffic for that stream is switched from I-PMSI to S-PMSI. BIER uses standard NG-MVPN signaling for S-PMSI and uses leaf AD routes from the leaf PEs to set up S-PMSI to the corresponding leaf that is interested in a specific (C-S, C-G).

The following example shows a BIER MVPN configuration.

[ex:/configure service vprn "1" mvpn]
A:admin@node-2# info
    c-mcast-signaling bgp
    umh-selection hash-based
    auto-discovery {
        type bgp
    }
    vrf-target {
        unicast true
    }
    provider-tunnel {
        inclusive {
            bier {
                admin-state enable
                sub-domain 0
            }
        }
        selective {
            data-threshold {
                group-prefix 224.0.0.0/4 {
                    threshold 10
                }
            }
            bier {
                admin-state enable
                sub-domain 0
            }
        }
    } 

A:node-2>config>service>vprn>mvpn# info 
----------------------------------------------
        auto-discovery default
        c-mcast-signaling bgp
        umh-selection hash-based
        provider-tunnel
            inclusive
                bier
                    sub-domain 0
                    no shutdown
                exit
            exit
            selective
                bier
                    sub-domain 0
                    no shutdown
                exit
                data-threshold 224.0.0.0/4 10
            exit
        exit
        vrf-target unicast
        exit
----------------------------------------------