All BFRs in a network are referred to as a BIER domain. A BIER domain can contain one or more sub-domains. Each sub-domain is identified by a sub-domain ID. All BFIRs and BFERs in a sub-domain are called BIER edge devices.

BFR ID

A BFR ID uniquely identifies a BIER edge device in a sub-domain. A transit BFR does not need to have a BFR ID.

BFR prefix

A BFR prefix is an IP address that uniquely identifies a BFR in a sub-domain. A BFR prefix must be routable in the sub-domain and can only be the IP address of a loopack interface.

Bit string

A bit string represents a set of BIER edge devices, with each bit corresponding to a BFR ID, starting from the rightmost position. The bit string length (BSL) refers to the number of bits in the bit string. A bit string with three bits can identify a maximum of three BIER edge devices. The BIER edge device with BFR ID is represented as 001.

Set identifier

When the number of BFR IDs is greater than the number of bits in the bit string, the bit string needs to be divided into sets identified by set identifiers (SI). For example, if the maximum BFR ID is 10 in a BIER sub-domain and the bit string length is 4, the bit string needs to be divided into three SIs (SI 0, SI 1, and SI 2). The maximum SI is (Maximum BFR ID–1)/BSL rounded down to the nearest integer.

Bit Index Routing Table

The Bit Index Routing Table (BIRT) is generated based on the BIER information ((sub-domain, BSL, and BFR ID) and routing informtion carried by IGP. The BIRT is used to guide the forwarding of BIER packets in a BIER sub-domain.

Forwarding Bit Mask

The Forwarding Bit Mask (F-BM) represents a set of edge nodes in a BIER sub-domain that are reachable through a BFR neighbor (BFR-NBR). The bit mask is obtained by taking the logical OR of the bit strings of all reachable edge nodes.

Bit Index Forwarding Table

The Bit Index Forwarding Table (BIFT) can guide the per-hop forwarding of multicast traffic in a BIER sub-domain.

The BIFT is used to map from the BFR ID of a BFER to the corresponding F-BM and BFR-NBR. Multiple BIFT can exist on a BFR. Each BIFT is identified by a combination of the BSL, SD, and SI).

Operating mechanism

The running mechanism of NG MVPN over G-BIER is as follows:

1. The multicast source-side PE first interacts with the receiver-side PE through BGP MVPN routes to identify which receiver-side PEs need to receive the multicast traffic.

2. The source-side PE and receiver-side PE exchange BIER information (BFR ID, Sub domain ID, BFR prefix) through the Intra-AS I-PMSI A-D Route, S-PMSI A-D Route, and Leaf A-D Route carried in BGP messages.

3. Multicast data is seamlessly transferred from the private to the public network when it travels from the CE to the PE through a compatible tunnel according to the PIM routing table. The source-side PE encapsulates the private network multicast data with a BIER header and sends it through the tunnel to the remote PE, which then restores it to a private network multicast message by stripping the label information.

4. When multicast traffic on the multicast source-side PE meets the conditions for selecting a switch-over tunnel, a selective tunnel is established. The private network multicast data encapsulating the BIER head is then transmitted through this selective tunnel.

BIER-based MVPN operation

BIER-based MVPN encapsulates multicast traffic in a private network and sends it to other nodes in the BIER sub domain.

The multicast source-side PE sends BGP MVPN routes to receiver-side PEs for establishing BIER tunnels. This process is similar to that of RSVP-TE-based MVPN and mLDP-based MVPN except that the Intra-AS I-PMSI A-D route, S-PMSI A-D route, and Leaf A-D route carry BIER information, including BFR ID, sub-domain ID, and BFR prefix. For more information about RSVP-TE-based MVPN and mLDP-based MVPN, see "Configuring RSVP-TE-based MVPN" and "Configuring mLDP-based MVPN."

After encapsulating the received private network multicast traffic with Bit String, the PE performs BIER forwarding for the traffic in the public network. For more information about BIER forwarding, see BIER Configuration Guide.

Similar to RSVP-TE-based MVPN and mLDP-based MVPN, in BIER-based MVPN mode, multicast packets of a VPN instance are seamlessly transmitted from a CE to the inclusive tunnel on the PE based on the PIM routing table. These packets are then transmitted to the remote PE through the inclusive tunnel. After receiving the packets, the remote PE decapsulates the packets to get the original private packets. The multicast source-side PE creates selective tunnels when multicast traffic that meets the tunnel switchover criterion arrives.

