| Internet-Draft | BIER Brownfield | July 2024 |
| Zhang, et al. | Expires 2 January 2025 | [Page] |
BIER is a new architecture for the forwarding and replication of multicast data packets. This document defines possible approaches to introduce BIER into networks consisting of a mixture of BFRs and non- BFRs and their respective preconditions and properties.¶
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 2 January 2025.¶
Copyright (c) 2024 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.¶
BIER [RFC8279] is a new architecture for the forwarding of multicast data packets. It allows replication through a "multicast domain" and it does not precondition construction of a multicast distribution tree, nor does it precondition intermediate nodes to maintain any per-flow state.¶
Given that BIER encompasses a novel switching path it can be reasonably expected that in many deployment scenarios, at least initially, a mixture of BFRs and non-BFR (i.e. routers having all or some of the interfaces not being capable of BIER forwarding) will be used and represent what we will call "mixed environments". [RFC8279] offers several suggestions how a mixture of such routers can be handled in the network. The purpose of this memo is to cover other possible deployment options with explanation what preconditions are necessary to apply each of those and what properties and requirements they bring in operational considerations respectively.¶
The presented sequence of possible solutions follows very loosely an ordering starting with the ones that use "least" amount of additional technologies beside BIER to deploy a "mixed environment". This¶
serves subsequently to facilitate the introduction of consecutive, more interdependent solutions. Nevertheless, this does not imply that any of the solutions is better or simpler. The "optimal" solution will depend every time on operational realities of the network performing a migration towards BIER deployment.¶
Any tunnelling technology used when deploying BIER in a "mixed environment" must ensure that in case the tunnel carries other types of traffic beside BIER the tunnel termination point MUST be capable of identifying BIER frames by some means. In case of tunnel carrying only Ethernet frames or MPLS encapsulated traffic [RFC8296] allows to distinguish BIER from other frames.¶
Strictly speaking BIER can be deployed in "mixed environments" without any additional extensions or new technologies in its basic form. Proper use of multi-topology [RFC5120] configuration in IGPs will allow separation of BIER capable routers and interfaces in the topology, possibly connected via IGP tunnels to create at minimum a graph of BFRs.¶
BIER IGP signalling via [RFC8444], [RFC8401], [I-D.ietf-bier-ospfv3-extensions], or [I-D.ietf-bier-lsr-non-mpls-extensions], and¶
implementation of multi-topology and¶
any kind of tunneling technology that can be viewed as adjacency in IGP.¶
Multi-topology has been standardized and used for many years in IGPs and other signalling protocols.¶
The use of multi-topology allows for multicast and unicast traffic to follow (per subdomain) different paths if necessary in case such a behavior is desired operationally.¶
Normal IGP computation results are used as BIER nexthops, i.e. normal SPF nexthops or even TE computation nexthops and techniques like [RFC3906] are applicable.¶
Reconfiguring multi-topology preconditions the touching of both sides of a link in the multi-topology and recomputation of BIER nexthops for the given topology on all routers. On changes in topology the tunnels may need to be reprovisioned depending on technology and protection scheme used.¶
Physical links configured as members of several multi-topologies can be "shared" between subdomains for e.g. protection purposes, i.e. if multi topologies used for different sub-domains are using same physical links, the links will be used by the according sub- domains as well. By adjusting IGP metrics the traffic can be kept separate per subdomain with the possiblity of a "fail-over" onto the links with high IGP metric in case of failures. It is even possible to use the same physical topology with each multi- topology carrying different metrics to make different links having different preference for each sub-domain and "separate" traffic per sub-domain that way.¶
Since multi-topology membership is a "per interface" property it allows to manage "partial BFR" routers, i.e. routers where only a subset of interfaces is BIER capable.¶
Multi-topology solution can be combined in case of "mixed environment" with any other solution described in this document that is multi-topology aware.¶
If tunnel metrics are chosen based on purely IGP metrics the solution may load-balance between hop-by-hop BIER path and tunnels which can lead to different timing behavior on each path albeit in case of BIER entropy encompassing a logical flow this should be benign.¶
Multi-topology provides inherently separate routing tables and according statistics.¶
This section deals with the "re-parenting" solution outlined in Section 6.9 of [RFC8279]. We will deal with the modified step 2) solution in Section 4.¶
BIER IGP signalling via [RFC8444], [RFC8401], [I-D.ietf-bier-ospfv3-extensions], or [I-D.ietf-bier-lsr-non-mpls-extensions], and¶
pre-provisioned "static" tunnels that allows "re-parenting" in any possible failure scenario and/or¶
a "dynamic tunneling" technology that can use a unicast tunnel between any pair of nodes in the domain without configuration or setup, e.g. "soft" GRE [RFC2784], LDP [RFC3036] in Downstream Unsolicited mode or Segment Routing [RFC8402] are assumed to be deployed through the whole BIER domain.¶
When used with dynamic tunnels the solution can automatically "bridge" disconnected areas without necessity to provision multi topology or static tunnel configuration, i.e. this solution can deal with any arbitrary breakage of topology as long the network does not become partitioned. It is equivalent to node protection [RFC5286].¶
IGPs do not have to be aware of the tunnels.¶
BIER traffic strictly follows unicast path only (assuming that the "dynamic tunnels" are following IGP unicast nexthops as well) and with that¶
all BIER capable routers MUST have enough scale to carry unicast load and¶
if the unicast next-hop is a non-BIER capable router the router upstream will ingress replicate to all the children on the unicast tree of that next-hop and¶
BIER may load balance between tunneled and BIER native forwarding paths which can lead to different timing behavior albeit in case of BIER entropy encompassing a logical flow this should be benign.¶
All interfaces on BFRs MUST be capable of BIER forwarding.¶
Dynamic tunneling topologies do not provide extensive OAM normally albeit they may provide node and link failure protection. On the other hand, some "dynamic tunnelling" technologies like segment routing will hold minimum amount of state in the network, i.e. no per-tunnel specific state while providing coverage for any non- partitioning failure.¶
If a tunnel is used to reach the next BFR, the tunnel's own node/ link protection provides FRR.¶
Each change in dynamic tunnel signalling (such as LDP) may lead to recomputation of BIFT entries.¶
With the RFC8279 Section 6.9 solution, an upstream BFR will ingress replicate to downstream BFRs that are the children/grandchildren of a non-BFR on the SPF tree. This may not be desired in certain situations, as described in [I-D.ietf-bier-tether].¶
A solution is specified in [I-D.ietf-bier-tether]. In the simplest form, a BFR can be attached to a non-BFR with a local fat pipe, as a helper to the non-BFR. The upstream BFR will tunnel a single copy to the tethered BFR, which will then tunnel to downstream BFRs.¶
The same as in Section 3, plus signaling as specified in [I-D.ietf-bier-tether].¶
The same as in Section 3, except that ingress replication from the upstream BFR is replaced by a single tunnel to the tethered BFR, and then ingress replication from the tethered BFR to downstream BFRs.¶
As described in [I-D.ietf-bier-tether], the tethered BFR does not have to be a dedicated one - it can be used in the network for other purposes. A single tethered BFR can help multiple non-BFRs, and multiple helpers can help a single non-BFR. The same method that is used to ensure loop-free in LFA/TI-LFA is used to ensure loop-free in this BIER tethering case.¶
BIER can support a multitude of BIER Algorithms (BAR) as specified in IGP drafts and [RFC9272] to operate in "mixed environments" and take into consideration BIER specific constraints and properties. While doing that BFRs signal which algorithm they use so the distributed computation delivers consistent results on all BFRs. In its simplest form BAR can defined an SPF where non-BFRs are not being put on the candidate list which we denote for the moment as BAR=1 and consider further.¶
BIER IGP signalling via [RFC8444], [RFC8401], [I-D.ietf-bier-ospfv3-extensions], or [I-D.ietf-bier-lsr-non-mpls-extensions], and¶
Implementation of non-zero BAR values and¶
any kind of tunneling technology that can be viewed as an adjacency in IGP.¶
BAR allows for multicast and unicast traffic to follow different paths if necessary in case such a behavior is desired operationally.¶
BAR could take into accounts different limitations like e.g. maximum possible fan-out degree on nodes or inter-dependency of sub-domains in same BIER domain.¶
Normal IGP computation can be used easily to compute BAR BIER nexthops while preserving all unicast node and link-protection schemes.¶
Reconfiguring BAR preconditions the touching of all participating BFR.¶
BAR can allow to manage "partial BFR" routers, i.e. routers where only a subset of interfaces is BIER capable if additional information is advertised with BIER sub-TLVs.¶
All interfaces on BFRs MUST be capable of BIER forwarding unless the static tunnels can be "homed" on BIER capable interfaces only.¶
Ultimately, the according BIRTs and BIFTs can be precomputed by an off-line controller via any algoirthm desirable (in a sense similar to Section 4 but being able to take other metrics and constraints in the computation than distributed by IGP possibly) and downloaded.¶
Controller based solution can take into account many constraints and metrics that are not distributed network-wide such as provisioning constraints depending on time of day.¶
Centralized cntroller computation cannot normally react quickly to
node or link failures due to delays involved. It is possible that
a centralized computation precomputes and installs according link-
and node-protection BIER next-hops and installs those in the
forwarding path. Depending on delays two set of tables may be
necessary where after download to all routers a fast switch-over
is performed to minimize holes and traffic losses.¶
Consider a scenario where BIER is used as underlay for overlay services like MVPN/EVPN [RFC6514] [RFC7432], where the PEs would need to be BFIRs/BFERs and encapsulate/decapsulate BIER packets. The migration/brownfield solutions described in previous sections are all for routers that cannot forward BIER traffic, and won't help if a PE cannot encapsulate/decapsulate BIER packets.¶
[I-D.ietf-bier-php] specifies a solution where an egress PE would participate in BIER flow overlay signaling and BIER signaling, but request its upstream BFRs to pop the BIER header so that it would only receive the payload without the BIER header.¶
Additional PHP-request in the BIER signaling¶
Upstream-assgined service labels cannot be used, because an egress PE cannot determine which ingress PE sent the packets¶
Ingress PEs must be able to send BIER packets, or they must rely on some other BIER-capable helper PEs to relay traffic, as specified in [RFC7024] for MVPN and [I-D.ietf-bess-evpn-virtual-hub] or [RFC9574] for EVPN.¶
A router requesting PHP behaves as BFER, i.e., participating in BIER and flow overlay signaling even though it does not do BIER forwarding (because its upstream BFRs remove the BIER header from the traffic destined to this router).¶
A BFR treats a BFER requesting PHP as BIER-incapable for transit traffic, and deliver traffic destined to the BFER with BIER header popped.¶
None.¶
General BIER security considerations apply and this document does not introduce any new security relevant topics.¶
Controller based solutions may introduce new security considerations.¶