Internet-Draft BIER Brownfield July 2024
Zhang, et al. Expires 2 January 2025 [Page]
Workgroup:
bier
Internet-Draft:
draft-zzhang-bier-brownfield-options-00
Published:
Intended Status:
Informational
Expires:
Authors:
Z. Zhang
Juniper Networks
A. Przygienda
Juniper Networks
Z. Zhang
ZTE

BIER Brownfield Frameworks

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.

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

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

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.

  • 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

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.

  • 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.

5.1. Preconditions

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

  • 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.

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.

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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8444>.
[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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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 in Progress, Internet-Draft, draft-ietf-bier-tether-05, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9574>.

Authors' Addresses

Zhaohui Zhang
Juniper Networks
Antoni Przygienda
Juniper Networks
Zheng Zhang
ZTE