NOTE:

BIER supports multiple encapsulation types. The operation of different encapsulation types are similar, with different BIER header formats. For more information, see BIER configuration in BIER Configuration Guide.

‌

Inclusive tunnel establishment

As shown in Figure 1, the private network runs PIM, and the public network uses BIER. The inclusive tunnels are established as follows:

1. PE 1 sends an Intra-AS I-PMSI A-D route to PE 2 and PE 3. The route contains the following information:

¡ Route Target—Controls route transmission and receiving. It is configured as the export target of PE 1.

¡ PMSI Tunnel attribute—Transmits tunnel information, where the value for the Tunnel Type field is the BIER tunnel, and the field contains BIER information including Sub domain ID, BFR ID, and BFR prefix for PE 1.

2. Upon receiving the Intra-AS I-PMSI A-D route, PE 2 and PE 3 identify whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, the PEs accept the route and respond with a Leaf A-D route to PE 1. The route contains the following information:

¡ Route Target— Controls route transmission and receiving. It is configured as the export target of PE 2 or PE 3.

¡ PMSI Tunnel attribute—Transmits tunnel information, where the value for the Tunnel Type field is the BIER tunnel. This field contains information about the BFIRs and BFERs in the same sub domain as PE 1. The information is obtained by checking the BFR ID and BFR prefix configured in the local sub domain with an ID same as that in the Intra-AS I-PMSI A-D route sent by PE 1.

3. Upon receiving the Leaf A-D route, PE 1 identifies whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, PE 1 accept the route and marks PE 2 and PE 3 as members of the MVPN. At the same time, PE 1 obtains the SI based on the BFR ID in the route and the value of the BSL in the BIER sub domain. Then PE 1 combines information about all leaf nodes and generates the bit string to establish an inclusive tunnel.

Figure 1 Inclusive tunnel establishment

Selective tunnel establishment and tunnel switchover

BIER-based MVPN supports switchover from the inclusive tunnel to selective tunnels to off-load traffic for specific (S, G) entries from the inclusive tunnel. An MVPN can have multiple selective tunnels.

As shown in Figure 2, the process of selective tunnel creation and the tunnel switchover is as follows:

1. PE 1 sends an S-PMSI A-D route to PE 2 and PE 3. The route contains the following information:

¡ Route Target—Controls route transmission and receiving. It is configured as the export target of PE 1.

2. Upon receiving the S-PMSI A-D route, PE 2 and PE 3 identify whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, the PEs accept the route and if a downstream receiver exists, the two PEs respond with a Leaf A-D route to PE 1. The route contains the following information:

¡ Route Target— Controls route transmission and receiving. It is configured as the export target of PE 2 or PE 3.

¡ PMSI Tunnel attribute—Transmits tunnel information, where the value for the Tunnel Type field is the BIER tunnel. This field contains information about the BFIRs and BFERs in the same sub domain as PE 1. The information is obtained by checking the BFR ID and BFR prefix configured in the local sub domain with an ID the same as that in the S-PMSI A-D route sent by PE 1.

Figure 2 Selective tunnel establishment and tunnel switchover

‌

Control plane

In the NG MVPN over BIER scenario, BIER is used to establish a carrying tunnel. Multicast private network traffic is encapsulated by BIER and sent across the public network to other nodes in the BIER sub-domain.

The control plane package of NG MVPN over BIER includes the following unique technical implementations:

· Receiver PE collects information.

In this scenario, the multicast source-side PE first recognizes which receiver-side PEs the multicast traffic needs to be transmitted to. Then, the source-side PE encapsulates the Bit String based on the received private network multicast traffic. In this, the gathering mechanism of each PE member within MVPN is similar to the process under RSVP-TE and mLDP modes in MVPN.

· Added a new BIER tunnel type attribute.

