Internet-Draft BGP Extensions for BIER June 2024
Xu, et al. Expires 5 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-ietf-bier-idr-extensions-11
Published:
Intended Status:
Standards Track
Expires:
Authors:
X.X. Xu
China Mobile
M.C. Chen
Huawei
K.P. Patel
Arrcus, Inc.
I.W. Wijnands
Individual
A.P. Przygienda
Juniper
Z. Zhang, Ed.
Juniper

BGP Extensions for BIER

Abstract

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 per-tree multicast states. Some BIER-specific information and state, which are only in proportion to the network but not per-tree, do need to be advertised, calculated, and maintained. This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisement.

Requirements Language

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.

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 5 December 2024.

1. Introduction

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 per-tree multicast states. This document describes BGP extensions for advertising the BIER-specific information and the methods for calculating BIER forwarding states with this 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.

2. Terminology

This document makes use of the terms defined in [RFC4271] and [RFC8279]. Some terminologies are listed below for convenience.

BIER: Bit Indexed Explicit Replication

BFR: BIER Forwarding Router

BFER: BIER Forwarding Egress Router

BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub-domain to which it belongs. It is recommended that the BFR-prefix be a loopback address of the BFR.

3. BIER Path Attribute

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 for NLRIs of AFI 1/2 and SAFI 1/2/4 so as to indicate the BIER-specific information of a particular BFR identified by the /32 or /128 host address prefix contained in the NLRI, or a set of BFERs covered by a non-host address prefix [I-D.ietf-bier-prefix-redistribute]. In other words, if the BIER path attribute is present, the NLRI is treated by BIER as a "BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside the scope of this document.

The BIER path attribute is encoded in the TLV format shown in the following figure.


   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                        Value (variable)                       ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1

The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of zero). The TLV is not padded to 4-octet alignment. Unknown and unsupported types MUST be preserved and propagated within both the NLRI and the BGP-LS Attribute. The presence of unknown or unexpected TLVs MUST NOT result in the NLRI or the BGP-LS Attribute being considered malformed.

When creating a BIER attribute, a BFR needs to include one BIER TLV for every Sub-domain that the prefix belongs to. 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 2.


       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 = 1            |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Sub-domain   |            BFR-ID             |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                                                               ~
       |                           Sub-TLVs                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................

Figure 2
  • Type: 1.

  • Length: Two octets encoding the length in octets of the Value part.

  • Sub-domain: a one-octet field encoding the sub-domain ID corresponding to the BFR-ID.

  • BFR-ID: a two-octet field encoding the BFR-ID.

  • Sub-TLVs: contains one or more sub-TLV.

The BIER TLV MAY appear multiple times in the BIER Path Attribute, one for each sub-domain. There MUST be no more than one BIER TLV with the same Sub-domain value; if there is, the entire BIER Path Attribute MUST be ignored.

A BIER TLV may have sub-TLVs, which may have their own sub-TLVs. All those are referred to as sub-TLVs and share the same Type space, regardless of the level.

3.1. BIER MPLS Encapsulation sub-TLV

The BIER MPLS Encapsulation sub-TLV has the following format. It MAY appear multiple times in the BIER TLV.


   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 = 2            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |             Label                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  2

   Length:  4 or other values (depending on sub-TLVs)

   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.

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

   Label:  A 20-bit value representing the first label in the label range.

   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 same BitString length is repeated in multiple BIER MPLS
   Encapsulation Sub-TLVs inside the same BIER TLV, all BIER MPLS
   Encapsulation Sub-TLVs in the BIER TLV 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 MPLS Encapsulation Sub-TLVs advertised by the BFR MUST be ignored.

3.2. BIER Non-MPLS Encapsulation sub-TLV

The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsulation and has the following format. It 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 = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS LEN |                  BIFT-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  3.

   Length:  4 or other values (depending on sub-TLVs).

   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 20-bit field representing the first BIFT-id in the BIFT-id
      range.

   BitString Length (BS Len):  A 4 bit field encoding the
      bitstring length (as per [RFC8296]) supported for the encapsulation.

   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 an overlap is
   detected, all the BIER non-MPLS Encapsulation sub-TLV advertised
   by the BFR MUST be ignored. 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.

3.3. BIER Nexthop sub-TLV

       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 = 4           |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Nexthop                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3
  • Type: 4

  • Length: 4 if the Nexthop is IPv4 address and 16 if the Nexthop is IPv6 address

  • Nexthop: 4 or 16 octets of IPv4/IPv6 address

The BIER Nexthop sub-TLV MAY be included in the MPLS or non-MPLS Encapsulation sub-TLV as well as in the top level BIER TLV. It is used when calculating BIFT entries, as described in Section 5 and illustrated in Section 6.

4. Originating/Propagating/Updating BIER Attribute

The use of BIER attribute with a non-host BFR-prefix NLRI is covered in [I-D.ietf-bier-prefix-redistribute].

A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute to its own host BFR-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 and/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.

When a BGP speaker receives an update with the BIER path attribute, the syntactic validation of the attribute is done regardless if the speaker is a BFR or not, and appropriate action is taken, e.g., performing an "attribute discard" action [RFC7606] about the BIER attribute. If it is a BFR, then semantics validation of the BIER path attribute is done. If the validation passes, BIFT entries are calculated as described in Section 5. Otherwise, some or all BIER TLVs MUST be ignored and not re-advertised further. However, as long as the syntactic validation of the BIER path attribute passes, the route is useable for non-BIER purposes.

