BIER with Anycast

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

Copyright Notice

Copyright (c) 2023 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.¶

Table of Contents

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

All BFRs need to allow a non-zero BFR-ID advertised with the same BFR-prefix from different BFRs. An operator needs to ensure that all BFRs allow it when the anycast functionality is needed. At the protocol level, there is no need to signal a BFR's capability of allowing this. Signaling the capability will not help backward compatiblity, but existence of BFRs not supporting the enhanced detection procedure will not cause issues other than that the BFERs with anycast BFR-IDs may not receive traffic. The operator needs to upgrade those BFRs if the anycast functionaly is desired, and the required error reporting from those BFRs can help the operator identify the problem.¶

An alternative way of supporting anycast functionality can be via the BIER Proxy Range sub-TLV [I-D.ietf-bier-prefix-redistribute]. A BFER can use the BIER Proxy Range sub-TLV to advertise additional BFR-IDs associated with itself, even though the original intention of the Proxy Range sub-TLV is to advertise BFR-IDs associated with other BFRs but reachable via an ABR/ASBR. The same BFR-ID may appear in multiple Proxy Range sub-TLVs from different advertisers, hence allowing multiple BFERs to advertise the shared BFR-ID.¶

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

3. Security Considerations

This document does not introduce any new security concerns besides what has been discussed in [RFC8279] or what is associated with anycast.¶

Authors' Addresses