To support NG MVPN over BIER, RFC 8556 defines the information required when using BIER tunnels in BGP MVPN services, namely, a BIER-type PTA (PMSI Tunnel attribute). This BIER-type PTA is used when BIER tunnels are employed in BGP MVPN services. Originally, the MPLS Label field of the PTA was used to identify the upstream allocation tags of the MVPN instance. In the MVPN based on BIER tunnels, this field is no longer used. Instead, a new BGP attribute carrying the IPv6 source address (multicast service source address, src-dt4, or src-dt6) used to identify the MVPN instance is used. This attribute is referred to as the multicast service identifier (MSID). For BIERv6 or MSR6, This attribute is referred to as Prefix-SID. The value of the MPLS label field in the PTA is set to 0.

MSID attributes

In MVPN over G-BIER, the newly added BGP attricute MSID is used to identify the MVPN-instance. The multicast source address within MSID is carried by the multicast source-side PE in the class 1 route 'Intra-AS I-PMSI A-D route', and is announced to the recipient-side PE. The recipient-side PE records the corresponding relationship between this source address and the MVPN-instance. When the recipient-side PE receives a multicast packet encapsulated in G-BIER, it will use the multicast source address in the packet to find the corresponding MVPN-instance, find the corresponding entry in the multicast forwarding table of the MVPN instance, and forward the multicast packet.

The BGP MSID attricutes and their content adhere to the format requirements defined by BGP attricutes, shown as Figure 3.

Figure 3 MSID Attribute Format

The meaning of each field in the MSID Attribute is as follows:

· Attribute Flags: 8 bits, identify (ID) attricutes.

· Attribute Type: 8bits, representing the category field of the attribute, named as MSID.

· Attribute Length: 16 bits, indicating the length of the attribute.

· Attribute Data: Variable length, representing the attribute data, expressed using a Sub-TLV with no fixed fields.

The Attribute Data is a Sub-TLV with no fixed fields, and its specific format is shown in Figure 4.

Figure 4 Sub-TLV format.

The meanings of each field in the Sub-TLV are as follows:

· Sub-TLV Type: 8 bits, indicating the type of the Sub-TLV.

· Sub-TLV Length: A 16-bit value representing the length of the Sub-TLV.

· Reserved: 8 bits, reserved field.

· IPv6 address: The source IPv6 address.

· sub-sub-TLV: Variable length, indicating the sub-sub-TLVs carried by this Sub-TLV, currently only supporting the Structure sub-sub-TLV.

The format of the Structure sub-sub-TLV is shown as in Figure 5.

Figure 5 Structure sub-sub-TLV format

The meanings of each field in the Structure sub-sub-TLV are as follows:

· sub-sub-TLV Type: 8 bits, the type of sub-sub-TLV, with a value of 1 indicating a Structure sub-sub-TLV.

· sub-sub-TLV Length: 16 bits, the length of the sub-sub-TLV, with a value of 5.

· Flags: 8 bits, a flag field for future expansion, currently required to be 0.

· Prefix Length: 8 bits, indicating the length of the prefix.

· The length of the multicast service ID, known as MSID Length, is 8 bits.

· Must Be Zero: 16bits, reserved field.

Prefix-SID attributes

In MVPN over BIERv6, the BGP attribute Prefix-SID is used to carry the IPv6 source address encapsulated by the BIERv6 tunnel. The multicast source-side PE advertises the tunnel source address to the receiver-side PE by carrying the Prefix-SID in Type 1 routes, Intra-AS I-PMSI A-D routes, and Type 3 routes, S-PMSI A-D routes. Upon receiving Type 1 and Type 3 routes, the receiver-side PE matches the Route Target attribute carried by the route with the local VPN instance or public network instance and records the relationship between the Prefix-SID and the VPN or public network instance. When the receiver-side PE receives a multicast packet encapsulated by BIERv6, it identifies the corresponding VPN or public network instance based on the BIERv6 tunnel source address in the packet, establishes multicast forwarding table entries in the corresponding MVPN instance, and forwards the multicast packet.

The BGP Prefix-SID attribute and its contents follow the format requirements defined by the RFC standard, as shown in Figure 6.

Figure 6 BGP Prefix-SID Format

The meanings of each field in the BGP Prefix-SID are as follows:

· TLV Type: This is the type of TLV. A value of 5 means that SRv6 carries a three-stratum service; a value of 6 means that SRv6 carries a two-stratum service.

· TLV Length: The length of the TLV.

· Reserved: Reserved field.

