rfc9262v4.txt   rfc9262.txt 
skipping to change at line 376 skipping to change at line 376
extension to the (non-TE) BIER forwarding plane, hence allowing it to extension to the (non-TE) BIER forwarding plane, hence allowing it to
be added to BIER deployments where it can be beneficial. be added to BIER deployments where it can be beneficial.
BIER-TE is also intended as an option to expand the BIER architecture BIER-TE is also intended as an option to expand the BIER architecture
into deployments where (non-TE) BIER may not be the best fit, such as into deployments where (non-TE) BIER may not be the best fit, such as
statically provisioned networks that need path steering but do not statically provisioned networks that need path steering but do not
want distributed routing protocols. want distributed routing protocols.
1. BIER-TE inherits the following aspects from BIER unchanged: 1. BIER-TE inherits the following aspects from BIER unchanged:
a. The fundamental purpose of per-packet signaled replication 1.a The fundamental purpose of per-packet signaled replication
and delivery via a BitString. and delivery via a BitString.
b. The overall architecture, which consists of three layers: the 1.b The overall architecture, which consists of three layers:
flow overlay, the BIER(-TE) layer, and the routing underlay. the flow overlay, the BIER(-TE) layer, and the routing
underlay.
c. The supported encapsulations [RFC8296]. 1.c The supported encapsulations [RFC8296].
d. The semantics of all BIER header elements [RFC8296] used by 1.d The semantics of all BIER header elements [RFC8296] used by
the BIER-TE forwarding plane, other than the semantic of the the BIER-TE forwarding plane, other than the semantic of the
BP in the BitString. BP in the BitString.
e. The BIER forwarding plane, except for how bits have to be 1.e The BIER forwarding plane, except for how bits have to be
cleared during replication. cleared during replication.
2. BIER-TE has the following key changes with respect to BIER: 2. BIER-TE has the following key changes with respect to BIER:
a. In BIER, bits in the BitString of a BIER packet header 2.a In BIER, bits in the BitString of a BIER packet header
indicate a BFER, and bits in the BIFT indicate the BIER indicate a BFER, and bits in the BIFT indicate the BIER
control plane's calculated next hop towards that BFER. In control plane's calculated next hop towards that BFER. In
BIER-TE, a bit in the BitString of a BIER packet header BIER-TE, a bit in the BitString of a BIER packet header
indicates an adjacency in the BIER-TE topology, and only the indicates an adjacency in the BIER-TE topology, and only the
BFR that is the upstream of that adjacency has its BP BFR that is the upstream of that adjacency has its BP
populated with the adjacency in its BIFT. populated with the adjacency in its BIFT.
b. In BIER, the implied reference options for the core part of 2.b In BIER, the implied reference options for the core part of
the BIER layer control plane are the BIER extensions for the BIER layer control plane are the BIER extensions for
distributed routing protocols. These include IS-IS and OSPF distributed routing protocols. These include IS-IS and OSPF
extensions for BIER, as specified in [RFC8401] and [RFC8444], extensions for BIER, as specified in [RFC8401] and
respectively. [RFC8444], respectively.
c. The reference option for the core part of the BIER-TE control 2.c The reference option for the core part of the BIER-TE
plane is the BIER-TE controller. Nevertheless, both the BIER control plane is the BIER-TE controller. Nevertheless, both
and BIER-TE BIFTs' forwarding plane state could equally be the BIER and BIER-TE BIFTs' forwarding plane state could
populated by any mechanism. equally be populated by any mechanism.
d. Assuming the reference options for the control plane, BIER-TE 2.d Assuming the reference options for the control plane, BIER-
replaces in-network autonomous path calculations with TE replaces in-network autonomous path calculations with
explicit paths calculated by the BIER-TE controller. explicit paths calculated by the BIER-TE controller.
3. The following elements/functions described in the BIER 3. The following elements/functions described in the BIER
architecture are not required by the BIER-TE architecture: architecture are not required by the BIER-TE architecture:
a. "Bit Index Routing Tables" (BIRTs) are not required on BFRs 3.a "Bit Index Routing Tables" (BIRTs) are not required on BFRs
for BIER-TE when using a BIER-TE controller, because the for BIER-TE when using a BIER-TE controller, because the
controller can directly populate the BIFTs. In BIER, BIRTs controller can directly populate the BIFTs. In BIER, BIRTs
are populated by the distributed routing protocol support for are populated by the distributed routing protocol support
BIER, allowing BFRs to populate their BIFTs locally from for BIER, allowing BFRs to populate their BIFTs locally from
their BIRTs. Other BIER-TE control plane or management plane their BIRTs. Other BIER-TE control plane or management
options may introduce requirements for BIRTs for BIER-TE plane options may introduce requirements for BIRTs for BIER-
BFRs. TE BFRs.
b. The BIER-TE layer forwarding plane does not require BFRs to 3.b The BIER-TE layer forwarding plane does not require BFRs to
have a unique BP; see Section 5.1.3. Therefore, BFRs may not have a unique BP; see Section 5.1.3. Therefore, BFRs may
have a unique BFR-id; see Section 5.3.3. not have a unique BFR-id; see Section 5.3.3.
c. Identification of BFRs by the BIER-TE control plane is 3.c Identification of BFRs by the BIER-TE control plane is
outside the scope of this specification. Whereas the BIER outside the scope of this specification. Whereas the BIER
control plane uses BFR-ids in its BFR-to-BFR signaling, a control plane uses BFR-ids in its BFR-to-BFR signaling, a
BIER-TE controller may choose any form of identification BIER-TE controller may choose any form of identification
deemed appropriate. deemed appropriate.
d. BIER-TE forwarding does not require the BFIR-id field of the 3.d BIER-TE forwarding does not require the BFIR-id field of the
BIER packet header. BIER packet header.
4. Co-existence of BIER and BIER-TE in the same network requires the 4. Co-existence of BIER and BIER-TE in the same network requires the
following: following:
a. The BIER/BIER-TE packet header needs to allow the addressing 4.a The BIER/BIER-TE packet header needs to allow the addressing
of both BIER and BIER-TE BIFTs. Depending on the of both BIER and BIER-TE BIFTs. Depending on the
encapsulation option, the same SD may or may not be reusable encapsulation option, the same SD may or may not be reusable
across BIER and BIER-TE. See Section 4.3. In either case, a across BIER and BIER-TE. See Section 4.3. In either case,
packet is always forwarded only end to end via BIER or via a packet is always forwarded only end to end via BIER or via
BIER-TE ("ships in the night" forwarding). BIER-TE ("ships in the night" forwarding).
b. BIER-TE deployments will have to assign BFR-ids to BFRs and 4.b BIER-TE deployments will have to assign BFR-ids to BFRs and
insert them into the BFIR-id field of BIER packet headers, as insert them into the BFIR-id field of BIER packet headers,
does BIER, whenever the deployment uses (unchanged) as does BIER, whenever the deployment uses (unchanged)
components developed for BIER that use BFR-ids, such as components developed for BIER that use BFR-ids, such as
multicast flow overlays or BIER layer control plane elements. multicast flow overlays or BIER layer control plane
See also Section 5.3.3. elements. See also Section 5.3.3.
2.5. Accelerated Hardware Forwarding Comparison 2.5. Accelerated Hardware Forwarding Comparison
BIER-TE forwarding rules, especially BitString parsing, are designed BIER-TE forwarding rules, especially BitString parsing, are designed
to be as close as possible to those of BIER, with the expectation to be as close as possible to those of BIER, with the expectation
that this eases the programming of BIER-TE forwarding code and/or that this eases the programming of BIER-TE forwarding code and/or
BIER-TE forwarding hardware on platforms supporting BIER. The BIER-TE forwarding hardware on platforms supporting BIER. The
pseudocode in Section 4.4 shows how existing (non-TE) BIER/BIFT pseudocode in Section 4.4 shows how existing (non-TE) BIER/BIFT
forwarding can be modified to support the required BIER-TE forwarding forwarding can be modified to support the required BIER-TE forwarding
functionality (Section 4.5), by using the BIER BIFT's "Forwarding Bit functionality (Section 4.5), by using the BIER BIFT's "Forwarding Bit
skipping to change at line 532 skipping to change at line 533
In the (non-TE) BIER architecture [RFC8279], the BIER layer is In the (non-TE) BIER architecture [RFC8279], the BIER layer is
summarized in Section 4.2 of [RFC8279]. This summary includes both summarized in Section 4.2 of [RFC8279]. This summary includes both
the functions of the BIER-layer control plane and forwarding plane, the functions of the BIER-layer control plane and forwarding plane,
without using those terms. Example standardized options for the BIER without using those terms. Example standardized options for the BIER
control plane include IS-IS and OSPF extensions for BIER, as control plane include IS-IS and OSPF extensions for BIER, as
specified in [RFC8401] and [RFC8444], respectively. specified in [RFC8401] and [RFC8444], respectively.
For BIER-TE, the control plane includes, at a minimum, the following For BIER-TE, the control plane includes, at a minimum, the following
functionality. functionality.
BIER-TE topology control: During initial provisioning of the network 1. BIER-TE topology control: During initial provisioning of the
and/or during modifications of its topology and/or services, the network and/or during modifications of its topology and/or
protocols and/or procedures to establish BIER-TE BIFTs: services, the protocols and/or procedures to establish BIER-TE
BIFTs:
1. Determine the desired BIER-TE topology for BIER-TE subdomains: 1.a Determine the desired BIER-TE topology for BIER-TE
the adjacencies that are assigned to BPs. Topology discovery subdomains: the adjacencies that are assigned to BPs.
is discussed in Section 3.2.1.1, and the various aspects of Topology discovery is discussed in Section 3.2.1.1, and the
the BIER-TE controller's determinations regarding the topology various aspects of the BIER-TE controller's determinations
are discussed throughout Section 5. regarding the topology are discussed throughout Section 5.
2. Determine the per-BFR BIFT from the BIER-TE topology. This is 1.b Determine the per-BFR BIFT from the BIER-TE topology. This
achieved by simply extracting the adjacencies of the BFR from is achieved by simply extracting the adjacencies of the BFR
the BIER-TE topology and populating the BFR's BIFT with them. from the BIER-TE topology and populating the BFR's BIFT with
them.
3. Optionally assign BFR-ids to BFIRs for later insertion into 1.c Optionally assign BFR-ids to BFIRs for later insertion into
BIER headers on BFIRs as BFIR-ids. Alternatively, BFIR-ids in BIER headers on BFIRs as BFIR-ids. Alternatively, BFIR-ids
BIER packet headers may be managed solely by the flow overlay in BIER packet headers may be managed solely by the flow
layer and/or be unused. This is discussed in Section 5.3.3. overlay layer and/or be unused. This is discussed in
Section 5.3.3.
4. Install/update the BIFTs into the BFRs and, optionally, BFR- 1.d Install/update the BIFTs into the BFRs and, optionally, BFR-
ids into BFIRs. This is discussed in Section 3.2.1.1. ids into BFIRs. This is discussed in Section 3.2.1.1.
BIER-TE tree control: During network operations, protocols and/or 2. BIER-TE tree control: During network operations, protocols and/or
procedures to support creation/change/removal of overlay flows on procedures to support creation/change/removal of overlay flows on
BFIRs: BFIRs:
1. Process the BIER-TE requirements for the multicast overlay 2.a Process the BIER-TE requirements for the multicast overlay
flow: BFIRs and BFERs of the flow as well as policies for the flow: BFIRs and BFERs of the flow as well as policies for
path selection of the flow. This is discussed in Section 3.5. the path selection of the flow. This is discussed in
Section 3.5.
2. Determine the BitStrings and, optionally, entropy. BitStrings 2.b Determine the BitStrings and, optionally, entropy.
are discussed in Sections 3.2.1.2, 3.5, and 5.3.4. Entropy is BitStrings are discussed in Sections 3.2.1.2, 3.5, and
discussed in Section 4.2.3. 5.3.4. Entropy is discussed in Section 4.2.3.
3. Install state on the BFIR to impose the desired BIER packet 2.c Install state on the BFIR to impose the desired BIER packet
header(s) for packets of the overlay flow. Different aspects header(s) for packets of the overlay flow. Different
of this point, as well as the next point, are discussed aspects of this point, as well as the next point, are
throughout Section 3.2.1 and in Section 4.3. The main discussed throughout Section 3.2.1 and in Section 4.3. The
component responsible for these two points is the multicast main component responsible for these two points is the
flow overlay (Section 3.1), which is architecturally inherited multicast flow overlay (Section 3.1), which is
from BIER. architecturally inherited from BIER.
4. Install the necessary state on the BFERs to decapsulate the 2.d Install the necessary state on the BFERs to decapsulate the
BIER packet header and properly dispatch its payload. BIER packet header and properly dispatch its payload.
3.2.1. The BIER-TE Controller 3.2.1. The BIER-TE Controller
This architecture describes the BIER-TE control plane, as shown in This architecture describes the BIER-TE control plane, as shown in
Figure 3, as consisting of: Figure 3, as consisting of:
* A BIER-TE controller. * A BIER-TE controller.
* BFR data models and protocols to communicate between the * BFR data models and protocols to communicate between the
controller and BFRs in support of BIER-TE topology control controller and BFRs in support of BIER-TE topology control (see
(Section 3.2) (see the list under "BIER-TE topology control"), the list under "BIER-TE topology control"), such as YANG/NETCONF/
such as YANG/NETCONF/RESTCONF [RFC7950] [RFC6241] [RFC8040]. RESTCONF [RFC7950] [RFC6241] [RFC8040].
* BFR data models and protocols to communicate between the * BFR data models and protocols to communicate between the
controller and BFIRs in support of BIER-TE tree control controller and BFIRs in support of BIER-TE tree control (see
(Section 3.2) (see the list under "BIER-TE tree control"), such as Section 3.2, point 2.), such as BIER-TE extensions for [RFC5440].
BIER-TE extensions for [RFC5440].
The single, centralized BIER-TE controller is used in this document The single, centralized BIER-TE controller is used in this document
as the reference option for the BIER-TE control plane, but other as the reference option for the BIER-TE control plane, but other
options are equally feasible. The BIER-TE control plane could options are equally feasible. The BIER-TE control plane could
equally be implemented without automated configuration/protocols, by equally be implemented without automated configuration/protocols, by
an operator via a CLI on the BFRs. In that case, operator-configured an operator via a CLI on the BFRs. In that case, operator-configured
local policy on the BFIR would have to determine how to set the local policy on the BFIR would have to determine how to set the
appropriate BIER header fields. The BIER-TE control plane could also appropriate BIER header fields. The BIER-TE control plane could also
be decentralized and/or distributed, but this document does not be decentralized and/or distributed, but this document does not
consider any additional protocols and/or procedures that would then consider any additional protocols and/or procedures that would then
be necessary to coordinate its (distributed/decentralized) entities be necessary to coordinate its (distributed/decentralized) entities
to achieve the above-described functionality. to achieve the above-described functionality.
3.2.1.1. BIER-TE Topology Discovery and Creation 3.2.1.1. BIER-TE Topology Discovery and Creation
The first item listed for BIER-TE topology control (Section 3.2) The first item listed for BIER-TE topology control (Section 3.2,
includes network topology discovery and BIER-TE topology creation. point 1.a.) includes network topology discovery and BIER-TE topology
The latter describes the process by which a controller determines creation. The latter describes the process by which a controller
which routers are to be configured as BFRs and the adjacencies determines which routers are to be configured as BFRs and the
between them. adjacencies between them.
In statically managed networks, e.g., industrial environments, both In statically managed networks, e.g., industrial environments, both
discovery and creation can be a manual/offline process. discovery and creation can be a manual/offline process.
In other networks, topology discovery may rely on such protocols as In other networks, topology discovery may rely on such protocols as
those that include extending an IGP based on a link-state protocol those that include extending an IGP based on a link-state protocol
into the BIER-TE controller itself, e.g., BGP-LS [RFC7752] or YANG into the BIER-TE controller itself, e.g., BGP-LS [RFC7752] or YANG
topology [RFC8345], as well as methods specific to BIER-TE -- for topology [RFC8345], as well as methods specific to BIER-TE -- for
example, via [BIER-TE-YANG]. These options are non-exhaustive. example, via [BIER-TE-YANG]. These options are non-exhaustive.
skipping to change at line 1088 skipping to change at line 1092
forwarding functions (see Section 4.5) -- forward_connected(), forwarding functions (see Section 4.5) -- forward_connected(),
forward_routed(), and local_decap() -- but cannot support the forward_routed(), and local_decap() -- but cannot support the
recommended functions (DNC flag and multiple adjacencies per bit) or recommended functions (DNC flag and multiple adjacencies per bit) or
the optional function (i.e., ECMP() adjacencies). The DNC flag the optional function (i.e., ECMP() adjacencies). The DNC flag
cannot be supported when using only [1] to mask bits. cannot be supported when using only [1] to mask bits.
The modified and expanded forwarding pseudocode in Figure 6 specifies The modified and expanded forwarding pseudocode in Figure 6 specifies
how to support all BIER-TE forwarding functions (required, how to support all BIER-TE forwarding functions (required,
recommended, and optional): recommended, and optional):
* This pseudocode eliminates per-bit F-BMs, therefore reducing the 1. This pseudocode eliminates per-bit F-BMs, therefore reducing the
size of BIFT state by SI*BSL^2 and eliminating the need for per- size of BIFT state by SI*BSL^2 and eliminating the need for per-
packet-copy BitString masking operations, except for adjacencies packet-copy BitString masking operations, except for adjacencies
with the DNC flag set: with the DNC flag set:
- AdjacentBits[SI] are bit positions with a non-empty list of 1.a AdjacentBits[SI] are bit positions with a non-empty list of
adjacencies in this BFR BIFT. This can be computed whenever adjacencies in this BFR BIFT. This can be computed whenever
the BIER-TE controller updates (adds/removes) adjacencies in the BIER-TE controller updates (adds/removes) adjacencies in
the BIFT. the BIFT.
- The BFR needs to create packet copies for these adjacent bits 1.b The BFR needs to create packet copies for these adjacent
when they are set in the packets BitString. This set of bits bits when they are set in the packets BitString. This set
is calculated in PktAdjacentBits. of bits is calculated in PktAdjacentBits.
- All bit positions for which the BFR creates copies have to be 1.c All bit positions for which the BFR creates copies have to
cleared in packet copies to avoid loops. This is done by be cleared in packet copies to avoid loops. This is done by
masking the BitString of the packet with ~AdjacentBits[SI]. masking the BitString of the packet with ~AdjacentBits[SI].
When an adjacency has DNC set, this bit position is set again When an adjacency has DNC set, this bit position is set
only for the packet copy towards that bit position. again only for the packet copy towards that bit position.
* BIFT entries may contain more than one adjacency in support of 2. BIFT entries may contain more than one adjacency in support of
specific configurations, such as a hub and multiple spokes specific configurations, such as a hub and multiple spokes
(Section 5.1.5). The code therefore includes a loop over these (Section 5.1.5). The code therefore includes a loop over these
adjacencies. adjacencies.
* The ECMP() adjacency is also shown in the figure. Its parameters 3. The ECMP() adjacency is also shown in the figure. Its parameters
are a seed and "ListOfAdjacencies", from which one is picked. are a seed and "ListOfAdjacencies", from which one is picked.
* The forward_connected(), forward_routed(), and local_decap() 4. The forward_connected(), forward_routed(), and local_decap()
adjacencies are shown with their parameters. adjacencies are shown with their parameters.
void ForwardBitMaskPacket_withTE (Packet) void ForwardBitMaskPacket_withTE (Packet)
{ {
SI = GetPacketSI(Packet); SI = GetPacketSI(Packet);
Offset = SI * BitStringLength; Offset = SI * BitStringLength;
// Determine adjacent bits in the packets BitString // Determine adjacent bits in the packets BitString
PktAdjacentBits = Packet->BitString & AdjacentBits[SI]; PktAdjacentBits = Packet->BitString & AdjacentBits[SI];
// Clear adjacent bits in the packet header to avoid loops // Clear adjacent bits in the packet header to avoid loops
Packet->BitString &= ~AdjacentBits[SI]; Packet->BitString &= ~AdjacentBits[SI];
skipping to change at line 1630 skipping to change at line 1634
controller can create a BIER-TE topology in a way that minimizes the controller can create a BIER-TE topology in a way that minimizes the
number of necessary BPs. number of necessary BPs.
Without any optimization, a BIER-TE controller would attempt to map Without any optimization, a BIER-TE controller would attempt to map
the network subnet topology 1:1 into the BIER-TE topology, every the network subnet topology 1:1 into the BIER-TE topology, every
adjacent neighbor in the subnet would require a forward_connected() adjacent neighbor in the subnet would require a forward_connected()
BP, and every BFER would require a local_decap() BP. BP, and every BFER would require a local_decap() BP.
The optimizations described in this document are then as follows: The optimizations described in this document are then as follows:
* P2P links require only one BP (Section 5.1.1). 1. P2P links require only one BP (Section 5.1.1).
* All leaf BFERs can share a single local_decap() BP 2. All leaf BFERs can share a single local_decap() BP
(Section 5.1.3). (Section 5.1.3).
* A LAN with N BFRs needs at most N BPs (one for each BFR). It only 3. A LAN with N BFRs needs at most N BPs (one for each BFR). It
needs one BP for all those BFRs that are not redundantly connected only needs one BP for all those BFRs that are not redundantly
to multiple LANs (Section 5.1.4). connected to multiple LANs (Section 5.1.4).
* A hub with P2P connections to multiple non-leaf BFER spokes can 4. A hub with P2P connections to multiple non-leaf BFER spokes can
share one BP with all of the spokes if traffic can be flooded to share one BP with all of the spokes if traffic can be flooded to
all of those spokes, e.g., because of no bandwidth concerns or all of those spokes, e.g., because of no bandwidth concerns or
dense receiver sets (Section 5.1.5). dense receiver sets (Section 5.1.5).
* Rings of BFRs can be built with just two BPs (one for each 5. Rings of BFRs can be built with just two BPs (one for each
direction), except for BFRs with multiple ring connections -- direction), except for BFRs with multiple ring connections --
similar to LANs (Section 5.1.6). similar to LANs (Section 5.1.6).
* ECMP() adjacencies to N neighbors can replace N BPs with one BP. 6. ECMP() adjacencies to N neighbors can replace N BPs with one BP.
Multihop ECMP can avoid polarization through different seeds of Multihop ECMP can avoid polarization through different seeds of
the ECMP algorithm (Section 5.1.7). the ECMP algorithm (Section 5.1.7).
* Forward_routed() adjacencies permit "tunneling" across routers 7. Forward_routed() adjacencies permit "tunneling" across routers
that are either BIER-TE capable or not BIER-TE capable where no that are either BIER-TE capable or not BIER-TE capable where no
traffic steering or replications are required (Section 5.1.8). traffic steering or replications are required (Section 5.1.8).
* A BP can generally be reused across a set of nodes where it can be 8. A BP can generally be reused across a set of nodes where it can
guaranteed that no path will ever need to traverse more than one be guaranteed that no path will ever need to traverse more than
node of the set. Depending on the scenario, this may limit the one node of the set. Depending on the scenario, this may limit
feasible path steering options (Section 5.1.9). the feasible path steering options (Section 5.1.9).
Note that this list of optimizations is not exhaustive. Further Note that this list of optimizations is not exhaustive. Further
optimizations of BPs are possible, especially when both the set of optimizations of BPs are possible, especially when both the set of
required path steering choices and the possible subsets of BFERs that required path steering choices and the possible subsets of BFERs that
should be able to receive traffic are limited. The hub-and-spoke should be able to receive traffic are limited. The hub-and-spoke
optimization is a simple example of such traffic-pattern-dependent optimization is a simple example of such traffic-pattern-dependent
optimizations. optimizations.
5.2. Avoiding Duplicates and Loops 5.2. Avoiding Duplicates and Loops
skipping to change at line 1805 skipping to change at line 1809
In BIER-TE, BitStrings need to carry bits to indicate not only the In BIER-TE, BitStrings need to carry bits to indicate not only the
receiving BFER but also the intermediate hops/links across which the receiving BFER but also the intermediate hops/links across which the
packet must be sent. The maximum number of BFERs that can be packet must be sent. The maximum number of BFERs that can be
supported in a single BitString or BIFT:SI depends on the number of supported in a single BitString or BIFT:SI depends on the number of
bits necessary to represent the desired topology between them. bits necessary to represent the desired topology between them.
"Desired" topology means that it depends on the physical topology and "Desired" topology means that it depends on the physical topology and
the operator's desire to the operator's desire to
* permit explicit path steering across every single hop (which 1. permit explicit path steering across every single hop (which
requires more bits), or requires more bits), or
* reduce the number of required bits by exploiting optimizations 2. reduce the number of required bits by exploiting optimizations
such as unicast (forward_routed()), ECMP(), or flood (DNC) over such as unicast (forward_routed()), ECMP(), or flood (DNC) over
"uninteresting" sub-parts of the topology, e.g., parts where, for "uninteresting" sub-parts of the topology, e.g., parts where, for
path steering reasons, different trees do not need to take path steering reasons, different trees do not need to take
different paths. different paths.
The total number of bits to describe the topology vs. the number of The total number of bits to describe the topology vs. the number of
BFERs in a BIFT:SI can range widely based on the size of the topology BFERs in a BIFT:SI can range widely based on the size of the topology
and the amount of alternative paths in it. In a BIER-TE topology and the amount of alternative paths in it. In a BIER-TE topology
crafted by a BIER-TE expert, the higher the percentage of non-BFER crafted by a BIER-TE expert, the higher the percentage of non-BFER
bits, the higher the likelihood that those topology bits are not just bits, the higher the likelihood that those topology bits are not just
BIER-TE overhead without additional benefit but instead will allow BIER-TE overhead without additional benefit but instead will allow
the expression of desirable path steering alternatives. the expression of desirable path steering alternatives.
5.3.3. Assigning BFR-ids with BIER-TE 5.3.3. Assigning BFR-ids with BIER-TE
skipping to change at line 2180 skipping to change at line 2184
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
8.2. Informative References 8.2. Informative References
[BIER-MCAST-OVERLAY] [BIER-MCAST-OVERLAY]
Trossen, D., Rahman, A., Wang, C., and T. T. Eckert, Trossen, D., Rahman, A., Wang, C., and T. Eckert,
"Applicability of BIER Multicast Overlay for Adaptive "Applicability of BIER Multicast Overlay for Adaptive
Streaming Services", Work in Progress, Internet-Draft, Streaming Services", Work in Progress, Internet-Draft,
draft-ietf-bier-multicast-http-response-06, 10 July 2021, draft-ietf-bier-multicast-http-response-06, 10 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier- <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
multicast-http-response-06>. multicast-http-response-06>.
[BIER-TE-PROTECTION] [BIER-TE-PROTECTION]
Eckert, T. T., Cauchie, G., Braun, W., and M. Menth, Eckert, T., Cauchie, G., Braun, W., and M. Menth,
"Protection Methods for BIER-TE", Work in Progress, "Protection Methods for BIER-TE", Work in Progress,
Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018, Internet-Draft, draft-eckert-bier-te-frr-03, 5 March 2018,
<https://datatracker.ietf.org/doc/html/draft-eckert-bier- <https://datatracker.ietf.org/doc/html/draft-eckert-bier-
te-frr-03>. te-frr-03>.
[BIER-TE-YANG] [BIER-TE-YANG]
Zhang, Z., Wang, C., Chen, R., hu, F., Sivakumar, M., and Zhang, Z., Wang, C., Chen, R., Hu, F., Sivakumar, M., and
chenhuanan, "A YANG data model for Tree Engineering for H. Chen, "A YANG data model for Tree Engineering for Bit
Bit Index Explicit Replication (BIER-TE)", Work in Index Explicit Replication (BIER-TE)", Work in Progress,
Progress, Internet-Draft, draft-ietf-bier-te-yang-05, 1 Internet-Draft, draft-ietf-bier-te-yang-05, 1 May 2022,
May 2022, <https://datatracker.ietf.org/doc/html/draft- <https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-
ietf-bier-te-yang-05>. yang-05>.
[Bloom70] Bloom, B. H., "Space/time trade-offs in hash coding with [Bloom70] Bloom, B. H., "Space/time trade-offs in hash coding with
allowable errors", Comm. ACM 13(7):422-6, allowable errors", Comm. ACM 13(7):422-6,
DOI 10.1145/362686.362692, July 1970, DOI 10.1145/362686.362692, July 1970,
<https://dl.acm.org/doi/10.1145/362686.362692>. <https://dl.acm.org/doi/10.1145/362686.362692>.
[CONSTRAINED-CAST] [CONSTRAINED-CAST]
Bergmann, O., Bormann, C., Gerdes, S., and H. Chen, Bergmann, O., Bormann, C., Gerdes, S., and H. Chen,
"Constrained-Cast: Source-Routed Multicast for RPL", Work "Constrained-Cast: Source-Routed Multicast for RPL", Work
in Progress, Internet-Draft, draft-ietf-roll-ccast-01, 30 in Progress, Internet-Draft, draft-ietf-roll-ccast-01, 30
skipping to change at line 2323 skipping to change at line 2327
<https://www.rfc-editor.org/info/rfc8444>. <https://www.rfc-editor.org/info/rfc8444>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
[TE-OVERVIEW] [TE-OVERVIEW]
Farrel, A., Ed., "Overview and Principles of Internet Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", Work in Progress, Internet-Draft, Traffic Engineering", Work in Progress, Internet-Draft,
draft-ietf-teas-rfc3272bis-16, 24 March 2022, draft-ietf-teas-rfc3272bis-21, 11 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas- <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
rfc3272bis-16>. rfc3272bis-21>.
Appendix A. BIER-TE and Segment Routing (SR) Appendix A. BIER-TE and Segment Routing (SR)
SR [RFC8402] aims to enable lightweight path steering via loose SR [RFC8402] aims to enable lightweight path steering via loose
source routing. For example, compared to its more heavyweight source routing. For example, compared to its more heavyweight
predecessor, RSVP-TE, SR does not require per-path signaling to each predecessor, RSVP-TE, SR does not require per-path signaling to each
of these hops. of these hops.
BIER-TE supports the same design philosophy for multicast. Like SR, BIER-TE supports the same design philosophy for multicast. Like SR,
BIER-TE BIER-TE
 End of changes. 50 change blocks. 
169 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.48.