| Internet-Draft | PIM Signaling Through BIER Core | March 2025 |
| Bidgoli, et al. | Expires 4 September 2025 | [Page] |
Consider large networks deploying traditional PIM multicast service. Typically, each portion of these large networks have their own mandates and requirements. It might be desirable to deploy BIER technology in some part of these networks to replace traditional PIM services. In such cases downstream PIM states need to be signaled over the BIER Domain toward the source.¶
This document specifies the procedures to signal PIM Join and Prune messages through a BIER Domain using [RFC9739] , enabling the provisioning of traditional PIM services through a BIER Domain. These procedures are valid for forwarding PIM Join/Prune messages to the Source (SSM) or Rendezvous Point (ASM).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
It might be desirable to simplify/upgrade some part of an existing multicast network to BIER technology, replacing existing legacy multicast protocols like PIM. This replacement of protocols should be done with minimum interruption or disruption to the other parts of the network. This document specifies procedures for signaling multicast Join and Prune messages over the BIER domain using [RFC9739]. The portion of the network that still is using legacy PIM protocol can be terminated at BIER edge routers and only PIM Join/Prune signaling messages are transported over the BIER network as per [RFC9739]. These signaling messages are forwarded upstream through the BIER network and toward the BIER edge routers on path to the Source or Rendezvous point.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
An understanding of the BIER architecture [RFC8279] and the related terminology is expected. The following are some of the new definitions used in this document.¶
BBR:¶
BIER Boundary router. A router between the PIM domain and BIER domain. Maintains PIM adjacency for all routers attached to it on the PIM domain and terminates the PIM adjacency toward the BIER domain.¶
IBBR:¶
Ingress BIER Boundary Router. An ingress router from signaling point of view. It maintains PIM adjacency toward the PIM domain and signals Join/Prune messages across the BIER domain to EBBR as needed.¶
EBBR:¶
Egress BIER Boundary Router. An egress router in BIER domain from signaling point of view. It maintains PIM adjacency to all upstream PIM routers. It terminates the BIER signaling packets and creates necessary PIM Join/Prune messages into PIM Domain.¶
BBR BBR b
|--PIM Domain--|-----BIER domain-----|--PIM domain--|
S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h
EBBR IBBR
Sig <-----PIM-----|<------PIM-Light-----|<----PIM------
(new) BIER-Tunneling
BFIR BFER
------------->|--------BIER-------->|-------------> Datapath
(no change)
Figure 1 illustrates the operation of the BIER Boundary router (BBR). BBRs are connected to PIM routers toward the PIM domain and BIER routers toward the BIER domain. PIM routers in PIM domain continue to send PIM state messages to the BBR. The BBRs will create a PIM Light Interface (PLI) between each other. PLI is defined in [RFC9739]. This PLI can be created via configuration or automatically and it will be used to forward the PIM Join/Prune messages between the PIM domains. Each BBR determines the Join or Prune message needs to be transmitted via the PLI through the BIER domain. The PLI packets are transmitted between BBRs with BIER header and is tunneled through the BIER domain as it is explained in upcoming sections.¶
The terminology ingress BBR (IBBR) and egress BBR (EBBR) is relative only from a signaling point of view.¶
The egress BBR will determine if the arriving BIER packet is a PIM Light signaling packet and if so it will generate a PIM Join/Prune packet toward its attached PIM domain.¶
The new procedures in this document are only applicable to signaling and there are no changes from datapath point of view.¶
The IBBR maintains a PIM adjacency [RFC7761] with any PIM router attached to it on the PIM domain.¶
When a PIM Join or Prune message is received, the IBBR determines whether the Source or the Rendezvous Point (RP) is reachable through the BIER domain. The EBBR is the BBR through which the Source of the Multicast stream or RP is reachable. In PIM terms [RFC7761], the EBBR is the RPF Neighbor, and the RPF Interface is the BIER "tunnel" used to reach it. The mechanisms used to find the EBBR are outside the scope of this document and there can be many mechanism depending on if the Source of the Multicast stream or the RP are in same area or autonomous system (AS) or in different area or AS. Some examples are provided in Appendix A.¶
On the IBBR, If the lookup for Source of Multicast stream or RP results into multiple EBBRs, different IBBRs could choose different EBBRs for the same flow based on their local hashing algorithm. On downstream these EBBRs will send traffic to their corresponding IBBRs.¶
After discovering the EBBR and its BFR-id, the IBBR MUST use the BIER Information Vector (Section 3.1.1) which is a PIM Join/Prune Attribute type in the "Upstream Neighbor Address" field as specified in [RFC7887]. This Join/Prune Attribute type applies to all source and groups in the Join/Prune message. The EBBR uses this PIM Join/Prune attribute or the BIER header itself to obtain the necessary BIER information to build its multicast state. since EBBR and IBBR are using a PLI for signaling PIM J, as per [RFC9739] section 3.2.1 both BBRs MUST support this new Join Attribute as part of their PIM Light capabilities and MUST NOT discard the Join/Prune Attribute. The signaling packet, in this case a PIM Join/Prune message, is encapsulated in the BIER Header and forwarded through the BIER domain to the EBBR. The source address of the PIM packets MUST be set to IBBR local BFR-prefix. The destination address MUST be set to ALL-PIM-ROUTERS [RFC7761].¶
The IBBR will track all the PIM interfaces on the attached PIM domain which are interested in a certain (S,G). It creates multicast states for arriving Join messages from PIM domain, with incoming interface as BIER "tunnel" interface and outgoing interface as the PIM domain interface(s) on which PIM Join(s) were received on.¶
The new PIM Join/Prune Attribute " BIER Information Vector" is defined as follow based on [RFC7887]¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E|Attr_Type | Length | Addr Family | BIER info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
F bit: Transitive Attribute, as specified in [RFC7887]. MUST be set to zero as this attribute is always non-transitive. If EBBR receives this attribute type with the F bit set it must discard the Attribute.¶
E bit: End of Attributes, as specified in [RFC7887]¶
Attr_Type: TBD assign by IANA.¶
Length: Length of the value field, as specified in [RFC7887]. MUST be set to the length of the BIER Info field + 1. For IPv4 the length is 8, and 20 for IPv6. Incorrect length value compare to the Addr Family must be discarded.¶
Addr Family: PIM address family as specified in [RFC7761]. Unrecognized Address Family must be discarded.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IBBR Prefix IPv4 or IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-domain-id | BFR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BIER Info: IBBR's BFR-prefix (IPv4 or IPv6), sub-domain-id, BFR-id¶
The BIER header will be encoded with the BFR-id of the IBBR(with appropriate bit set in the BitString) and the PIM Light signaling packet is then encapsulated in the packet.¶
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BIFT-id | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Nibble | Ver | BSL | Entropy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM|Rsv| DSCP | Proto | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BIERHeader.Proto = PIM Addrress Family¶
BIERHeader.BitString= Bit corresponding to the BFR-id of the EBBR¶
BIERHeader.BFIR-id = BFR-Id of the BBR originating the encapsulated signaling packet, i.e. the IBBR.¶
Rest of the values in the BIER header are determined based on the network (MPLS/non-MPLS), capabilities (BSL), and network configuration.¶
When PIM Light is encapsulated with the BIER header, the BIER forwarding procedure is according to [RFC8279]. No BIER router SHOULD examine this PIM Light signaling packet or modify the signaling packet. As such there is no multicast state built in the BIER domain.¶
The PIM Light signaling packet will be forwarded through the BIER domain until it reaches the EBBR that is indicated by the BIERHeader.Bitstring. Only this targeted EBBR router will remove the BIER header and examine the PIM Light IPv4 or IPv6 signaling packet further as per EBBR Procedure section.¶
EBBR removes the BIER Header and determine this is a PIM Light signaling packet arriving on a PLI. The received signaling packet, Join/Prune message from the PLI is processed as per [RFC9739]¶
The EBBR will build a forwarding table for the arriving (S,G) using the obtained BFIR-id and the Sub-Domain information from BIER Header and/or the PIM join Attributes added to the signaling packet. For a specific Source and Group, EBBR MUST track all the interested IBBRs via signaling messages arriving from the BIER Domain. EBBR builds its (S,G) forwarding state with incoming interface (IIF) as the Reverse Path Forwarding (RPF) interface (in attached PIM domain) towards the source or rendezvous point. The outgoing interfaces are BIER tunnels to the tracked IBBRs interested in that (S,G).¶
The EBBR maintains a PIM adjacency [RFC7761] with any PIM router attached to it on the PIM domain. At this point the end-to-end multicast traffic flow setup is complete.¶
When multicast data traffic arrives on the BFIR (EBBR) it forwards the traffic, through the BIER domain, to all interested IBBRs following the procedures specified in [RFC8279]. The BFER(s) (IBBR(s)) also follow the procedures in [RFC8279] and forward the multicast packet through its outgoing interface(s).¶
The procedures described in this document can be used with Any-Source Mutlicast (ASM) as long as a static Rendezvous Point (RP) or embedded RP for IPv6 is used[RFC3956].¶
In case of PIM ASM Static RP or embedded RP for IPv6 the procedure for hosts joining RP is the same as procedures explained in this document. It should be noted that for ASM, the EBBRs are determined with respect to the RP instead of the source.¶
As per [RFC9739] since PIM Hellos and Asserts are not supported on a PLI, functionality related to these type of message will not be possible through a BIER domain. Future documents may cover these scenarios.¶
With just minor changes, the above procedures apply to MVPN as well, with BFIR/BFER/EBBR/IBBR being VPN PEs. All the PIM related procedures, and the determination of EBBR happens in the context of a VRF, following procedures for PIM-MVPN.¶
Each VPN is provisioned with a sub-domain-id and a label from the default label space consistently across all PEs in the VPN, to be used for PIM signaling and data plane (i.e., Default MDT [RFC6037] or I-PMSI [RFC6514]). This is analogues to that a multicast group address is configured for each VPN.¶
The sub-domain-id and the VPN-identifying label MAY also be independently assigned by each PE. A Data MDT (or S-PMSI) MAY use the same sub-domain-id and label as in the Default MDT (or I-PMSI), or in some cases it is desired to use a different sub-domain-id and label. In these cases, x-PMSI signaling specified in [RFC8556] MUST be used. The Leaf Information Required flag MUST be set to 0 because the leaf information will be signaled via PIM joins. For label optimization space [RFC9573] can be used.¶
When a PIM Join/Prune message arrives from PIM domain attached to the VRF (IBBR), and it is determined that the source is reachable via the VRF through the BIER domain, a PIM signaling message is sent over a PLI via BIER to the EBBR, using the IBBR's BFR-prefix as the source address. In this case usually the PE terminating the PIM-MVPN is the EBBR. The label (provisioned, or signaled from the EBBR) is imposed before the BIER header is imposed (corresponding to the provisioned or signaled sub-domain-id), and the "proto" field in the BIER header is set to 1 (for "MPLS packet with downstream-assigned label at top of stack"). When the EBBR receives message, the label after the BIER header will direct the message to the corresponding VRF.¶
Note that the join/prune messages do not include the attrbute that specifies the BIER information. The EBBR knows the sub-domain-id from its own provisioning (even when different sub-domains are used on different PEs for the same VPN), and derives the BFR-ID of the IBBR from the source address based on BIER signaling.¶
When a multicast data packet is sent via BIER by an EBBR/BFIR, the label is imposed before the BIER packet is imposed, and the "proto" field in the BIER header is set to 1 (for "MPLS packet with downstream-assigned label at top of stack") if the label is assigned to the VPN consistently on all VRFs, or set to 2 if the label is assigned independently on each PE.¶
Note that the "BIER Information Vector PIM Join Attribute" is not used for MVPN.¶
IANA is requested to assign a value (TBD) to the BIER Information Vector PIM Join Attribute from the PIM Join Attribute Types registry.¶
The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane. For a discussion of the security considerations regarding the use of BIER, please see [RFC8279] and [RFC8296]. The security consideration for [RFC7761] aslso apply.¶
The authors would like to thank Eric Rosen, Stig Venaas for their reviews and comments.¶
This appendix provides some examples of routing procedures that can be used to determine the EBBR at the IBBR.¶
On IBBR SPF procedures can be used to find the EBBR closest to the source.¶
Assuming the BIER domain consists of all BIER forwarding routers, SPF calculation can identify the router advertising the prefix for the source. A post process can find the EBBR by walking from the advertising router back to the IBBR in the reverse direction of shortest path tree branch until the first BFR is encountered.¶
Alternatively, the route to the source could have an indirect next-hop that identifies the EBBR. These methods are explained in the following sections.¶
A static route to the source can be configured on the IBBR with the next-hop set as the EBBR's BFR-prefix.¶
Consider the following topology:¶
EBBR IBBR
|--PIM Domain--|-----BIER domain-----|--PIM domain--|
S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h
Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM Domain routes are redistributed to the BIER domain via BGP, performing next-hop-self for these routes. This would include the Multicast Source IP address (S). In such case BGP should use the same next-hop as the EBBR BIER prefix. This will ensure that all PIM domain routes, including the Multicast Source IP address (S) are resolve via EBBR's BIER prefix address. When the host (h) triggers a PIM join message to IBBR (D), IBBR tries to resolve (S). It resolves (S) via BGP installed route and realizes its next-hop is EBBR (B).¶
If each area has its own BIER sub-domain, the above procedure for post-SPF could identify one of the ABRs and the EBBR. If a sub-domain spans multiple areas, then additional procedures as described in A.2 is needed.¶
In a multi-area topology, a BIER sub-domain can span a single area. Suppose this single area is constructed entirely of BIER capable routers and the ABRs are the BIER Boundary Routers attaching the BIER sub-domain in this area to PIM domains in adjacent areas. These BBRs can summarize the PIM domain routes via summary routes, as an example for OSPF, a type 3 summary LSAs can be used to advertise summary routes from a PIM domain area to the BIER area. In such scenarios the IBBR can be configured to look up the Source via IGP database and use the summary routes and its Advertising Router field to resolve the EBBR. The IBBR needs to ensure that the IGP summary route is generated by a BFR. This can be achieved by ensuring that BIER Sub-TLV exists for this route. If multiple BBRs (ABRs) have generated the same summary route the lowest Advertising Router IP can be selected or a vendor specific hashing algorithm can select the summary route from one of the BBRs.¶