· SRv6 Service Sub-TLVs: The service information related to Prefix-SID, which is of variable length.

The SRv6 Service Sub-TLV package contains the following fields:

· Service Sub-TLV Type in SRv6: The type of Prefix-SID information is fixed at 1, indicating SRv6 SID Information Sub-TLV.

· SRv6 Service Sub-TLV Length: The length of the SRv6 Service Sub-TLV.

· SRv6 Service Sub-TLV Value: The value of the SRv6 Service Sub-TLV, which is variable in length.

When the type is SRv6 SID Information Sub-TLV, the SRv6 Service Sub-TLV includes the following fields:

· SRv6 Service Sub-TLV Type: The type of SRv6 Service Sub-TLV, with a fixed value of 1.

· SRv6 Service Sub-TLV Length: The length of the SRv6 SID Information Sub-TLV.

· Reserved1: A reserved field.

· SRv6 SID Value: The value of the Prefix-SID, representing the Src.DT4 SID and Src.DT6 SID for the BIERv6 tunnel source address, is carried by this field.

· SRv6 SID Flags: The flags for the Prefix-SID, with a fixed value of 0.}

· SRv6 Endpoint Behavior: The type of Prefix-SID. A value of 0x45 indicates a Src.DT4 SID, and 0x44 indicates a Src.DT6 SID.

· Reserved2: A reserved field.

MVPN extended community attributes

Introduction

MVPN's extended community attributes are primarily used for the advertisement and reception of C-multicast routes, including the following two types:

· The Source AS Extended Community attricute is used to identify the AS number where the multicast source is located, applicable in cross-domain scenarios.

· The VRF Route Import Extended Community attribute is used to identify the IP address of the multicast source-side PE and the VPN-instance where the multicast source is located.

The format of Source AS Extended Community and VRF Route Import Extended Community within the extended community attribute is depicted respectively in Figure 7 and Figure 8.

Figure 7 Format of the Source AS Extended Community

The Source AS Extended Community package includes the following fields:

· Type: The type of the extended community attribute, which can either be 0x00 (representing the extended community attribute of a 2-byte AS number type) OR 0x02 (representing the extended community attribute of a 4-byte AS number type).

· Sub-Type: The subtype of the extended community attribute, with a value of 0x09, indicating it is a Source AS Extended Community.

· Global Administrator: The AS number, where the multicast source is located, can be in either a 2-byte format or a 4-byte format.

· Local Administrator: Has a value of 0, currently without special meaning.

Figure 8 Format of the VRF Route Import Extended Community

The VRF Route Import Extended Community includes the following fields:

· Type: The type of the extended community attribute, with a value of 0x01 (for IPv4 address type extended community attribute) or no value (for IPv6 address type extended community attribute).

· Sub-Type: The subtype of the extended community attribute, with a value of 0x0b (when it's an IPv4 address type extended community attribute) or 0x000b (when it's an IPv6 address type extended community attribute), indicating it is a VRF Route Import Extended Community.

· IPv4/IPv6 address: The IP address of the multicast source-side PE.

· Local Administrator: The VPN instance where the multicast source is located.

Operating mechanism

As shown in Figure 9, PE 1 and PE 2 are multicast source PEs, while PE 3 is a receiving-side PE. Both PE 1 and PE 2 are connected to VPN 1 and the public network instance sites. On PE 1, the VRF Route Import Extended Community value for VPN 1 is 1.1.1.1:1; for the public network instance on PE 1, the value is 1.1.1.1:0 (the Local Administrator value in the VRF Route Import Extended Community for the public network instance must be 0); the Source AS Extended Community value on PE 1 is 10:0. On PE 2, the VRF Route Import Extended Community value for VPN 1 is 2.2.2.2:1; for the public network instance on PE 2, the value is 2.2.2.2:0 (the Local Administrator value in the VRF Route Import Extended Community for the public network instance must be 0); the Source AS Extended Community value on PE 2 is 10:0.

Figure 9 MVPN extended community attributes working mechanism

After establishing BGP MVPN address family sessions with PE 3 respectively, both PE 1 and PE 2 will release unicast route information to the multicast source to PE 3. The multicast source unicast route information of VPN-instance is carried via BGP VPNv4 or VPNv6 routes. The public network instance's multicast source unicast route information is carried via BGP IPv4/IPv6 unicast routes OR BGP IPv4/IPv6 multicast routes. All BGP routes carrying the announced unicast route information to the multicast source will include Source AS Extended Community and VRF Route Import Extended Community.

