Internet-Draft | BGP Extensions for BIER | October 2022 |
Xu, et al. | Expires 14 April 2023 | [Page] |
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 14 April 2023.¶
Copyright (c) 2022 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.¶
Bit Index Explicit Replication (BIER) [RFC8279] 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. More specifically, in this document, we define a new optional, non- transitive BGP attribute, referred to as the BIER attribute, to convey the BIER-specific information such as BIER Forwarding Router identifier (BFR-id), BitString Length (BSL) and so on. In addition, this document specifies procedures to prevent the BIER attribute from "leaking out" of a BIER domain.¶
These extensions are applicable in those multi-tenant data centers where BGP instead of IGP is used as an underlay [RFC7938]. These extensions may also be applicable to other BGP based network scenarios, e.g., as described in [I-D.ietf-bier-multicast-as-a-service].¶
This memo makes use of the terms defined in [RFC4271] and [RFC8279].¶
This draft defines a new optional, transitive BGP path attribute, referred to as the BIER attribute. This attribute can be attached to a BGP UPDATE message by the originator so as to indicate the BIER- specific information of a particular BFR which is identified by the /32 or /128 address prefix contained in the NLRI. In other words, if the BIER path attribute is present, the NLRI is treated by BIER as a "BFR-prefix". When creating a BIER attribute, a BFR needs to include one BIER TLV for every Sub-domain that it supports. The attribute type code for the BIER Attribute is TBD. The value field of the BIER Attribute contains one or more BIER TLV as shown in Figure 1.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain | BFR-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................¶
The BIER MPLS Encapsulation sub-TLV matches the OSPFv2 "BIER MPLS Encapsulation sub-TLV" as specified in Section 2.2 of [RFC8444]. It MAY appear multiple times in the BIER TLV.¶
The following is copied verbatim from that section:¶
The BIER MPLS Encapsulation Sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD1 (To be assigned by IANA). Length: 8 octets Max SI: A 1-octet field encoding the maximum Set Identifier (SI) (see Section 1 of [RFC8279]) used in the encapsulation for this BIER sub-domain for this BitString length. Label: A 3-octet field, where the 20 rightmost bits represent the first label in the label range. The 4 leftmost bits MUST be ignored. BS Len (BitString Length): A 4-bit field encoding the supported BitString length associated with this BFR-prefix. The values allowed in this field are specified in Section 2 of [RFC8296]. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. The "label range" is the set of labels beginning with the Label and ending with (Label + (Max SI)). A unique label range is allocated for each BitString length and sub-domain-id. These labels are used for BIER forwarding as described in [RFC8279] and [RFC8296]. The size of the label range is determined by the number of SIs (Section 1 of [RFC8279]) that are used in the network. Each SI maps to a single label in the label range: the first label is for SI=0, the second label is for SI=1, etc. If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored. If the BitString length is set to a value that does not match any of the allowed values specified in [RFC8296], the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored. If the same BitString length is repeated in multiple BIER MPLS Encapsulation Sub-TLVs inside the same BIER TLV, the whole BIER TLV containing the conflicts MUST be ignored. Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised by the same BFR MUST NOT overlap. If an overlap is detected, all BIER TLVs advertised by such a router MUST be ignored.¶
Similar to the concept in [I-D.ietf-bier-lsr-non-mpls-extensions], the BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsulation. It matches the OSPFv2 BIER non-MPLS Encapsulation sub TLV as specified in Section 3.2 of [I-D.ietf-bier-lsr-non-mpls-extensions].¶
The following are copied verbatim from that section. Note to RFC Editor: the following copied text must match the final text in the RFC for [I-D.ietf-bier-lsr-non-mpls-extensions].¶
The non-MPLS Encapsulation Sub-TLV MAY appear multiple times within a single BIER TLV. If the same BitString length is repeated in multiple BIER non-MPLS encapsulation Sub-TLVs inside the same BIER TLV, the BIER TLV MUST be ignored. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | BIFT-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD2 (To be assigned by IANA). Length: 8 Max SI: A 1 octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279]) used in the encapsulation for this BIER subdomain for this BitString length. The first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. If the BIFT-id associated with the Maximum Set Identifier exceeds the 20-bit range, the sub-TLV MUST be ignored. BIFT-id: A 3-octet field, where the 20 rightmost bits represent the first BIFT-id in the BIFT-id range. The 4 leftmost bits MUST be ignored. BitString Length (BS Len): A 4 bit field encoding the bitstring length (as per [RFC8296]) supported for the encapsulation. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception. The "BIFT-id range" is the set of 20-bit values beginning with the BIFT-id and ending with (BIFT-id + (Max SI)). These BIFT-id's are used for BIER forwarding as described in [RFC8279] and [RFC8296]. The size of the BIFT-id range is determined by the number of SI's (Section 1 of [RFC8279]) that are used in the network. Each SI maps to a single BIFT-id in the BIFT-id range: the first BIFT-id is for SI=0, the second BIFT-id is for SI=1, etc. If the BIFT-id associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV containing the error MUST be ignored. BIFT-id ranges within all the BIER non-MPLS Encapsulation sub- TLVs advertised by the same BFR MUST NOT overlap. If the overlap is detected, the advertising router MUST be treated as if it did not advertise any BIER non-MPLS encapsulation sub-TLVs. However the BIFT-id ranges may overlap across different encapsulation types and is allowed. As an example, the BIFT-id value in the non-MPLS encapsulation sub-TLV may overlap with the Label value in the Label range in BIER MPLS encapsulation sub-TLV ([RFC8444] and is allowed.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nexthop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute to its own BIER prefix NLRI. The BIER attribute MUST include one BIER TLV for each BIER sub-domain that it supports. Each BIER TLV MUST include an MPLS or non-MPLS Encapsulation sub-TLV, and SHOULD include a BIER Nexthop sub-TLV with the Nexthop set to the BIER prefix. If the BIER Nexthop sub-TLV is not included, the BIER prefix will be used by receiving BFRs as the BIER nexthop when calculating BIFT.¶
A BFR/BFER MAY attach a BIER proxy range sub-TLV [I-D.ietf-bier-prefix-redistribute] in the BIER TLV. In this case it MUST attach a BIER attribute to its own BIER prefix NLRIs. Other than this case, a BFR that is not a BFER (i.e., its BFR-ID is 0) SHOULD NOT attach a BIER attribute to its own BIER prefix NLRIs (if a BIER attribute is attached it will not get used anyway).¶
When a BFR re-advertises a BGP NLRI with a BIER attribute, it SHOULD set/update the BIER Nexthop sub-TLV to use its own BIER prefix, in which case it MUST replace the MPLS or non-MPLS Encapsulation sub-TLV with its own, i.e., as if the BFR is attaching the encapsulation sub-TLV for its own BIER prefix. If it does not update the BIER Nexthop sub-TLVs, it MUST NOT update MPLS or non-MPLS Encapsulation sub-TLV, and the consequence is explained in the next section.¶
Since the BIER attribute is an optional, transitive BGP path attribute, a non-BFR BGP speaker could still advertise the received route with a BIER attribute.¶
For each sub-domain, a BFR calculates the corresponding BIFTs by going through the BIER prefixes whose BIER attribute includes a BIER TLV for the sub-domain. For a non-zero BFR-id in the BIER TLV, or for each BFR-id in the BIER Proxy Range sub-TLV in the BIER TLV of a BIER prefix, a BIFT entry is created or updated. The entry's BFR Neighbor (BFR-NBR) [RFC8279] is the Nexthop in the BIER Nexthop sub-TLV (or the BIER prefix itself if the sub-TLV is not present). The BIER label or BIFT-id for the entry is derived from the Label Range in the MPLS Encapsulation sub-TLV or from the BIFT-id Range in the non-MPLS Encapsulation sub-TLV.¶
BIER traffic is sent to the BFR-NBR either natively (BIER header directly follows a layer 2 header) if the BFR-NBR is directly connected, or via a tunnel otherwise. Notice that, if a non-BFR BGP speaker re-advertises a BIER prefix (in this case it can not update the BIER attribute since it is not capable), or if a BFR BGP speaker re-advertises a BIER prefix without updating the BIER Nexthop sub-TLV, the BFR receiving the prefix will tunnel BIER traffic - the BGP speaker re-advertising the BIER prefix will not see the BIER traffic for the BIER prefix.¶
It's assumed by this document that the BIER domain is aligned with an Administrative Domain (AD) which may be composed of multiple ASes (either private or public ASes). Use of the BIER attribute in other scenarios is outside the scope of this document.¶
A boundary router of the AD that supports the BIER attribute MUST support a per-EBGP-session/group policy, that indicates whether the attribute is allowed. If it is not allowed, the BIER attribute MUST NOT be sent to any EBGP peer of the session/group, and the BIER attribute received from the peer MUST be treated exactly as if it were an unrecognized non-transitive attribute. That is, "it MUST be quietly ignored and not passed along to other BGP peers".¶
Thanks a lot for Eric Rosen and Peter Psenak for their valuable comments on this document.¶
IANA is requested to assign a codepoint in the "BGP Path Attributes" registry to the BIER attribute.¶
IANA is requested to create a registry for "BGP BIER Attribute Types" and a registry for "BGP BIER TLV sub-TLV Types". The type field for both registry consists of two octets, with possible values from 1 to 655355 (the value 0 is reserved). The allocation policy for this field is to be "First Come First Serve".¶
Three initial values are to be allocated from the "BGP BIER TLV sub-TLV Types" for MPLS Encapsulation, non-MPLS Encapsulation, and BIER Nexthop sub-TLV respectively.¶
This document introduces no new security considerations beyond those already specified in [RFC4271] and [RFC8279].¶
This document has the following contributors:¶
Zheng Zhang ZTE zhang.zheng@zte.com.cn¶