BGP Extensions for BIER
draft-ietf-bier-idr-extensions-16
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Xiaohu Xu , Mach Chen , Keyur Patel , IJsbrand Wijnands , Tony Przygienda , Zhaohui (Jeffrey) Zhang | ||
| Last updated | 2024-12-03 (Latest revision 2024-11-22) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
by Brian Haberman
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Ran Chen | ||
| Shepherd write-up | Show Last changed 2023-03-06 | ||
| IESG | IESG state | IESG Evaluation | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has enough positions to pass. |
||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | zzhang@juniper.net, chen.ran@zte.com.cn | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-bier-idr-extensions-16
Network Working Group X.X. Xu
Internet-Draft China Mobile
Intended status: Standards Track M.C. Chen
Expires: 6 June 2025 Huawei
K.P. Patel
Arrcus, Inc.
I.W. Wijnands
Individual
A.P. Przygienda
Z. Zhang, Ed.
Juniper
3 December 2024
BGP Extensions for BIER
draft-ietf-bier-idr-extensions-16
Abstract
Bit Index Explicit Replication (BIER) is a new multicast forwarding
architecture that 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 in a single
Administrative Domain.
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/.
Xu, et al. Expires 6 June 2025 [Page 1]
Internet-Draft BGP Extensions for BIER December 2024
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 6 June 2025.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 4
3.1. BIER MPLS Encapsulation sub-TLV . . . . . . . . . . . . . 5
3.2. BIER Non-MPLS Encapsulation sub-TLV . . . . . . . . . . . 6
3.3. BIER Nexthop sub-TLV . . . . . . . . . . . . . . . . . . 7
4. Originating/Propagating/Updating BIER Attribute . . . . . . . 8
5. BIFT Calculation with BGP Signaling . . . . . . . . . . . . . 9
6. Example of BIER Nexthop Usage and Handling . . . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Xu, et al. Expires 6 June 2025 [Page 2]
Internet-Draft BGP Extensions for BIER 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. It supports both native and
tunneled BIER forwarding. 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 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. The signaling is to be used
in a single Administrative Domain, and Section 7 specifies procedures
to prevent the BIER attribute from "leaking out" of the 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
BFR-ID: BIER Forwarding Router Identifier
BIFT: BIER Forwarding Table
BIFT-id: BIER Forwarding Table Identifier
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.
NLRI: Network Layer Reachability Information [RFC4271]
AFI: Address Family Identifier [RFC4760]
SAFI: Subsequent Address Family Identifier [RFC4760]
Xu, et al. Expires 6 June 2025 [Page 3]
Internet-Draft BGP Extensions for BIER December 2024
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 (for IPv4) or /128 (for IPv6) 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 as
follows:
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
BIER Attribute. The presence of unknown or unexpected TLVs MUST NOT
result in the NLRI or the BIER 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 shown as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Type: 1.
Xu, et al. Expires 6 June 2025 [Page 4]
Internet-Draft BGP Extensions for BIER December 2024
Length: Two octets encoding the length in octets of the Value
part.
Sub-domain [RFC8279]: a one-octet field encoding the sub-domain ID
corresponding to the BFR-ID.
BFR-ID [RFC8279]: 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: 2 octets. The value is 4 or other (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].
Xu, et al. Expires 6 June 2025 [Page 5]
Internet-Draft BGP Extensions for BIER December 2024
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: 2 octets. The value is 4 or other (depending on sub-
TLVs).
Xu, et al. Expires 6 June 2025 [Page 6]
Internet-Draft BGP Extensions for BIER December 2024
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 that 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
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.
Xu, et al. Expires 6 June 2025 [Page 7]
Internet-Draft BGP Extensions for BIER December 2024
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4
Length: 2 octets. The value is 4 if the Nexthop is IPv4 address
and 16 if the Nexthop is IPv6 address
Nexthop: 4 or 16 octets of IPv4/IPv6 address
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 /32 (for IPv4) or /128 (for IPv6) 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.
Xu, et al. Expires 6 June 2025 [Page 8]
Internet-Draft BGP Extensions for BIER December 2024
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 re-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.
Xu, et al. Expires 6 June 2025 [Page 9]
Internet-Draft BGP Extensions for BIER December 2024
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 Label Switched
Path 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.
Xu, et al. Expires 6 June 2025 [Page 10]
Internet-Draft BGP Extensions for BIER December 2024
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 Autonomous Systems. 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. If a BIER attribute is received from the peer, it
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".
BFR-prefixes are typically loopback addresses on the BFRs. They are
distributed throughout the AD but they do not need to be distributed
outside the AD for the BIER purposes. This is analogous to that
Provider Edge router's loopback addresses are distributed inside the
AD but they do not need to be distributed outside the AD.
8. 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 in the BGP Parameters registry
group for "BGP BIER TLV and SUB-TLV Types". The type field for the
registry consists of two octets, with possible values from 0 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
Xu, et al. Expires 6 June 2025 [Page 11]
Internet-Draft BGP Extensions for BIER December 2024
9. Security Considerations
This document introduces no new security considerations beyond those
already discussed in [RFC4271] and [RFC8279] and the operational
considerations (Section 7) of this document.
10. Contributors
This document has the following contributors:
Zheng Zhang
ZTE
zhang.zheng@zte.com.cn
11. Acknowledgements
Thanks a lot for Eric Rosen and Peter Psenak for their valuable
comments on this document.
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, March 1997,
<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, January 2006,
<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,
May 2017, <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, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
Xu, et al. Expires 6 June 2025 [Page 12]
Internet-Draft BGP Extensions for BIER December 2024
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-07, 28 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
prefix-redistribute-07>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[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, August 2015,
<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, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses
Xiaohu Xu
China Mobile
Email: xuxiaohu@cmss.chinamobile.com
Mach Chen
Huawei
Email: mach.chen@huawei.com
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
IJsbrand Wijnands
Individual
Email: ice@braindump.be
Xu, et al. Expires 6 June 2025 [Page 13]
Internet-Draft BGP Extensions for BIER December 2024
Antoni Przygienda
Juniper
Email: prz@juniper.net
Zhaohui Zhang (editor)
Juniper
Email: zzhang@juniper.net
Xu, et al. Expires 6 June 2025 [Page 14]