rfc9793.original   rfc9793.txt 
Network Working Group X.X. Xu Internet Engineering Task Force (IETF) X. Xu
Internet-Draft China Mobile Request for Comments: 9793 China Mobile
Intended status: Standards Track M.C. Chen Category: Standards Track M. Chen
Expires: 22 June 2025 Huawei ISSN: 2070-1721 Huawei
K.P. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
I.W. Wijnands IJ. Wijnands
Individual Individual
A.P. Przygienda T. Przygienda
Z. Zhang, Ed. Z. Zhang, Ed.
Juniper Juniper
19 December 2024 June 2025
BGP Extensions for BIER BGP Extensions for Bit Index Explicit Replication (BIER)
draft-ietf-bier-idr-extensions-19
Abstract Abstract
Bit Index Explicit Replication (BIER) is a multicast forwarding Bit Index Explicit Replication (BIER) is a multicast forwarding
architecture that doesn't require an explicit tree-building protocol architecture that doesn't require an explicit tree-building protocol
and doesn't require intermediate routers to maintain per-tree and doesn't require intermediate routers to maintain per-tree
multicast states. Some BIER-specific information and state, which multicast states. Some BIER-specific information and states, which
are only in proportion to the number of BIER routers but not per- are only in proportion to the number of BIER routers but not per-
tree, do need to be advertised, calculated, and maintained. This tree, do need to be advertised, calculated, and maintained. This
document describes BGP extensions for advertising the BIER document describes BGP extensions for advertising the BIER
information and methods for calculating BIER states based on the information and methods for calculating BIER states based on the
advertisements. advertisements.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9793.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language
3.1. BIER MPLS Encapsulation sub-TLV . . . . . . . . . . . . . 5 3. BIER Path Attribute
3.2. BIER Non-MPLS Encapsulation sub-TLV . . . . . . . . . . . 7 3.1. BIER MPLS Encapsulation Sub-TLV
3.3. BIER Nexthop sub-TLV . . . . . . . . . . . . . . . . . . 8 3.2. BIER Non-MPLS Encapsulation Sub-TLV
4. Originating/Propagating/Updating BIER Attribute . . . . . . . 8 3.3. BIER Nexthop Sub-TLV
5. BIFT Calculation with BGP Signaling . . . . . . . . . . . . . 10 4. Originating/Propagating/Updating the BIER Attribute
6. Example of BIER Nexthop Usage and Handling . . . . . . . . . 10 5. BIFT Calculation with BGP Signaling
7. Operational Considerations . . . . . . . . . . . . . . . . . 11 6. Example of BIER Nexthop Usage and Handling
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Operational Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Contributors
Authors' Addresses
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is a multicast Bit Index Explicit Replication (BIER) [RFC8279] is a multicast
forwarding architecture which doesn't require an explicit tree- forwarding architecture that doesn't require an explicit tree-
building protocol and doesn't require intermediate routers to building protocol and doesn't require intermediate routers to
maintain per-tree multicast states. It supports both direct and maintain per-tree multicast states. It supports both direct and
tunneled BIER forwarding. This document describes BGP extensions for tunneled BIER forwarding. This document describes BGP extensions for
advertising the BIER-specific information and the methods for advertising the BIER information and methods for calculating BIER
calculating BIER forwarding states with this information. More states based on the advertisements. More specifically, in this
specifically, in this document, we define a new optional transitive document, we define a new optional transitive BGP attribute, referred
BGP attribute, referred to as the BIER attribute, to convey the BIER- to as the "BIER attribute", to convey the BIER-specific information
specific information such as BIER Forwarding Router identifier (BFR- such as Bit-Forwarding Router Identifier (BFR-ID), BitStringLength
id), BitString Length (BSL), and so on. The signaling is to be used (BSL), and so on. The signaling is to be used in a single
in a single Administrative Domain, and Section 7 specifies procedures Administrative Domain (AD), and Section 7 specifies procedures to
to prevent the BIER attribute from "leaking out" of the domain. prevent the BIER attribute from "leaking out" of the domain.
2. Terminology 2. Terminology
This document makes use of the terms defined in [RFC4271] and This document makes use of the terminology defined in [RFC4271] and
[RFC8279]. Some terminologies are listed below for convenience. [RFC8279]. Some terms are listed below for convenience.
BIER: Bit Indexed Explicit Replication BIER: Bit Indexed Explicit Replication
BFR: BIER Forwarding Router BFR: Bit-Forwarding Router
BFR-ID: BIER Forwarding Router Identifier BFR-ID: BFR Identifier
BSL: BitStringLength BSL: BitStringLength
BIFT: BIER Forwarding Table BIFT: Bit Index Forwarding Table
BIFT-id: BIER Forwarding Table Identifier BIFT-id: Bit Index Forwarding Table Identifier
BFER: BIER Forwarding Egress Router BFER: Bit-Forwarding Egress Router
BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub- 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 domain to which it belongs. It is recommended that the BFR-prefix
a loopback address of the BFR. be a loopback address of the BFR.
NLRI: Network Layer Reachability Information [RFC4271] NLRI: Network Layer Reachability Information [RFC4271]
AFI: Address Family Identifier [RFC4760] AFI: Address Family Identifier [RFC4760]
SAFI: Subsequent Address Family Identifier [RFC4760] SAFI: Subsequent Address Family Identifier [RFC4760]
2.1. 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.
3. BIER Path Attribute 3. BIER Path Attribute
This specification defines an optional, transitive BGP path This specification defines an optional, transitive BGP path
attribute, referred to as the BIER attribute. This attribute can be attribute, referred to as the "BIER attribute". This attribute can
attached to a BGP UPDATE message by the originator for NLRIs of AFI 1 be attached to a BGP UPDATE message by the originator for NLRIs of
or 2 and SAFI 1,2, or 4 to indicate the BIER-specific information of AFI 1 or 2 and SAFI 1, 2, or 4 to indicate the BIER-specific
a particular BFR identified by the /32 (for IPv4) or /128 (for IPv6) information of a particular BFR identified by the /32 (for IPv4) or
host address prefix contained in the NLRI. The attachment of the /128 (for IPv6) host address prefix contained in the NLRI. The
BIER attribute to non-host address prefixes is not defined by this attachment of the BIER attribute to non-host address prefixes is not
document. It may be specified in the future, for example by defined by this document. It may be specified in the future, for
[I-D.ietf-bier-prefix-redistribute]. example, by [BIER-Prefix-Redistribute].
If the BIER path attribute is present, the NLRI is referred to as a If the BIER path attribute is present, the NLRI is referred to as a
"BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside "BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside
the scope of this document. the scope of this document.
The BIER path attribute is an optional, transitive BGP path attribute The BIER path attribute is an optional, transitive BGP path attribute
with type code TBD and of variable length. The attribute value with type code 41 and of variable length. The attribute value
portion carries BIER TLVs, which are encoded as follows: portion carries BIER TLVs, which are encoded as follows:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value (variable) ~ ~ Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets 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 (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 TLV is not padded to 4-octet alignment. Unknown and unsupported
types MUST be preserved and propagated within the BIER Attribute. types MUST be preserved and propagated within the BIER attribute.
The presence of unknown or unexpected TLVs MUST NOT result in the The presence of unknown or unexpected TLVs MUST NOT result in the
NLRI or the BIER Attribute being considered malformed. NLRI or the BIER attribute being considered malformed.
When creating a BIER attribute, a BFR MUST include one BIER TLV for When creating a BIER attribute, a BFR MUST include one BIER TLV for
every Sub-domain that the prefix belongs to. The attribute type code 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 for the BIER attribute is 41. The value field of the BIER attribute
contains one or more BIER TLV shown as follows: contains one or more BIER TLVs as shown below:
0 1 2 3 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 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 | | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain | BFR-ID | Reserved | | Sub-domain | BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Sub-TLVs | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Type: 1. Type: 1
Length: Two octets encoding the length in octets of the Value Length: 2 octets encoding the length in octets of the Value part.
part.
Sub-domain [RFC8279]: a one-octet field encoding the sub-domain ID Sub-domain: A 1-octet field encoding the sub-domain ID corresponding
corresponding to the BFR-ID. to the BFR-ID (see [RFC8279]).
BFR-ID [RFC8279]: a two-octet field encoding the BFR-ID. BFR-ID: A 2-octet field encoding the BFR-ID (see [RFC8279]).
Reserved: SHOULD be set to 0 on transmission and MUST be ignored Reserved: SHOULD be set to 0 on transmission and MUST be ignored on
on reception. reception.
Sub-TLVs: contains one or more sub-TLV. Sub-TLVs: Contains one or more sub-TLVs.
The BIER TLV MAY appear multiple times in the BIER Path Attribute, 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 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 with the same Sub-domain value; if there is, the entire BIER path
Attribute MUST be ignored. attribute MUST be ignored.
A BIER TLV may have sub-TLVs, which may have their own sub-TLVs. All 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, those are referred to as sub-TLVs and share the same Type space,
regardless of the level. regardless of the level.
3.1. BIER MPLS Encapsulation sub-TLV 3.1. BIER MPLS Encapsulation Sub-TLV
The BIER MPLS Encapsulation sub-TLV has the following format. It MAY The BIER MPLS Encapsulation sub-TLV has the following format. It MAY
appear multiple times in the BIER TLV. appear multiple times in the BIER TLV.
The BIER MPLS Encapsulation Sub-TLV has the following format: The BIER MPLS Encapsulation sub-TLV has the following format:
0 1 2 3 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 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 | | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS Len | Label | | Max SI |BS Len | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs | ~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2 Type: 2
Length: Two octets encoding the length in octets of the Value Length: 2 octets encoding the length in octets of the Value part.
part. The value is 4 or other (depending on sub-TLVs) The value is 4 or other (depending on sub-TLVs).
Max SI: A 1-octet field encoding the maximum Set Identifier (SI) Max SI: A 1-octet field encoding the Maximum Set Identifier (see
(see Section 1 of [RFC8279]) used in the encapsulation for this Section 1 of [RFC8279]) used in the encapsulation for this BIER
BIER sub-domain for this BitString length. sub-domain for this BitString length.
BS Len (BitString Length): A 4-bit field encoding the supported BS Len: BitString Length. A 4-bit field encoding the supported
BitString length associated with this BFR-prefix. The values BitString length associated with this BFR-prefix. The values
allowed in this field are specified in Section 2 of [RFC8296]. allowed in this field are specified in Section 2 of [RFC8296].
Label: A 20-bit value representing the first label in the label Label: A 20-bit value representing the first label in the label
range. range.
The "label range" is the set of labels beginning with the Label and The "label range" is the set of labels beginning with the Label and
ending with (Label + (Max SI)). A unique label range is allocated ending with (Label + (Max SI)). A unique label range is allocated
for each BitString length and sub-domain-id. These labels are used for each BitString length and sub-domain-id. These labels are used
for BIER forwarding as described in [RFC8279] and [RFC8296]. for BIER forwarding, as described in [RFC8279] and [RFC8296].
The size of the label range is determined by the number of SIs 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 (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, to a single label in the label range: the first label is for SI=0,
the second label is for SI=1, etc. the second label is for SI=1, etc.
If the label associated with the Maximum Set Identifier exceeds the If the label associated with the Maximum SI exceeds the 20-bit range,
20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the the BIER MPLS Encapsulation sub-TLV containing the error MUST be
error MUST be ignored. ignored.
If the same BitString length is repeated in multiple BIER MPLS 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 inside the same BIER TLV, all BIER MPLS
Encapsulation Sub-TLVs in the BIER TLV MUST be ignored. Encapsulation sub-TLVs in the BIER TLV MUST be ignored.
Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised Label ranges within all BIER MPLS Encapsulation sub-TLVs advertised
by the same BFR MUST NOT overlap. If an overlap is detected, all by the same BFR MUST NOT overlap. If an overlap is detected, all
BIER MPLS Encapsulation Sub-TLVs advertised by the BFR MUST be BIER MPLS Encapsulation sub-TLVs advertised by the BFR MUST be
ignored. ignored.
3.2. BIER Non-MPLS Encapsulation sub-TLV 3.2. BIER Non-MPLS Encapsulation Sub-TLV
The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS
encapsulation and has the following format. It MAY appear multiple encapsulation and has the following format. It MAY appear multiple
times within a single BIER TLV. If the same BitString length is times within a single BIER TLV. If the same BitString length is
repeated in multiple BIER non-MPLS encapsulation Sub-TLVs inside the repeated in multiple BIER non-MPLS Encapsulation sub-TLVs inside the
same BIER TLV, the BIER TLV MUST be ignored. same BIER TLV, the BIER TLV MUST be ignored.
0 1 2 3 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 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 | | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS LEN | BIFT-id | | Max SI |BS Len | BIFT-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs | ~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3. Type: 3
Length: Two octets encoding the length in octets of the Value Length: 2 octets encoding the length in octets of the Value part.
part. The value is 4 or other (depending on sub-TLVs). The value is 4 or other (depending on sub-TLVs).
Max SI: A 1-octet field encoding the Maximum Set Identifier Max SI: A 1-octet field encoding the Maximum Set Identifier
(Section 1 of [RFC8279]) used in the encapsulation for this BIER (Section 1 of [RFC8279]) used in the encapsulation for this BIER
subdomain for this BitString length. The first BIFT-id is for sub-domain 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 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 associated with the Maximum SI exceeds the 20-bit range, the sub-
range, the sub-TLV MUST be ignored. 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 BS Len: BitString Length. A 4-bit field encoding the BitString
length (as per [RFC8296]) supported for the encapsulation. length (as per [RFC8296]) supported for the encapsulation.
BIFT-id: A 20-bit field representing the first BIFT-id in the BIFT-
id range.
The "BIFT-id range" is the set of 20-bit values beginning with the 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 BIFT-id and ending with (BIFT-id + (Max SI)). These BIFT-ids are
used for BIER forwarding as described in [RFC8279] and [RFC8296]. 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 The size of the BIFT-id range is determined by the number of SIs
(Section 1 of [RFC8279]) that are used in the network. Each SI maps (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 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. SI=0, the second BIFT-id is for SI=1, etc.
If the BIFT-id associated with the Maximum Set Identifier exceeds the If the BIFT-id associated with the Maximum SI exceeds the 20-bit
20-bit range, the BIER non-MPLS Encapsulation sub-TLV containing the range, the BIER non-MPLS Encapsulation sub-TLV containing the error
error MUST be ignored. MUST be ignored.
BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs
advertised by the same BFR MUST NOT overlap. If an overlap is advertised by the same BFR MUST NOT overlap. If an overlap is
detected, all the BIER non-MPLS Encapsulation sub-TLV advertised by detected, all the BIER non-MPLS Encapsulation sub-TLVs advertised by
the BFR MUST be ignored. However, the BIFT-id ranges may overlap the BFR MUST be ignored. However, the BIFT-id ranges may overlap
across different encapsulation types and that is allowed. As an across different encapsulation types and that is allowed. As an
example, the BIFT-id value in the non-MPLS encapsulation sub-TLV may 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 overlap with the Label value in the Label range in the BIER MPLS
encapsulation sub-TLV. Encapsulation sub-TLV.
3.3. BIER Nexthop sub-TLV 3.3. BIER Nexthop Sub-TLV
The BIER Nexthop sub-TLV MAY be included, and MUST NOT be included The BIER Nexthop sub-TLV MAY be included, and it MUST NOT be included
more than once in each of the MPLS or non-MPLS Encapsulation sub-TLV more than once in each of the MPLS or non-MPLS Encapsulation sub-TLVs
as well as the top-level BIER TLV. It is used when calculating BIFT or in the top-level BIER TLV. It is used when calculating BIFT
entries, as described in Section 5 and illustrated in Section 6. entries, as described in Section 5 and illustrated in Section 6.
0 1 2 3 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 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 | | Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nexthop | | Nexthop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4 Type: 4
Length: 2 octets. The value is 4 if the Nexthop is an IPv4 Length: 2 octets. The value is 4 if the Nexthop is an IPv4 address
address and 16 if the Nexthop is an IPv6 address and 16 if the Nexthop is an IPv6 address.
Nexthop: 4 or 16 octets of IPv4/IPv6 address Nexthop: 4 or 16 octets of an IPv4/IPv6 address.
4. Originating/Propagating/Updating BIER Attribute 4. Originating/Propagating/Updating the BIER Attribute
A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute A Bit-Forwarding Egress Router (BFER) MUST attach a BIER attribute to
to its own /32 (for IPv4) or /128 (for IPv6) host BFR-prefix NLRI. its own /32 (for IPv4) or /128 (for IPv6) host BFR-prefix NLRI. The
The BIER attribute MUST include one BIER TLV for each BIER sub-domain 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 that it supports. Each BIER TLV MUST include an MPLS and/or non-MPLS
Encapsulation sub-TLV, and MAY include a BIER Nexthop sub-TLV with Encapsulation sub-TLV and MAY include a BIER Nexthop sub-TLV with the
the Nexthop set to the BIER prefix. If the BIER Nexthop sub-TLV is Nexthop set to the BIER prefix. If the BIER Nexthop sub-TLV is not
not included, the BIER prefix will be used by receiving BFRs as the included, the BIER prefix will be used by receiving BFRs as the BIER
BIER nexthop when calculating BIFT. next hop when calculating BIFT.
When a BFR receives an update with the BIER path attribute, the When a BFR receives an update with the BIER path attribute, the
attribute is parsed with the following validations: attribute is parsed with the following validations:
* Syntactic checking based on the length field of TLVs and sub-TLVs: * Syntactic checking based on the Length field of TLVs and sub-TLVs:
- The total length of BIER TLVs (including the type and length - The total length of BIER TLVs (including the Type and Length
fields) MUST equal to the BIER path attribute length. fields) MUST be equal to the BIER path attribute length.
- The total length of sub-TLVs (including the type and length - The total length of sub-TLVs (including the Type and Length
fields) of a TLV MUST equal to the length of the TLV. fields) of a TLV MUST be equal to the length of the TLV.
* Semantic checking as per Section 3. * Semantic checking as per Section 3.
If the syntactic checking fails, the attribute is considered If the syntactic checking fails, the attribute is considered
malformed and the "attribute discard" action [RFC7606] about the BIER malformed and the "attribute discard" action [RFC7606] for the BIER
attribute MUST be taken. If the semantic checking passes, BIFT attribute MUST be taken. If the semantic checking passes, BIFT
entries are calculated as described in Section 5. Otherwise entries are calculated as described in Section 5. Otherwise (i.e.,
(semantic checking fails), some or all BIER TLVs are ignored, per the if semantic checking fails), some or all BIER TLVs are ignored, per
rules given in Section 3, and if the remaining data permits, BIFT the rules given in Section 3, and if the remaining data permits, BIFT
entries are calculated per Section 5. entries are calculated per Section 5.
When a BFR re-advertises a BGP NLRI with a BIER attribute, for the 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 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 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 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 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 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 update the BIER Nexthop sub-TLVs, it MUST NOT update the MPLS or non-
Encapsulation sub-TLV. If it does not support a sub-domain, it MUST MPLS Encapsulation sub-TLV. If it does not support a sub-domain, it
NOT update the corresponding BIER TLV. MUST NOT update the corresponding BIER TLV.
It's possible that the BFR supports some but not all BitStringLengths It's possible that the BFR supports some but not all BitStringLengths
(BSLs) in the received MPLS or non-MPLS Encapsulation sub-TLVs. (BSLs) in the received MPLS or non-MPLS Encapsulation sub-TLVs.
After setting/updating the BIER Nexthop sub-TLV in the top BIER TLV After setting/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 to itself, for the BSLs that it does support, the BFR MUST remove the
BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation
sub-TLVs. For the BSLs that it does not support: sub-TLVs. For the BSLs that it does not support:
* If a BIER Nexthop sub-TLV is included in the Encapsulation sub- * If a BIER Nexthop sub-TLV is included in the Encapsulation sub-
TLV, it MUST NOT be updated. TLV, it MUST NOT be updated.
* Otherwise, if a BIER Nexthop sub-TLV was included in the received * Otherwise, if a BIER Nexthop sub-TLV is included in the received
BIER TLV, its original value (before changed for supported BSLs by BIER TLV, its original value (before changed for supported BSLs by
this BFR) MUST be copied into the Encapsulation sub-TLV. this BFR) MUST be copied into the Encapsulation sub-TLV.
* Otherwise, a BIER Nexthop sub-TLV MUST be added to the * Otherwise, a BIER Nexthop sub-TLV MUST be added to the
Encapsulation sub-TLV with its value set to the BFR-prefix. Encapsulation sub-TLV with its value set to the BFR-prefix.
All impacted length fields (e.g., the Encapsulation sub-TLV Length, All impacted Length fields (e.g., the Encapsulation sub-TLV Length
the top-level BIER TLV Length) MUST be updated accordingly. and the top-level BIER TLV Length) MUST be updated accordingly.
Since the BIER attribute is an optional, transitive BGP path Since the BIER attribute is an optional, transitive BGP path
attribute, a non-BFR BGP speaker could still re-advertise the attribute, a non-BFR BGP speaker could still re-advertise the
received route with a BIER attribute. received route with a BIER attribute.
Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in 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 the same sub-domain. If a duplication is detected, the receiving BFR
MUST NOT use the BFR-prefixes with the same BFR-ID for BIFT MUST NOT use the BFR-prefixes with the same BFR-ID for BIFT
calculation for the sub-domain and an error SHOULD be logged. calculation for the sub-domain and an error SHOULD be logged.
5. BIFT Calculation with BGP Signaling 5. BIFT Calculation with BGP Signaling
As pointed out in [RFC8279], BIFTs are derived from the unicast FIB As pointed out in [RFC8279], BIFTs are derived from the unicast FIB
by adding BIER-specific information. by adding BIER-specific information.
For each sub-domain, a BFR calculates the corresponding BIFTs by For each sub-domain, a BFR calculates the corresponding BIFTs by
going through the BIER prefixes whose BIER attribute includes a BIER 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 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) 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 [RFC8279] is the Nexthop in the BIER Nexthop sub-TLV in the
corresponding Encapsulation sub-TLV, or in the top-level BIER TLV if 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 the Encapsulation sub-TLV does not have a BIER Nexthop sub-TLV. If
is no Nexthop sub-TLV at all, The entry's BFR Neighbor is the BIER there is no BIER Nexthop sub-TLV at all, the entry's BFR-NBR is the
prefix itself. The BIER label or BIFT-id for the entry is derived BIER prefix itself. The BIER label or BIFT-id for the entry is
from the Label Range in the MPLS Encapsulation sub-TLV or from the derived from the label range in the MPLS Encapsulation sub-TLV or
BIFT-id Range in the non-MPLS Encapsulation sub-TLV. from the BIFT-id range in the non-MPLS Encapsulation sub-TLV.
BIER traffic is sent to the BFR-NBR either directly (BIER header BIER traffic is sent to the BFR-NBR either directly (BIER header
directly follows a layer 2 header) if the BFR-NBR is directly 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 connected or via a tunnel. Notice that, if a non-BFR BGP speaker re-
speaker re-advertises a BIER prefix (in this case it can not update advertises a BIER prefix (in this case, it cannot update the BIER
the BIER attribute since it is not capable), or if a BFR BGP speaker attribute since it is not capable), or if a BFR BGP speaker re-
re-advertises a BIER prefix without updating the BIER Nexthop sub- advertises a BIER prefix without updating the BIER Nexthop sub-TLV,
TLV, the BFR receiving the prefix will tunnel BIER traffic - the BGP the BFR receiving the prefix will tunnel BIER traffic -- the BGP
speaker re-advertising the BIER prefix will not see the BIER traffic speaker re-advertising the BIER prefix will not see the BIER traffic
for the BIER prefix. for the BIER prefix.
How the tunnel is set up and chosen is outside the scope of this 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 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 Path or IP/GRE, as long as the tunnel header can indicate that the
payload is BIER. payload is BIER.
6. Example of BIER Nexthop Usage and Handling 6. Example of BIER Nexthop Usage and Handling
Consider a simple topology as follows: Consider a simple topology as follows:
----- BFER1 ----- BFER1
/ /
BFR1 --- non-BFR --- BFR2 ------ BFER2 BFR1 --- non-BFR --- BFR2 ------ BFER2
\ \
----- BFER3 ----- BFER3
The BFER1/2/3 each advertises a route for its loopback address with a 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 BIER path attribute, listing one BIER TLV for each sub-domain that it
is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV. A
BIER Nexthop sub-TLV is not included in the one from BFER1 but is BIER Nexthop sub-TLV is not included in the one from BFER1 but is
included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes
the BFR-prefix of BFER2 and BFER3 respectively. the BFR-prefix of BFER2 and BFER3, respectively.
When BFR2 receives the route, it calculates its BIFT entries. When BFR2 receives the route, it calculates its BIFT entries.
Because the route from BFER1 does not include a BIER Nexthop, BFR2 Because the route from BFER1 does not include a BIER Nexthop, BFR2
uses BFRer1's BFR-prefix as the nexthop. uses BFR1's BFR-prefix as the next hop.
When BFR2 re-advertises the routes to the non-BFR, it adds a BIER 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- 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 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. updates the MPLS Encapsulation sub-TLV to encode its own labels.
When the non-BFR receives the routes, since it does not support BIER, 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 no BIER-specific action is taken and the routes are re-advertised to
BFR1 with the BIER path attribute unchanged. BFR1 with the BIER path attribute unchanged.
When BFR1 receives the routes, it calculates the BIFT entries, using When BFR1 receives the routes, it calculates the BIFT entries, using
BFR2's address encoded in the BIER Nexthop sub-TLV as the nexthop. BFR2's address encoded in the BIER Nexthop sub-TLV as the next hop.
Because BFR2 is not directly connected, a tunnel must be used. Because BFR2 is not directly connected, a tunnel must be used.
7. Operational Considerations 7. Operational Considerations
It's assumed by this document that the BIER domain [RFC8279] is In this document, it is assumed that the BIER domain [RFC8279] is
aligned with an Administrative Domain (AD) which may be composed of aligned with an Administrative Domain (AD), which may be composed of
multiple Autonomous Systems. Use of the BIER attribute in other multiple Autonomous Systems. Use of the BIER attribute in other
scenarios is outside the scope of this document. scenarios is outside the scope of this document.
BFR-prefixes are typically loopback addresses on the BFRs. They are BFR-prefixes are typically loopback addresses on the BFRs. They are
distributed throughout the AD but they do not need to be distributed distributed throughout the AD, but they do not need to be distributed
outside the AD for the BIER purposes. This is analogous to that outside the AD for the BIER's purposes. This is analogous to the
Provider Edge router's loopback addresses are distributed inside the Provider Edge router's loopback addresses that are distributed inside
AD but they do not need to be distributed outside the AD. the AD, but they do not need to be distributed outside the AD.
If prefixes are distributed outside of the AD with the BIER attribute If prefixes are distributed outside of the AD with the BIER attribute
attached and the neighboring AD also deploys BIER, then the two BIER attached and the neighboring AD also deploying BIER, then the two
domains, which should be independent of each other, may be BIER domains, which should be independent of each other, may be
incorrectly joined together and most likely have conflicting incorrectly joined together and most likely have conflicting
configurations, causing security risks and operational troubles. configurations, causing security risks and operational troubles.
To prevent that, a boundary router of the AD that supports the BIER To prevent that, a boundary router of the AD that supports the BIER
attribute MUST support a per-EBGP-session/group policy, that attribute MUST support a policy based on an External BGP (EBGP)
indicates whether the attribute is allowed and by default it is NOT session/group that indicates whether the attribute is allowed; by
allowed. If it is not allowed, the BIER attribute MUST NOT be sent default, it is NOT allowed. If it is not allowed, the BIER attribute
to any EBGP peer of the session/group. If a BIER attribute is MUST NOT be sent to any EBGP peer of the session/group. If a BIER
received from the peer, it MUST be treated exactly as if it were an attribute is received from the peer, it MUST be treated exactly as if
unrecognized non-transitive attribute. That is, "it MUST be quietly it were an unrecognized non-transitive attribute. That is, it MUST
ignored and not passed along to other BGP peers". be quietly ignored and not passed along to other BGP peers.
8. IANA Considerations 8. IANA Considerations
IANA is requested to assign a codepoint TBD in the "BGP Path IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path
Attributes" registry (https://www.iana.org/assignments/bgp- Attributes" registry <https://www.iana.org/assignments/bgp-
parameters/bgp-parameters.xhtml#bgp-parameters-2) to the BIER parameters> as follows:
attribute.
Value Name Reference +=======+======+===========+
===== ==== ========= | Value | Code | Reference |
TBD BIER This document +=======+======+===========+
| 41 | BIER | RFC 9793 |
+-------+------+-----------+
IANA is requested to create a registry in the BGP Parameters registry Table 1
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].
Five initial values are to be allocated from the "BGP BIER TLV and IANA has created the "BGP BIER TLV and Sub-TLV Types" registry within
Sub-TLV Types" registry as follows: the "Border Gateway Protocol (BGP) Parameters" registry group. The
type field for the registry consists of 2 octets, with possible
values from 0 to 65535 (the value 0 is reserved). The allocation
policy for this field is First Come First Served [RFC8126].
Value Name Reference The five initial values have been allocated as follows:
===== ==== =========
0 Reserved This document +=========+================================+===========+
1 BIER TLV This document | Value | Name | Reference |
2 MPLS Encapsulation sub-TLV This document +=========+================================+===========+
3 non-MPLS Encapsulation sub-TLV This document | 0 | Reserved | RFC 9793 |
4 BIER Nexthop sub-TLV This document +---------+--------------------------------+-----------+
5-65535 Unassigned | 1 | BIER TLV | RFC 9793 |
+---------+--------------------------------+-----------+
| 2 | MPLS Encapsulation sub-TLV | RFC 9793 |
+---------+--------------------------------+-----------+
| 3 | non-MPLS Encapsulation sub-TLV | RFC 9793 |
+---------+--------------------------------+-----------+
| 4 | BIER Nexthop sub-TLV | RFC 9793 |
+---------+--------------------------------+-----------+
| 5-65535 | Unassigned |
+---------+--------------------------------------------+
Table 2
9. Security Considerations 9. Security Considerations
This document introduces no new security considerations beyond those This document introduces no new security considerations beyond those
already discussed in [RFC4271] and [RFC8279] and the operational already discussed in [RFC4271], [RFC8279], and the operational
considerations (Section 7) of this document. considerations (Section 7) of this document.
10. Contributors 10. References
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 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 14, line 5 skipping to change at line 584
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
12.2. Informative References 10.2. Informative References
[I-D.ietf-bier-prefix-redistribute] [BIER-Prefix-Redistribute]
Zhang, Z., Wu, B., Zhang, Z. J., Wijnands, I., Liu, Y., Zhang, Z., Wu, B., Zhang, Z. J., Wijnands, I., Liu, Y.,
and H. Bidgoli, "BIER Prefix Redistribute", Work in and H. Bidgoli, "BIER Prefix Redistribute", Work in
Progress, Internet-Draft, draft-ietf-bier-prefix- Progress, Internet-Draft, draft-ietf-bier-prefix-
redistribute-07, 28 August 2024, redistribute-08, 23 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier- <https://datatracker.ietf.org/doc/html/draft-ietf-bier-
prefix-redistribute-07>. prefix-redistribute-08>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
Thanks to Eric Rosen and Peter Psenak for their valuable comments on
this document.
Contributors
This document has the following contributor:
Zheng (Sandy) Zhang
ZTE
Email: zhang.zheng@zte.com.cn
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
China Mobile China Mobile
Email: xuxiaohu@cmss.chinamobile.com Email: xuxiaohu@cmss.chinamobile.com
Mach Chen Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
IJsbrand Wijnands IJsbrand Wijnands
Individual Individual
Email: ice@braindump.be Email: ice@braindump.be
Antoni Przygienda
Tony Przygienda
Juniper Juniper
Email: prz@juniper.net Email: prz@juniper.net
Zhaohui Zhang (editor) Zhaohui Zhang (editor)
Juniper Juniper
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 115 change blocks. 
266 lines changed or deleted 275 lines changed or added

This html diff was produced by rfcdiff 1.48.