BIER with Anycast

Internet-Draft	BIER-anycast	February 2023
Zhang, et al.	Expires 12 August 2023	[Page]

Abstract

BIER architecture currently does not support anycast, in that each BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-ID. BIER signaling protocols also check if there are duplicate BFR-IDs advertised. This document discusses and specifies anycast support with BIER. It updates RFC 8279, RFC 8401 and RFC 8444.¶

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 12 August 2023.¶

Copyright Notice

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

1. Introduction

BIER architecture currently does not support anycast, in that each BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-ID. BIER signaling protocols [RFC8401] [RFC8444] require the checking for, and logging of duplicate BFR-IDs in advertisements, and require duplicate BFR-IDs be treated as zero, i.e., those BFRs advertising duplicate BFR-IDs will not be treated as BIER Forwarding Ingress Routers (BFIR) or BIER Forwarding Egress Routers (BFER).¶

However, anycast is widely used in networks and it is desired and feasiable to support anycast addresses as BFR-prefixes, especially for egress protection purposes.¶

In a simple egress protection scenario, a flow overlay node N1 connects to BFER1 and BFER2 that advertise the same anycast BFR-prefix with the same BFR-ID. For traffic that node N1 needs to receive, a BFIR can set the bit corresponding to the BFR-ID in the BitString. Either BFER1 or BFER2 will receive the traffic and deliver to N1 after removing the BIER header. If it is desired for BFER1 to be the primary while BFER2 to be the backup, then BFER2 can advertise with a higher cost.¶

                         +-----+
+----+                   |BFER1|_________+--+
|BFIR|                   +-----+        /|N1|
+----+                   +-----+_______/ +--+
                         |BFER2|
                         +-----+

In a more complicated scenario, a flow overlay node N1 may connect to BFER1 and BFER2, while another node N2 may connect to BFER2 and BFER3. In this case, BFER1 and BFER2 need to advertise an anycast BFR-prefix1 while BFER2 and BFER3 need to advertise another anycast BFR-prefix2.¶

                         +-----+
                         |BFER1|_________+--+
                         +-----+        /|N1|
 +----+                  +-----+_______/ +--+
 |BFIR|                  |BFER2|_________+--+
 +----+                  +-----+        /|N2|
                         +-----+_______/ +--+
                         |BFER3|
                         +-----+

In this scenario, BFER2 advertises two anycast BFR-prefixes and two corresponding BFR-IDs. Its BIFTs will have two entries for decapsulation with local forwarding. A packet arriving on BFER2 may have both bits set (for the two BFR-IDs corresponding to the two anycast BFR-prefixes), or two copies of the same packet may arrive on BFER2 (each with a different bit of the two bits being set). In both cases, the flow overlay needs to make sure that N1 receives a copy corresponding to one bit while N2 receives a copy corresponding to the other bit. Flow overlay procedures that may be used/needed for various protection scenarios will be specified in a separate document.¶

Since each unique BFR-prefix needs a unique BFR-ID that takes one bit position in the BitString, a network designer should minimize the number of anycast BFR-prefixes. Limiting egress protection to the first scenario where flow overlay nodes are uniformly connected is recommended.¶

In both example scenarios above, there is no need for the BFERs to advertise a non-anycast BFR-prefixes. Of course, there may be scenarios where both anycast and non-anycast BFR-prefixes are advertised by a BFER.¶

2. Specification

This document updates [RFC8279], [RFC8401], [RFC8444], [I-D.ietf-bier-ospfv3-extensions], [I-D.ietf-bier-lsr-non-mpls-extensions] and [I-D.ietf-bier-idr-extensions] to allow BFERs advertise anycast addresses as BFR-prefixes.¶

When a BIER signaling protocol checks for and logs duplicated BFR-IDs in routing advertisements, only the same BFR-ID advertised with different BFR-prefixes is considered as duplicate. The same BFR-prefix MAY be advertised by different BFRs, but they MUST all advertise the same BFR-ID.¶

It is RECOMMENDED that only BFERs advertises anycast BFR-prefixes. A transit BFR (with BFR-ID 0) SHOULD NOT advertise anycast BFR-prefixes, though otherwise the only consequence is additional useless advertisement.¶

A BFER MAY advertise one non-anycast BFR-prefix and MAY advertise one or more anycast BFR-prefixes. Multiple BFERs MAY advertise the same anycast BFR-prefix. The same anycast BIER-prefix MUST be advertised with the same non-zero BFR-ID.¶

Each BFR-prefix in a BIER sub-domain MUST have a unique BFR-ID if it is not zero.¶

A BFER may be a BFIR at the same time. If a BFIR advertises one or more anycast BFR-prefixes, it MUST uses the BFD-ID associated with its non-anycast BFR-prefix in the BIER header that it imposes, unless it is ok to associate the packet with any of the BFIRs having the same anycast BFR-prefix whose BFR-ID is used in the BIER header.¶

4. Normative References

[I-D.ietf-bier-idr-extensions]: Xu, X., Chen, M., Patel, K., Wijnands, I., Przygienda, T., and Z. J. Zhang, "BGP Extensions for BIER", Work in Progress, Internet-Draft, draft-ietf-bier-idr-extensions-08, 11 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-bier-idr-extensions-08>.
[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-01, 19 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-bier-lsr-non-mpls-extensions-01>.
[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>.
[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>.
[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>.
[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>.