BIER Brownfield Frameworks
draft-zzhang-bier-brownfield-options-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhaohui (Jeffrey) Zhang , Tony Przygienda , Zheng Zhang | ||
| Last updated | 2024-07-01 | ||
| Replaces | draft-przygienda-bier-migration-options | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zzhang-bier-brownfield-options-00
bier Z. Zhang
Internet-Draft A. Przygienda
Intended status: Informational Juniper Networks
Expires: 2 January 2025 Z. Zhang
ZTE
1 July 2024
BIER Brownfield Frameworks
draft-zzhang-bier-brownfield-options-00
Abstract
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.
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 2 January 2025.
Copyright Notice
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.
Zhang, et al. Expires 2 January 2025 [Page 1]
Internet-Draft BIER Brownfield July 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. 'Naked' MT . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 3
3. RFC8279 Section 6.9 . . . . . . . . . . . . . . . . . . . . . 4
3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 5
4. BIER Tethering . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 6
5. BIER Specific Algorithm Based Solutions . . . . . . . . . . . 6
5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 7
6. Controller Based Solutions . . . . . . . . . . . . . . . . . 7
6.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 8
7. BIER PHP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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
Zhang, et al. Expires 2 January 2025 [Page 2]
Internet-Draft BIER Brownfield July 2024
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.
This document uses terminology defined in [RFC8279].
2. 'Naked' MT
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.
2.1. Preconditions
* 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.
2.2. Properties
* 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.
Zhang, et al. Expires 2 January 2025 [Page 3]
Internet-Draft BIER Brownfield July 2024
* 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.
3. RFC8279 Section 6.9
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.
3.1. Preconditions
* BIER IGP signalling via [RFC8444], [RFC8401],
[I-D.ietf-bier-ospfv3-extensions], or
[I-D.ietf-bier-lsr-non-mpls-extensions], and
Zhang, et al. Expires 2 January 2025 [Page 4]
Internet-Draft BIER Brownfield July 2024
* 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.
3.2. Properties
* 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.
Zhang, et al. Expires 2 January 2025 [Page 5]
Internet-Draft BIER Brownfield July 2024
* Each change in dynamic tunnel signalling (such as LDP) may lead to
recomputation of BIFT entries.
4. BIER Tethering
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.
4.1. Preconditions
The same as in Section 3, plus signaling as specified in
[I-D.ietf-bier-tether].
4.2. Properties
* 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.
5. BIER Specific Algorithm Based Solutions
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.
Zhang, et al. Expires 2 January 2025 [Page 6]
Internet-Draft BIER Brownfield July 2024
5.1. Preconditions
* 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.
5.2. Properties
* 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.
6. Controller Based Solutions
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.
6.1. Preconditions
* Controller computing BIRTs and/or BIFTs and downloading them into
all BIER nodes and
Zhang, et al. Expires 2 January 2025 [Page 7]
Internet-Draft BIER Brownfield July 2024
* Preferrably signalling of a special BAR value on each router to
ensure that it is configured to use the according controller
downloaded tables.
6.2. Properties
* 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.
7. BIER PHP
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.
7.1. Preconditions
* 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.
Zhang, et al. Expires 2 January 2025 [Page 8]
Internet-Draft BIER Brownfield July 2024
7.2. Properties
* 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.
8. IANA Considerations
None.
9. Security Considerations
General BIER security considerations apply and this document does not
introduce any new security relevant topics.
Controller based solutions may introduce new security considerations.
10. Normative References
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
Extensions for Bit Index Explicit Replication (BIER)",
RFC 8444, DOI 10.17487/RFC8444, November 2018,
<https://www.rfc-editor.org/info/rfc8444>.
Zhang, et al. Expires 2 January 2025 [Page 9]
Internet-Draft BIER Brownfield July 2024
[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
Zhang, "Bit Index Explicit Replication (BIER) Support via
IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>.
[I-D.ietf-bier-ospfv3-extensions]
Psenak, P., Nainar, N. K., and I. Wijnands, "OSPFv3
Extensions for BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-ospfv3-extensions-07, 1 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
ospfv3-extensions-07>.
[I-D.ietf-bier-lsr-non-mpls-extensions]
Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z.
J., and J. Xie, "LSR Extensions for BIER non-MPLS
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-bier-lsr-non-mpls-extensions-03, 7 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
lsr-non-mpls-extensions-03>.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, DOI 10.17487/RFC3906, October 2004,
<https://www.rfc-editor.org/info/rfc3906>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036,
DOI 10.17487/RFC3036, January 2001,
<https://www.rfc-editor.org/info/rfc3036>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[I-D.ietf-bier-tether]
Zhang, Z. J., Warnke, N., Wijnands, I., and D. O. Awduche,
"Tethering A BIER Router To A BIER incapable Router", Work
Zhang, et al. Expires 2 January 2025 [Page 10]
Internet-Draft BIER Brownfield July 2024
in Progress, Internet-Draft, draft-ietf-bier-tether-05, 16
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-tether-05>.
[RFC9272] Zhang, Z., Przygienda, T., Dolganow, A., Bidgoli, H.,
Wijnands, IJ., and A. Gulko, "Underlay Path Calculation
Algorithm and Constraints for Bit Index Explicit
Replication (BIER)", RFC 9272, DOI 10.17487/RFC9272,
September 2022, <https://www.rfc-editor.org/info/rfc9272>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[I-D.ietf-bier-php]
Zhang, Z. J., "BIER Penultimate Hop Popping", Work in
Progress, Internet-Draft, draft-ietf-bier-php-11, 6
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-php-11>.
[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013,
<https://www.rfc-editor.org/info/rfc7024>.
[I-D.ietf-bess-evpn-virtual-hub]
Patel, K., Sajassi, A., Drake, J., Zhang, Z. J., and W.
Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
hub-00, 26 January 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-virtual-hub-00>.
[RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and
A. Sajassi, "Optimized Ingress Replication Solution for
Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574,
May 2024, <https://www.rfc-editor.org/info/rfc9574>.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
Zhang, et al. Expires 2 January 2025 [Page 11]
Internet-Draft BIER Brownfield July 2024
Email: zzhang@juniper.net
Antoni Przygienda
Juniper Networks
Email: prz@juniper.net
Zheng Zhang
ZTE
Email: zhang.zheng@zte.com.cn
Zhang, et al. Expires 2 January 2025 [Page 12]