Upon receiving the BGP routes of unicast routing information to multicast sources announced by PE 3, PE 3 will prefer the BGP routes, then store the Source AS Extended Community and VRF Route Import Extended Community carried by the routes for later construction of the C-multicast route. It is assumed in this instance that PE 3 has preferred the BGP route of the unicast routing information to the multicast source of VPN 1 announced by PE 1, and the BGP route of the unicast routing information to a multicast source of a public network instance announced by PE 2.

The construction process of C-multicast routing for VPN-instance VPN 1 and public network instance is as follows:

· When PE 3 receives a multicast join message from CE 3, it constructs a C-multicast route, and then transmits it to PE 1 and PE 2. The Source AS field of this route is the AS number in the received Source AS Extended Community. The Route Target attricutes carried by the route is the VRF Route Import Extended Community of the preferred BGP route, which is 1.1.1.1:1.

¡ Upon receiving the C-multicast routing, PE 1 compares the IP address carried in the RT attricutes of the C-multicast routing and discovers it is 1.1.1.1, which is the local source interface address. So, PE 1 accepts the C-multicast routing. Then, PE 1 determines the C-multicast routing belongs to VPN-instance VPN 1 based on the Local Administrator in the RT attricutes and adds the C-multicast routing to the multicast routing table of VPN 1.

¡ Upon receiving the C-multicast route, PE 2 compares the IP address carried in the RT attribute of the C-multicast route, identifies it as 1.1.1.1, which is not the local source interface address, and discards the C-multicast route.

When the multicast source in VPN 1 sends multicast packets subsequently, as only PE 1 has formed the multicast entry, the multicast packets will be encapsulated by BIER at PE 1 and transmitted through the BIER public network tunnel to PE 3. After decapsulation at PE 3, they are forwarded to CE 3.

· When PE 3 receives a multicast join message from CE 4, it constructs a C-multicast route and then sends it to PE 1 and PE 2. The Source AS field of this route is the AS number from the received Source AS Extended Community, and the Route Target attricutes it carries are the VRF Route Import Extended Community of the preferred BGP route, which is 2.2.2.2:0.

¡ Upon receiving the C-multicast route, PE 2 compares the IP address in the RT attribute of the route, recognizes it as 2.2.2.2, which is the local source interface address, and accepts the C-multicast route. Then, PE 2 uses the Local Administrator in the RT attribute to determine that the C-multicast route belongs to the public network instance and adds the route to the multicast routing table of the public network instance.

¡ Upon receiving the C-multicast route, PE 1 compares the IP address carried in the RT attricutes of the C-multicast route and finds out that it is 2.2.2.2, not the local source interface address, thus discards the C-multicast route.

When the multicast source in the public network instance subsequently transmits multicast packets, since only PE 2 forms the multicast entry, the multicast packets will be encapsulated in BIER at PE 2, and then transmitted to PE 3 through the BIER public network tunnel. After decapsulation on PE 3, the packets are forwarded to CE 4.

Inter-AS BIER-based MVPN

In an inter-AS VPN networking scenario, VPN sites are located in multiple ASs. These sites must be interconnected. Inter-AS VPN provides the following solutions:

· VRF-to-VRF connections between ASBRs—This solution is also called inter-AS option A.

· EBGP redistribution of labeled VPN-IPv4 routes between ASBRs—ASBRs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-AS option B.

· Multihop EBGP redistribution of labeled VPN-IPv4 routes between PE devices—PEs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-AS option C.

For more information about the three inter-AS VPN solutions, see MPLS L3VPN configuration in MPLS Configuration Guide.

Inter-AS option A BIER-based MVPN

As shown in Figure 10:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through their respective VPN instance and treat each other as a CE.

Figure 10 Inter-AS option A BIER-based MVPN

To implement inter-AS option A mLDP-based MVPN, a separate MVPN must be created in each AS. Multicast data of the VPN instance is transmitted across the ASs through the separate MVPNs in each AS.

Multicast packets of the VPN instance are delivered as follows:

1. CE 1 forwards a multicast packet of VPN instance 1 to PE 1.

2. PE 1 encapsulates the multicast packet into an MPLS packet and forwards it to PE 3 through BIER tunnel 1.

3. PE 3 considers PE 4 as a CE of MVPN 1, so PE 3 decapsulates the MPLS packet and forwards the multicast packet to PE 4.

4. PE 4 considers PE 2 as a CE of MVPN 2, so PE 4 encapsulates the multicast packet into an MPLS packet and then forwards the packet to PE 2 through BIER tunnel 2.

5. PE 2 decapsulates the MPLS packet and then forwards the multicast packet to CE 2.

In inter-AS option A, PEs in different ASs cannot advertise Source Active A-D routes to each other. Therefore, you must configure MSDP or Anycast-RP between RPs to allow Source Active A-D routes to be advertised across ASs.

Inter-AS option C BIER-based MVPN

Only G-BIER and MSR6 support Inter-AS option C BIER-based MVPN.

As shown in Figure 11:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are the ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PEs in different ASs establish a multihop MP-EBGP session to advertise VPN-IPv4 routes to each other.

Figure 11 Inter-AS option C BIER-based MVPN

To implement inter-AS option C mLDP-based MVPN, only one MVPN needs to be created cross all ASs. Multicast data is transmitted across the ASs through this MVPN.

Multicast packets of the VPN instance are delivered as follows:

1. Upon receiving a multicast packet of a multicast group in the VPN instance, CE 1 advertises the RP information for this group to PE 1 as follows:

¡ If the RP is PE 1, CE 1 directly sends a register message to PE 1 to advertise the RP information.

¡ If the RP is CE 1 or CE 2, CE 1 advertises the RP information to PE 1 through MSDP or Anycast-RP depending on the actual configuration.

2. PE 1 sends a source-active A-D route to PE 2 through BGP.

3. PE 2 sends a C-multicast route to join the multicast group if it has a receiver attached. The C-multicast route will be advertised to PE 1 through BGP.

4. PE 1 encapsulates the multicast packet into an MPLS packet and then sends the packet to PE 2 through the BIER tunnel.

5. PE 2 decapsulates the MPLS packet and then sends the multicast packet to CE 2.

Protocols and standards

· RFC 8279, Multicast Using Bit Index Explicit Replication (BIER)

· RFC 8296, Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks

· RFC 8401, Bit Index Explicit Replication (BIER) Support via IS-IS

· RFC 8444, OSPFv2 Extensions for Bit Index Explicit Replication (BIER)

· RFC 8556, Multicast VPN Using Bit Index Explicit Replication

· RFC9272, Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)

· draft-xie-bier-ipv6-encapsulation

· draft-cheng-msr6-design-consideration

· draft-lx-msr6-rgb-segment

BIER-based MVPN tasks at a glance

To configure BIER-based MVPN, perform the following tasks on PEs:

1. Enabling IP multicast routing for a VPN instance

2. Configuring BGP MVPN route exchange

¡ Configuring BGP IPv4 MVPN route exchange

¡ Configuring BGP IPv6 MVPN route exchange

3. Configuring BGP extended communities

¡ Allowing the device to add community attributes to C-multicast routes sent to BGP peers

¡ Enabling compatibility for the extended communities of the IPv6 address type

4. Creating a BIER-based MVPN instance

5. Creating an MVPN IPv4 address family

6. Specifying the MVPN source interface

7. Enabling IPv6 underlay for MVPN

8. Configuring source IPv6 addresses for encapsulation

¡ Configuring G-BIER multicast service prefix information

¡ Specifying the multicast service source address

¡ Configuring the source address of the BIERv6 or MSR6 tunnel

9. Configuring inclusive tunnels and selective tunnels

¡ Enabling inclusive tunnel creation

¡ (Optional.) Enabling selective tunnel creation

¡ (Optional.) Setting the tunnel holddown timer

10. (Optional.) Enabling inter-AS auto-discovery

11. (Optional.) Configuring BIER FRR

12. (Optional.) Configuring multicast warm backup

¡ Enabling multicast warm backup

13. (Optional.) Configuring the selection of the master IDF based on (S, G) entries

Prerequisites for configuring BIER-based MVPN

Before you configure BIER-based MVPN, complete the following tasks:

· Configure a unicast routing protocol on the public network.

· Configure MPLS LDP or SRv6 on the public network.

· Configure BIER on the public network.

· Configure BGP to enable PEs to mutually establish neighbor relationship.

Enabling IP multicast routing for a VPN instance

Restrictions and guidelines

For a multi-VPN instance scenario, you must configure different route targets for each VPN instance.

Procedure

1. Enter system view.

system-view

2. Create a VPN instance and enter its view.

ip vpn-instance vpn-instance-name

For more information about this command, see MPLS L3VPN commands in MPLS Command Reference.

3. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

For more information about this command, see MPLS L3VPN commands in MPLS Command Reference.

4. Configure route targets for the VPN instance.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

For more information about this command, see MPLS L3VPN commands in MPLS Command Reference.

5. Return to system view.

quit

6. Enter interface view.

interface interface-type interface-number

7. Associate the interface with the VPN instance.

ip binding vpn-instance vpn-instance-name

By default, an interface is associated with no VPN instance and belongs to the public network.

For more information about this command, see MPLS L3VPN commands in MPLS Command Reference.

8. Return to system view.

quit

9. Enable IP multicast routing for the VPN instance and enter MRIB view of the VPN instance.

IPv4:

multicast routing vpn-instance vpn-instance-name

By default, IP multicast routing is disabled for a VPN instance.

For more information about the commands, see multicast routing and forwarding commands in IP Multicast Command Reference.

Configuring BGP MVPN route exchange

Configuring BGP IPv4 MVPN route exchange

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify a BGP MVPN peer and its AS number.

peer ipv6-address as-number as-number

4. Enter BGP IPv4 MVPN address family view.

address-family ipv4 mvpn

5. Enable BGP to exchange IPv4 unicast routing information with BGP peers.

peer ipv6-address enable

By default, BGP cannot exchange IPv4 unicast routing information with BGP peers.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

6. (Optional.) Specify the maximum number of routes that a router can receive from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-limit prefix-number [ { alert-only | discard | reconnect reconnect-time } | percentage-value ] *

By default, the number of routes that a router can receive from a peer or peer group is not limited.

7. (Optional.) Configure the BGP Additional Paths feature.

a. Configure the BGP Additional Paths capabilities.

peer { group-name | ipv6-address [ prefix-length ] } additional-paths { receive | send } *

By default, no BGP Additional Paths capabilities are configured

b. Set the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } advertise additional-paths best number

By default, a maximum number of one Add-Path optimal route can be advertised to a peer or peer group.

c. Set the maximum number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number

By default, a maximum number of one Add-Path optimal route can be advertised to all peers.

For more information about the commands in this step, see BGP commands in Layer 3—IP Routing Command Reference.

8. (Optional.) Advertise the COMMUNITY or Large Community attribute to a peer or peer group.

¡ Advertise the COMMUNITY attribute to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } advertise-community

By default, the COMMUNITY attribute advertisement to a peer or peer group is disabled.

¡ Advertise the Large Community attribute to a peer or peer group.

peer { group-name | ipv6-address [ prefix-length ] } advertise-large-community

By default, the Large Community attribute advertisement to a peer or peer group is disabled.

For more information about the commands in this step, see BGP commands in Layer 3—IP Routing Command Reference.

9. (Optional.) Disable route target filtering of received BGP IPv4 MVPN routes.

undo policy vpn-target

By default, a PE device filters route targets for received BGP IPv4 MVPN routes.

10. (Optional.) Set the optimal route selection delay timer.

route-select delay delay-value

By default, the optimal route selection delay timer is 0 seconds, which means optimal route selection is not delayed.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

11. Prefer routes learned from the specified peer or peer group during optimal route selection.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } high-priority

By default, BGP does not prefer routes learned from any peer or peer groups during optimal route selection.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

Configuring BGP IPv6 MVPN route exchange

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify a BGP MVPN peer and its AS number.

peer ipv6-address as-number as-number

4. Enter BGP IPv6 MVPN address family view.

address-family ipv6 mvpn

5. Enable BGP to exchange IPv6 unicast routing information with dynamic BGP peers.

peer ipv6-address enable

By default, BGP cannot exchange IPv6 unicast routing information with dynamic BGP peers.