When a BFR re-advertises a BGP NLRI with a BIER attribute, for the sub-domains that this BFR supports, in the corresponding BIER TLV 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. If it does not support a sub-domain, it MUST NOT update the corresponding BIER TLV.

It's possible that the BFR supports some but not all BSLs in the received MPLS or non-MPLS Encapsulation sub-TLVs. After updating the BIER Nexthop sub-TLV in the top BIER TLV to itself, for the BSLs that it does support, the BFR MUST remove the BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation sub-TLVs. For the BSLs that it does not support, it MUST not update those Encapsulation sub-TLVs except that if a BIER Nexthop sub-TLV is not included in the Encapsulation sub-TLV, the received BIER Nexthop sub-TLV in the top BIER TLV MUST be copied into the Encapsulation sub-TLV. All impacted length fields (e.g., the Encapsulation sub-TLV Length, the top level BIER TLV Length) MUST be updated accordingly.

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.

Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in the same sub-domain. If a duplication is detected, the receiving BFR MUST NOT use it for BIFT calculation for the sub-domain and an error SHOULD be logged. The BFR SHOULD discard the BIER attribute that contains the duplicate BFR-ID.

5. BIFT Calculation with BGP Signaling

As pointed out in [RFC8279], BIFTs are derived from the unicast FIB by adding BIER-specific information.

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, a BIFT entry is created or updated. The entry's BFR Neighbor (BFR-NBR) [RFC8279] is the Nexthop in the BIER Nexthop sub-TLV in the corresponding Encapsulation sub-TLV, or in the top level BIER TLV if the Encapsulation sub-TLV does not have a Nexthop sub-TLV. If there is no Nexthop sub-TLV at all, The entry's BFR Neighbor is the BIER prefix itself. 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.

How the tunnel is set up and chosen is outside the scope of this document. It can be any kind of tunnel, e.g., MPLS LSP or IP/GRE, as long as the tunnel header can indicate that the payload is BIER.

6. Example of BIER Nexthop Usage and Handling

Consider a simple topology as follows:


                                      ----- BFER1
                                     /
           BFR1 --- non-BFR --- BFR2 ------ BFER2
                                     \
                                      ----- BFER3

The BFER1/2/3 each advertises a route for its loopback address with a BIER path attribute, listing one BIER TLV for each subdomain that it is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A BIER Nexthop sub-TLV is included in the one from BFER1 but not the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the addresses of BFER2 and BFER3 respectively.

When BFR2 receives the route, it calculates its BIFT entries. Because the route from BFER1 does not include a BIER Nexthop, BFR2 uses BFRer1's BFR-prefix as the nexthop.

When BFR2 re-advertises the routes to the non-BFR, it adds a BIER Nexthop sub-TLV to the BFER1 route, and updates the BIER Nexthop sub-TLV in the BFER2/3 routes, all encoding BFR2's own address. It also updates the MPLS Encapsulation sub-TLV to encode its own labels.

When the non-BFR receives the routes, since it does not support BIER, no BIER-specific action is taken and the routes are re-advertised to BFR1 with the BIER path attribute unchanged.

When BFR1 receives the routes, it calculates the BIFT entries, using BFR2's address encoded in the BIER Nexthop sub-TLV as the nexthop. Because BFR2 is not directly connected, a tunnel must be used.

7. Operational Considerations

It's assumed by this document that the BIER domain [RFC8279] 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 and by default it is NOT 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".

8. Acknowledgements

Thanks a lot for Eric Rosen and Peter Psenak for their valuable comments on this document.

9. IANA Considerations

IANA is requested to assign a codepoint TBD in the "BGP Path Attributes" registry to the BIER attribute.

IANA is requested to create a registry for "BGP BIER TLV and SUB-TLV Types". The type field for the 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" [RFC8126].

Four initial values are to be allocated from the "BGP BIER TLV and Sub-TLV Types" registry as follows:

  • 1: BIER TLV

  • 2: MPLS Encapsulation sub-TLV

  • 3: non-MPLS Encapsulation sub-TLV

  • 4: BIER Nexthop sub-TLV

10. Security Considerations

This document introduces no new security considerations beyond those already specified in [RFC4271] and [RFC8279].

11. Contributors

This document has the following contributors:

Zheng Zhang
ZTE
zhang.zheng@zte.com.cn

12. References

12.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/info/rfc4271>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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>.

12.2. Informative References

[I-D.ietf-bier-prefix-redistribute]
Zhang, Z., Wu, B., Zhang, Z. J., Wijnands, I., Liu, Y., and H. Bidgoli, "BIER Prefix Redistribute", Work in Progress, Internet-Draft, draft-ietf-bier-prefix-redistribute-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-bier-prefix-redistribute-06>.
[RFC7606]
Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, , <https://www.rfc-editor.org/info/rfc7606>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.

Authors' Addresses

Xiaohu Xu
China Mobile
Mach Chen
Huawei
Keyur Patel
Arrcus, Inc.
IJsbrand Wijnands
Individual
Antoni Przygienda
Juniper
Zhaohui Zhang (editor)
Juniper