]> Juniper Networks

zzhang@juniper.net

Arrcus

ice@braindump.be

ZTE

zhang.zhen@zte.com.cn

Cisco Systems

mankamis@cisco.com

Futurewei

Huaimo.chen@futurewei.com

Routing BIER Working Group BIER, anycast 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.

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

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.

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.

Specification This document updates , , , , and 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.

Security Considerations This document does not introduce any new security concerns besides what has been discussed in or what is associated with anycast.

This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document. This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. Cisco Systems, Inc. Cisco Systems, Inc. Individual Contributor Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER architecture uses MPLS or other encapsulation to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. The use of multiple encapsulation types is outside the scope of this document. Huawei Huawei Individual Cisco Systems Juniper Networks. Huawei Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. This document specifies the required extensions to the IS-IS, OSPFv2 and OSPFv3 protocols for supporting BIER in non-MPLS networks using BIER non-MPLS encapsulation. Midea Group Huawei Arrcus, Inc. Individual Juniper Juniper Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information.