Segmented MVPN Using IP Lookup for BIER

When using BIER to transport an MVPN data packet through a BIER domain, an ingress PE functions as a BFIR (see ). The BFIR must determine the set of BFERs to which the packet needs to be delivered. This can be done through an explicit-tracking function using a LIR and/or LIR-pF flag in BGP MVPN routes, per the , , , , and . Using a LIR-pF Flag will bring some extra benefits, as [I-D.ietf-bier-mvpn] and [I-D.ietf-bess-mvpn-expl-track] have stated. But unfortunately, the LIR-pF explicit tracking for a segmented MVPN deployment is not allowed in the current draft [I-D.ietf-bier-mvpn], because the draft requires a per-flow upstream-assigned label to do the data-plane per-flow lookup on the segmentation point BFR. This document specifies an alternative of the control plane and data plane procedures that allow segmented MVPN using BIER in both segments. This allows the use of the more efficient LIR-pF explicit-tracking as the BIER overlay, with a slight change in the forwarding procedure of a segmentation point BFR by using IP lookup. This will bring some significant benefits to the segmented MVPN deployment, including: Getting a much better multicast join latency by eliminating the round trip interaction of S-PMSI AD routes and Leaf AD routes. Especially, the S-PMSI A-D routes may need a data-driven procedure to trigger, and make the multicast join latency even worse. Greatly reducing the number of S-PMSI A-D routes that BFIR and BFERs need to save. Consolidated forwarding procedure of IP lookup for every BIER Overlay functioning routers, such as BFIR, BFER, segmentation point BFR, and segmentation point BFR with BFER function.

Readers of this document are assumed to be familiar with the terminology and concepts of the documents listed as Normative References.

BIER is a stateless multicast forwarding by introducing a multicast-specific BIER header in the data plane. The maximal number of BFERs a packet can reach is limited by the bit string length of a BIER header. For a network with many routers in multiple IGP areas (typically an Inter-Area network), it may be more expected to use a segmented MVPN when deploying BIER than traditional MVPN. However, it is not allowed in the [I-D.ietf-bier-mvpn] to use a LIR-pF explicit-tracking when deploying a segmented MVPN. This will lead to a low efficiency of explicit-tracking, and cause a worse multicast join latency. Here we take a scenario of inter-area segmented MVPN with both segments using BIER as an example.

A BFIR is always needed to know the BFERs interested in a specific flow. This is a function of a BIER overlay defined in [RFC8279]. A segmentation point BFR in a segmented MVPN deployment, saying ABR, will play similar roles of both BFIR and BFER. It needs to do a disposition of a BIER Header, and then do an imposition of a new BIER Header. It requires the ABR router to maintain per-flow states, and especially, such per-flow states always include a set of BFERs who are intrested in a specific flow by using an explicit-tracking procedure. This behavior is completely different from a traditional segmented MVPN deployment, e.g, with both of the two segments using P2MP label switch. In a traditional segmented MVPN with both segments using P2MP label switch, it is expected to receive a MPLS packet and replicate to downstream routers after swap the MPLS Label. A lookup of IP packet is not expected. Also, in a traditional segmented MVPN deployment, an MPLS label represents a P-tunnel, which may carry one, many or even all multicast flow(s) of a VPN, so it is not always a per-flow state on the segmentation point router. In conclusion, the pattern of forwarding packets on segmentation points only by lookup of MPLS label mapped from multicast flow(s) is significantly unnecessary when BIER is introduced. Instead, doing a per-flow lookup of IP header on segmentation points is more efficient and consolidated.

