Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia
Intended status: Standards Track F. Xu
Expires: 4 September 2025 Verizon
J. Kotalwar
Nokia
I. Wijnands
M. Mishra
Cisco System
Z. Zhang
Juniper Networks
3 March 2025
PIM Signaling Through BIER Core
draft-ietf-bier-pim-signaling-13
Abstract
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).
Status of This Memo
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.
Bidgoli, et al. Expires 4 September 2025 [Page 1]
Internet-Draft PIM Signaling Through BIER Core March 2025
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. PIM Signaling Through BIER domain . . . . . . . . . . . . . . 4
3.1. Ingress BBR procedure . . . . . . . . . . . . . . . . . . 4
3.1.1. New Pim Join Attribute, BIER Information Vector . . . 5
3.1.1.1. BIER packet construction at the IBBR . . . . . . 6
3.2. PIM Light tunneling procedure . . . . . . . . . . . . . . 7
3.3. EBBR procedure . . . . . . . . . . . . . . . . . . . . . 7
4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . 8
4.1. Datapath traffic flow . . . . . . . . . . . . . . . . . . 8
5. PIM-SM behavior . . . . . . . . . . . . . . . . . . . . . . . 8
6. Applicability to MVPN . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Determining the EBBR . . . . . . . . . . . . . . . . 11
A.1. Link-State Protocols . . . . . . . . . . . . . . . . . . 11
A.2. Indirect next-hop . . . . . . . . . . . . . . . . . . . . 11
A.2.1. Static Route . . . . . . . . . . . . . . . . . . . . 11
A.2.2. Interior Border Gateway Protocol (iBGP) . . . . . . . 11
A.3. Inter-area support . . . . . . . . . . . . . . . . . . . 12
A.3.1. Inter-area Route summarization . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Bidgoli, et al. Expires 4 September 2025 [Page 2]
Internet-Draft PIM Signaling Through BIER Core March 2025
1. Introduction
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.
2. Conventions used in this document
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.
2.1. Definitions
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.
Bidgoli, et al. Expires 4 September 2025 [Page 3]
Internet-Draft PIM Signaling Through BIER Core March 2025
3. PIM Signaling Through BIER 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: BIER boundary router
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.
3.1. Ingress BBR procedure
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"
Bidgoli, et al. Expires 4 September 2025 [Page 4]
Internet-Draft PIM Signaling Through BIER Core March 2025
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.
3.1.1. New Pim Join Attribute, BIER Information Vector
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 2: PIM Join Attribute
Bidgoli, et al. Expires 4 September 2025 [Page 5]
Internet-Draft PIM Signaling Through BIER Core March 2025
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PIM Join Attribute detail
BIER Info: IBBR's BFR-prefix (IPv4 or IPv6), sub-domain-id, BFR-id
3.1.1.1. BIER packet construction at the IBBR
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bidgoli, et al. Expires 4 September 2025 [Page 6]
Internet-Draft PIM Signaling Through BIER Core March 2025
Figure 4: BIER header
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.
3.2. PIM Light tunneling procedure
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.
3.3. EBBR procedure
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.
Bidgoli, et al. Expires 4 September 2025 [Page 7]
Internet-Draft PIM Signaling Through BIER Core March 2025
4. Datapath Forwarding
4.1. Datapath traffic flow
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).
5. PIM-SM behavior
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.
6. Applicability to MVPN
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.
Bidgoli, et al. Expires 4 September 2025 [Page 8]
Internet-Draft PIM Signaling Through BIER Core March 2025
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.
7. IANA Considerations
IANA is requested to assign a value (TBD) to the BIER Information
Vector PIM Join Attribute from the PIM Join Attribute Types registry.
8. Security Considerations
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.
9. Acknowledgments
The authors would like to thank Eric Rosen, Stig Venaas for their
reviews and comments.
10. References
Bidgoli, et al. Expires 4 September 2025 [Page 9]
Internet-Draft PIM Signaling Through BIER Core March 2025
10.1. Normative References
[RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate
Requirement Levels"", March 1997.
[RFC6037] "E. Rosen, Y. Cai, I. Wijnands "Cisco Systems' Solution
for Multicast in BGP/MPLS IP VPNs"", October 2010.
[RFC6514] "R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs"", February 2012.
[RFC7761] "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh,
Z.Zhang "PIM Sparse Mode"", March 2016.
[RFC7887] "S.Venaas, J. Arango, I. Kouvelas "Hierarchical PIM/Join
Attributes"", June 2016.
[RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words"", May 2017.
[RFC8279] "Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.
and S. Aldrin, "Multicast using Bit Index Explicit
Replication"", October 2016.
[RFC8296] "IJ. Wijnands, E. Rosen, A. Dolganow, J. Yantsura, S.
Aldrin, I. Meilik, "Encapsulation for BIER"", January
2018.
[RFC8556] "R. Rosen, M.Sivakumar, T. Przygienda, S. Aldrin, A.
Dulganow "Multicast VPN Using BIER", April 2018.
[RFC9573] "Z. Zhang, E. Rosen, W. Lin, Z. Li, IJ. Wijnands "MVPN/
EVPN Tunnel Aggregation with Common Labels "", May 2024.
[RFC9739] "H.Bidgoli, S.Venaas, M.Mishra, Z.Zhang, M.McBride
"Protocol Independent Multicast Light (PIM Light)"", March
2025.
10.2. Informative References
[draft-zzhang-bess-mvpn-evpn-aggregation-label-01]
"Z. Zhang, E. Rosen, W. Lin, Z. Li, I.Wijnands, "MVPN/EVPN
Tunnel Aggregation with Common labels"", April 2018.
[RFC3956] "P.Savola, B. Haberman "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address"".
Bidgoli, et al. Expires 4 September 2025 [Page 10]
Internet-Draft PIM Signaling Through BIER Core March 2025
[RFC6513] "E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs"",
November 2008.
Appendix A. Determining the EBBR
This appendix provides some examples of routing procedures that can
be used to determine the EBBR at the IBBR.
A.1. Link-State Protocols
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.
A.2. Indirect next-hop
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.2.1. Static Route
A static route to the source can be configured on the IBBR with the
next-hop set as the EBBR's BFR-prefix.
A.2.2. Interior Border Gateway Protocol (iBGP)
Consider the following topology:
EBBR IBBR
|--PIM Domain--|-----BIER domain-----|--PIM domain--|
S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h
Figure 5: Static Route
Bidgoli, et al. Expires 4 September 2025 [Page 11]
Internet-Draft PIM Signaling Through BIER Core March 2025
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).
A.3. Inter-area support
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.
A.3.1. Inter-area Route summarization
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.
Authors' Addresses
Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Fengman Xu
Verizon
Richardson,
United States of America
Bidgoli, et al. Expires 4 September 2025 [Page 12]
Internet-Draft PIM Signaling Through BIER Core March 2025
Email: fengman.xu@verizon.com
Jayant Kotalwar
Nokia
Montain View,
United States of America
Email: jayant.kotalwar@nokia.com
IJsbrand Wijnands
Cisco System
Diegem
Belgium
Email: ice@cisco.com
Mankamana Mishra
Cisco System
Milpitas,
United States of America
Email: mankamis@cisco.com
Zhaohui Zhang
Juniper Networks
Boston,
United States of America
Email: zzhang@juniper.com
Bidgoli, et al. Expires 4 September 2025 [Page 13]