The Overlay helps determine interested multicast sources and listeners in the BIER domain. The Overlay can be MVPN, EVPN, or Global IP Multicast. BIER on PTX10002-36QDD supports MVPN as the Overlay in Junos 23.4R2 release.
MVPN can use P2MP tunnels created by RSVP-TE, mLDP, or PIM to transport customer multicast traffic across the provider's backbone network. P2MP tunnels in "aggregate tunnel mode" allocate an "upstream-assigned MPLS label" for each VPN and each packet sent on this P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's VPN.
The upstream-assigned label procedures can result in scaling problems, as each PE allocates a label from its own label space. A detailed analysis is captured in the mvpn-evpn-aggregation-label draft. BIER implementation on PTX10002-36QDD follows the optimized approach mentioned in the above draft to solve all scaling issues. Here, the labels are allocated in the provider network by a central entity. All PEs use the same label to represent a VPN.
The BIER sub-domain got mapped to MVPN VPN instance as shown in the output below:
R1 acts as the BFIR router where the multicast source is present. As shown below, the down-stream OIF is the Pseudo-MVPN interface corresponding to the BIER tunnel and IIF is the directly connected interface from which the multicast data is sourced.
Through the type-1 routes, the peering routers PEs or BFIR/BFER advertise their PMSI characteristics including VPN label, subdomain id, and bfr-id.
Let's analyze the routes advt. by the source PE for the VPN customer. As shown below, at the receiver PE, R4, it received the VPN information from the source PE, R1 with VPN label as 990001, Sub Domain 100, BFR-ID 1.
regress@r4-sb-bier-RE0> show route receive-protocol bgp 11.1.1.2 table bgp.mvpn.0
Warning: License key missing; requires 'BGP' license
bgp.mvpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
1:11.1.1.1:1:11.1.1.1/240
* 11.1.1.1 100 I
1:11.1.1.5:1:11.1.1.5/240
* 11.1.1.5 100 I
1:11.1.1.6:1:11.1.1.6/240
* 11.1.1.6 100 I
1:11.1.1.7:1:11.1.1.7/240
* 11.1.1.7 100 I
regress@r4-sb-bier-RE0>
regress@r4-sb-bier-RE0> show route receive-protocol bgp 11.1.1.2 table bgp.mvpn.0 match-prefix 1:11.1.1.1:1:11.1.1.1/240 extensive
Warning: License key missing; requires 'BGP' license
bgp.mvpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
* 1:11.1.1.1:1:11.1.1.1/240 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 11.1.1.1:1
Nexthop: 11.1.1.1
Localpref: 100
AS path: I (Originator)
Cluster list: 11.1.1.2
Originator ID: 11.1.1.1
Communities: target:64512:1
PMSI: Flags 0x0: Label 990001: Type BIER 11.1.1.1 100 1
regress@r4-sb-bier-RE0>
regress@r4-sb-bier-RE0> show route table bgp.mvpn.0 match-prefix 1:11.1.1.1:1:11.1.1.1/240 extensive
bgp.mvpn.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
1:11.1.1.1:1:11.1.1.1/240 (1 entry, 0 announced)
*BGP Preference: 170/-101
PMSI: Flags 0x0: Label 990001: Type BIER 11.1.1.1 100 1
Next hop type: Indirect, Next hop index: 0
Address: 0x55cf71960a5c
Next-hop reference count: 12
Kernel Table Id: 0
Source: 11.1.1.2
Protocol next hop: 11.1.1.1
Indirect next hop: 0x2 no-forward INH Session ID: 0
Indirect next hop: INH non-key opaque: (nil) INH key opaque: (nil)
State: <Active Int Ext>
Local AS: 64512 Peer AS: 64512
Age: 2d 17:54:26 Metric2: 1
Validation State: unverified
Task: BGP_64512.11.1.1.2
AS path: I (Originator)
Cluster list: 11.1.1.2
Originator ID: 11.1.1.1
Communities: target:64512:1
Import Accepted
Localpref: 100
Router ID: 11.1.1.2
Secondary Tables: m_customer_A.mvpn.0
Thread: junos-main
Indirect next hops: 1
Protocol next hop: 11.1.1.1 Metric: 1 ResolvState: Resolved
Indirect next hop: 0x2 no-forward INH Session ID: 0
Indirect next hop: INH non-key opaque: (nil) INH key opaque: (nil)
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 12.1.4.1 via et-0/0/9.0
Session Id: 3
Statistics ID Group: Kernel ID = 4123, Stats IDs = { 805306391 }
11.1.1.1/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Next hop type: Router
Next hop: 12.1.4.1 via et-0/0/9.0
Session Id: 3
Statistics ID Group: Kernel ID = 4123, Stats IDs = { 805306391 }
regress@r4-sb-bier-RE0>
On receiving this information at the receiver PE, R4, it adds the label to the mpls.0. When it receives a packet with VPN label of 990001, it will send it to the tunnel ifl lsi.0 after popping the label.
regress@r1-sb-bier-RE0> show route 11.1.1.4 table inet.3
inet.3: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
11.1.1.4/32 *[LDP/9] 21:23:57, metric 1
> to 12.1.1.2 via et-0/0/9.0, Push 22
regress@r1-sb-bier-RE0>
This implies that, for the BGP MVPN peering to work, we need label exchange protocols like LDP, RSVP, and SR in the core. In our case, we enabled LDP, which provides the labels to inet.3, which BGP uses for resolution.
Note: For the BIER domain to work, the labels are advertised by the IGP underlay (ISIS). The overlay (MVPN) depends on the labeling protocol LDP, RSVP, or SR.
regress@r1-sb-bier-RE0> show route table m_customer_A.mvpn.0 match-prefix 7:11.1.1.1:1:64512:32:13.1.1.2:32:232.1.1.1/240
m_customer_A.mvpn.0: 6 destinations, 7 routes (6 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
7:11.1.1.1:1:64512:32:13.1.1.2:32:232.1.1.1/240
*[PIM/105] 21:04:33, metric 0
Multicast (IPv4) Composite
[BGP/170] 21:04:33, MED 0, localpref 100, from 11.1.1.2
AS path: I, validation-state: unverified
> to 12.1.1.2 via et-0/0/9.0
regress@r1-sb-bier-RE0>
regress@r1-sb-bier-RE0> show mvpn instance inet
MVPN instance:
Legend for neighbor state (St)
A- Preferred upstream neighbor for inter-AS
Legend for provider tunnel
S- Selective provider tunnel
F- Flood NH forwarding NH
M- Multicast Composite NH
C- Cloned NH
Legend for c-multicast routes properties (St)
DS -- derived from (*, c-g) RM -- remote VPN route
I -- Inactive
Family : INET
Instance : m_customer_A
MVPN Mode : SPT-ONLY
Sender-Based RPF: Disabled. Reason: Not enabled by configuration.
Hot Root Standby: Disabled. Reason: Not enabled by configuration.
Provider tunnel: I-P-tnl:BIER: subdomain-id 100 bfr-id 1 label 990001
Neighbor Inclusive Provider Tunnel Label-In St Segment
11.1.1.4 BIER: subdomain-id 100 bfr-id 4 bier-prefix 11.1.1.4 990001
11.1.1.5 BIER: subdomain-id 100 bfr-id 5 bier-prefix 11.1.1.5 990001
11.1.1.6 BIER: subdomain-id 100 bfr-id 6 bier-prefix 11.1.1.6 990001
11.1.1.7 BIER: subdomain-id 100 bfr-id 7 bier-prefix 11.1.1.7 990001
C-mcast IPv4 (S:G) Provider Tunnel Label-In St FwdNh Segment
13.1.1.2/32:232.1.1.1/32 BIER: subdomain-id 100 bfr-id 1 label 990001 RM M-8063
regress@r1-sb-bier-RE0>
As shown below at the BFIR, the multicast packet is encapsulated with a VPN label of 990001, the BIER BitString containing BFR-IDs of R4, R5, R6, and R7, and the BIER label of 16 which corresponds to the {ISIS Topology: Default, BIER Sub-Domain:100, Set:0}.
BIER carries the IPv6 multicast data over the Service Provider Core Network. In the below topology IPv6 Listeners sends MLD join from R1 and R7. The IPv6 multicast data stream is behind R4.
Figure 2: BIER IPv6 Multicast Flow
As shown below the IPv6 listener behind R7 sends MLD join for the SSM group ff3a::1
BIER includes the functionality provided by three layers:
The BIER underlay, in our case ISIS, gives the necessary information to create the BIER Routing Tables (BIRT) and BIER Forwarding Tables (BIFT) with information FBM (Forwarding Bit Mask) and BIER labels.
The BIER layer, states the encapsulation to pick and the various BSL (Bit string lengths) and Sets.
The BIER Overlay, in our case MVPN, the MVPN Overlay creates the bitstring to be appended to the multicast packet to be sent to the core from the IBGP MVPN peering with other PE routers of the core and builds either inclusive or selective tunnels. It also appends the correct VPN label for the destination VPN customers.
When the entire BFER falls into the same set, the multicast data replication is as follows. Here multicast source is behind R1 and multicast listeners are at R4, R5, R6 and R7
Figure 3: BIER Multicast Flow
Let's get the traffic stats at the BFIR R1. It shows 100pps packets sent toward R2 for the FBM
In the following example, the multicast source is behind R7 and listeners are behind R1, R4, R5, and R6 in different sets, we have four downstream tunnels.
The multicast route info from BFER perspective is as follows, per multicast VPN, there will be one lsi interface created and that will act as the upstream interface towards the source of the multicast stream.