In a scenario of Inter-area Segmented MVPN with both segments using BIER, the determination of the set of BFERs that need to receive the a specific multicast flow of (C-S1,C-G1) in each segment, can be obtained by using a LIR-pF flag. Suppose a topology of this:

) | ( BIER SD ) | ]]> PE1 is Ingress PE, and the area of { PE1 -- P1 -- ABR } is called an Ingress Area. PE2 is Egress PE, and the area of { ABR -- P2 -- PE2 } is called an Egress Area. The Ingress PE is configured to use a BIER tunnel type for a MVPN instance for the Ingress Area, and the ABR is configured to use a BIER tunnel type for the MVPN instance for the Egress Area. The Ingress PE originates a wildcard S-PMSI A-D route (C-*,C-*) and the PTA of that route has the following settings: The LIR-pF and LIR flags be set. The tunnel type be set to "BIER". A non-zero MPLS label be specified. ABR receives the S-PMSI A-D route from the Ingress PE, and re-advertises the route to the Egress PE, with a PTA type "BIER", and PTA flags of LIR and LIR-pF, and a new non-zero upstream-assigned MPLS label allocated by ABR per-VPN. Egress PE receives the S-PMSI A-D route from the ABR, and checks if it need to response with a Leaf A-D route to this S-PMSI A-D route using the process of the "match for reception" and "match for tracking" as defined in [I-D.bess-mvpn-expl-track]. In this example, for a C-flow of (C-S1, C-G1), the checking result of "matched for tracking" is the S-PMSI(C-*, C-*), and the checking result of "matched for reception" is also the S-PMSI(C-*, C-*). Egress PE will then send a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=PE2) to the ABR with a PTA flag LIR-pF, and a Leaf A-D route (RD, C-*, C-*, Root=PE1, Leaf=PE2) without a PTA flag LIR-pF. ABR then has an explicit-tracking result of a new per-flow information of (RD, C-S1, C-G1, Root=PE1) with Egress PE as its leaf or BFER. ABR's "matched for tracking" result to this flow(RD, C-S1, C-G1, PE1) will then be updated with a new record, and ABR then sends a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=ABR) to Ingress PE. Ingress PE then has an explicit-tracking result of a new per-flow information of (RD, C-S1, C-G1, Root=PE1) with ABR as its leaf or BFER. From this procedure description one can see that: The S-PMSI A-D(C-*, C-*) route is functioning as a per-VPN anchor of the upstream and the downstream(s), which can be called a BIER FEC in this document, saying BIER FEC(*,*). The Leaf A-D(S,G) routes are functioning as a per-flow anchor of the downstream(s) and the upstream, which are also BIER FECs accordingly, saying BIER FEC(S,G). The Tuple of (Root=PE1, RD) in S-PMSI (C-*, C-*) or Leaf AD(C-*, C-*) or Leaf AD(C-S, C-G) represents an VRF on the ABR implicitly. ABR knows the per-vpn infmation of a (Root=PE1, RD) tuple when receiving and re-advertising the S-PMSI A-D(*,*) route bound with a PTA, where: Inbound SD (InSD): in PTA of the received S-PMSI(*,*) route. Inbound VpnLabel (InVpnLabel): in PTA of the received S-PMSI(*,*) route. Inbound BfirId (InBfirId): in PTA of the received S-PMSI(*,*) route. Outbound SD(OutSD): in PTA of the re-advertised S-PMSI(*,*) route. Outbound VpnLabel (OutVpnLabel): in PTA of the re-advertised S-PMSI(*,*) route. Outbound BfirId (OutBfirId): in PTA of the re-advertised S-PMSI(*,*) route. ABR establishs a per-flow control-plane state accordingly like this: Per-flow upstream state, according to the Leaf A-D (C-S, C-G) route send to the Ingress PE: (PE1, RD, C-S1, C-G1, InSD, InBfirId, InVpnLabel). Per-flow downstream state(s), according to the Leaf A-D(C-S, C-G) route(s) received by the ABR from Egress PE(s): (PE1, RD, C-S1, C-G1, Leaf, OutSD, OutBfirId, OutVpnLabel). ABR knows the BIER Label(s) it allocated for InSD and OutSD, saying InBierLabel for InSD<X> and OutBierLabel for OutSD<Y>, and thus it can establish the per-flow forwarding state: Per-flow upstream forwarding state: (InBierLabel, InBfirId, InVpnLabel, C-S1, C-G1). Per-flow downstream(s) forwarding state: (InBierLabel, InBfirId, InVpnLabel, C-S1, C-G1, Leaf, OutBfirId, OutVpnLabel, OutBitString)

The Forwarding procedure of a segmentation point BFR is a combination of a deposition and a re-imposition of the whole BIER header and the upstream-assigned Vpn Label. One can think it as swapping of a series of fields like below: swapping the InBierLabel with an OutBierLabel. swapping the InBfirId with an OutBfirId. swapping the InVpnLabel with an OutVpnLabel. swapping the InBitString with an OutBitString. The key of a per-flow lookup on ABR is a tuple of (InBierLabel, InBfirId, InVpnLabel) and a tuple of (C-S1, C-G1), representing a VRF and a flow respectively. All the elements are from a BIER packet, and such an IP lookup can be seen the same as an MFIB lookup, if the (InBierLabel, InBfirId, InVpnLabel) tuple is mapped to a VRF locally on the ABR.

The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane.

No IANA allocation is required.

TBD.