Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 9793 China Mobile
Category: Standards Track M. Chen
ISSN: 2070-1721 Huawei
K. Patel
Arrcus, Inc.
IJ. Wijnands
Individual
T. Przygienda
Z. Zhang, Ed.
Juniper
June 2025
Bit Index Explicit Replication (BIER) is a 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 states, which are only in proportion to the number of BIER routers 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 advertisements.
BIT Index explicit Replication（BIER）は、明示的なツリービルディングプロトコルを必要としないマルチキャスト転送アーキテクチャであり、ツリーごとのマルチキャスト状態を維持するために中間ルーターを必要としません。いくつかのビア固有の情報と状態は、ビアルーターの数にのみ比例しているが、トゥリーごとではなく、宣伝、計算、および維持する必要があります。このドキュメントでは、広告に基づいてビア状態を計算するためのビア情報と方法を宣伝するためのBGP拡張機能について説明します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9793で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Requirements Language
3. BIER Path Attribute
3.1. BIER MPLS Encapsulation Sub-TLV
3.2. BIER Non-MPLS Encapsulation Sub-TLV
3.3. BIER Nexthop Sub-TLV
4. Originating/Propagating/Updating the BIER Attribute
5. BIFT Calculation with BGP Signaling
6. Example of BIER Nexthop Usage and Handling
7. Operational Considerations
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Bit Index Explicit Replication (BIER) [RFC8279] is a multicast forwarding architecture that doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain per-tree multicast states. It supports both direct and tunneled BIER forwarding. This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisements. 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 Bit-Forwarding Router Identifier (BFR-ID), BitStringLength (BSL), and so on. The signaling is to be used in a single Administrative Domain (AD), and Section 7 specifies procedures to prevent the BIER attribute from "leaking out" of the domain.
ビットインデックス明示的複製（BIER）[RFC8279]は、明示的なツリービルディングプロトコルを必要とせず、トリーごとのマルチキャスト状態を維持するために中間ルーターを必要としないマルチキャスト転送アーキテクチャです。直接およびトンネリングビア転送の両方をサポートします。このドキュメントでは、広告に基づいてビア状態を計算するためのビア情報と方法を宣伝するためのBGP拡張機能について説明します。より具体的には、このドキュメントでは、「ビア属性」と呼ばれる新しいオプションの推移的BGP属性を定義し、ビットフォードルーター識別子（BFR-ID）、BitStringLength（BSL）などのビア固有の情報を伝えます。シグナリングは単一の管理ドメイン（AD）で使用され、セクション7では、ビア属性がドメインの「漏れ」を防ぐ手順を指定します。
This document makes use of the terminology defined in [RFC4271] and [RFC8279]. Some terms are listed below for convenience.
このドキュメントでは、[RFC4271]および[RFC8279]で定義されている用語を使用しています。便利なために、いくつかの用語を以下にリストします。
BIER:
ビア：
Bit Indexed Explicit Replication
ビットインデックス付き明示的な複製
BFR:
BFR:
Bit-Forwarding Router
ビットフォワードルーター
BFR-ID:
BFR-ID：
BFR Identifier
BFR識別子
BSL:
BSL:
BitStringLength
BitStringlength
BIFT:
bift：
Bit Index Forwarding Table
ビットインデックス転送テーブル
BIFT-id:
bift-id：
Bit Index Forwarding Table Identifier
ビットインデックス転送テーブル識別子
BFER:
Bfer：
Bit-Forwarding Egress Router
ビットフォワード出力ルーター
BFR-prefix:
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.
各BFRには、属するサブドメインごとに単一の「BFR-Prefix」が割り当てられます。BFR-PrefixはBFRのループバックアドレスであることをお勧めします。
NLRI:
NLRI：
Network Layer Reachability Information [RFC4271]
ネットワークレイヤーリーチビリティ情報[RFC4271]
AFI:
AFI:
Address Family Identifier [RFC4760]
住所ファミリ識別子[RFC4760]
SAFI:
サフィ：
Subsequent Address Family Identifier [RFC4760]
後続のアドレスファミリ識別子[RFC4760]
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This specification defines an 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 or 2 and SAFI 1, 2, or 4 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. The attachment of the BIER attribute to non-host address prefixes is not defined by this document. It may be specified in the future, for example, by [BIER-Prefix-Redistribute].
この仕様は、「ビア属性」と呼ばれるオプションの推移的なBGPパス属性を定義します。この属性は、AFI 1または2およびSAFI 1、2、または4のNLRISのOriginatorによるBGP更新メッセージに添付して、NLRIに含まれる /32（IPv4の場合）または /128（IPv6の場合）ホストアドレスのプレフィックスによって識別される特定のBFRのビア固有の情報を示すことができます。非ホストアドレスプレフィックスへのBier属性の添付ファイルは、このドキュメントでは定義されていません。たとえば、[Bier-Prefix-Redistribute]によって将来指定される場合があります。
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 the scope of this document.
Bier Path属性が存在する場合、NLRIは「BFR-Prefix」と呼ばれます。他のAFIS/SAFISでの属性の使用は、このドキュメントの範囲外です。
The BIER path attribute is an optional, transitive BGP path attribute with type code 41 and of variable length. The attribute value portion carries BIER TLVs, which are encoded as follows:
Bier Path属性は、タイプコード41および可変長のオプションのTransitive BGPパス属性です。属性値部分には、次のようにエンコードされているビア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 | 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 the BIER attribute. The presence of unknown or unexpected TLVs MUST NOT result in the NLRI or the BIER attribute being considered malformed.
長さのフィールドは、オクテットの値部分の長さを定義します（したがって、値部分のないTLVの長さはゼロになります）。TLVは、4-OCTETアライメントにパッドで埋められていません。未知のサポートされていないタイプは、Bier属性内に保存および伝播する必要があります。不明または予期しないTLVの存在は、NLRIまたはビア属性が奇形と見なされるとは呼ばれないはずです。
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 for the BIER attribute is 41. The value field of the BIER attribute contains one or more BIER TLVs as shown below:
Bier属性を作成する場合、BFRには、プレフィックスが属するすべてのサブドメインに1つのビアTLVを含める必要があります。Bier属性の属性タイプコードは41です。Bier属性の値フィールドには、以下に示すように1つ以上のビア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 = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain | BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Type:
タイプ：
1
1
Length:
長さ：
2 octets encoding the length in octets of the Value part.
値部分のオクテットの長さをコードする2オクテット。
Sub-domain:
サブドメイン：
A 1-octet field encoding the sub-domain ID corresponding to the BFR-ID (see [RFC8279]).
BFR-IDに対応するサブドメインIDをコードする1-OCTETフィールド（[RFC8279]を参照）。
BFR-ID:
BFR-ID：
A 2-octet field encoding the BFR-ID (see [RFC8279]).
BFR-IDをコードする2-OCTETフィールド（[RFC8279]を参照）。
Reserved:
予約済み：
SHOULD be set to 0 on transmission and MUST be ignored on reception.
トランスミッションで0に設定する必要があり、受信で無視する必要があります。
Sub-TLVs:
サブTLV：
Contains one or more sub-TLVs.
1つ以上のサブ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.
Bier TLVは、各サブドメインに1つずつ、Bier Path属性に複数回表示される場合があります。同じサブドメイン値を持つビアTLVが1つしかない必要があります。ある場合、ビアパス属性全体を無視する必要があります。
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.
ビアTLVにはサブTLVがあり、独自のサブTLVがある場合があります。これらはすべてサブTLVと呼ばれ、レベルに関係なく同じタイプスペースを共有します。
The BIER MPLS Encapsulation sub-TLV has the following format. It MAY appear multiple times in the BIER TLV.
Bier MPLSカプセル化Sub-TLVには、次の形式があります。Bier TLVで複数回表示される場合があります。
The BIER MPLS Encapsulation sub-TLV has the following format:
Bier MPLSカプセル化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 = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS Len | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
2
2
Length:
長さ：
2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs).
値部分のオクテットの長さをコードする2オクテット。値は4またはその他です（サブTLVによって異なります）。
Max SI:
マックスSI：
A 1-octet field encoding the Maximum Set Identifier (see Section 1 of [RFC8279]) used in the encapsulation for this BIER sub-domain for this BitString length.
このビットストリング長のこのビアサブドメインのカプセル化で使用される最大セット識別子（[RFC8279]のセクション1を参照）をコードする1オクテットのフィールド。
BS Len:
BSレン：
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].
ビットストリングの長さ。このBFR-Prefixに関連付けられたサポートされているビットストリングの長さをコードする4ビットフィールド。このフィールドで許可されている値は、[RFC8296]のセクション2で指定されています。
Label:
ラベル：
A 20-bit value representing the first label in the label range.
ラベル範囲の最初のラベルを表す20ビット値。
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].
「ラベル範囲」は、ラベルから始まり、（ラベル +（最大SI））で終わるラベルのセットです。ビットストリングの長さとサブドメインIDごとに一意のラベル範囲が割り当てられます。これらのラベルは、[RFC8279]および[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.
ラベル範囲のサイズは、ネットワークで使用されるSIS（[RFC8279]のセクション1）の数によって決定されます。ラベル範囲の単一のラベルへの各SIマップ：最初のラベルはSi = 0用です。2番目のラベルはSi = 1などです。
If the label associated with the Maximum SI exceeds the 20-bit range, the BIER MPLS Encapsulation sub-TLV containing the error MUST be ignored.
最大SIに関連付けられたラベルが20ビット範囲を超える場合、エラーを含むBier MPLSカプセル化Sub-TLVを無視する必要があります。
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.
同じビアTLV内の複数のビアMPLSカプセル化サブTLVで同じビットストリングの長さが繰り返される場合、Bier TLVのすべてのビアMPLSカプセル化サブTLVを無視する必要があります。
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.
同じBFRによって宣伝されているすべてのBier MPLSカプセル化サブTLV内のラベル範囲は、重複してはなりません。オーバーラップが検出された場合、BFRによって宣伝されているすべてのビアMPLSカプセル化サブ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.
Bier Non-Mplsカプセル化Sub-TLVは、非MPLSカプセル化に使用され、次の形式があります。単一のビアTLV内で複数回表示される場合があります。同じBier TLV内の複数のBier Non-Mplsカプセル化サブTLVで同じビットストリングの長さが繰り返される場合、Bier 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 = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max SI |BS Len | BIFT-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
3
3
Length:
長さ：
2 octets encoding the length in octets of the Value part. The value is 4 or other (depending on sub-TLVs).
値部分のオクテットの長さをコードする2オクテット。値は4またはその他です（サブTLVによって異なります）。
Max SI:
マックスSI：
A 1-octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279]) used in the encapsulation for this BIER 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 associated with the Maximum SI exceeds the 20-bit range, the sub-TLV MUST be ignored.
このビットストリング長のこのビアサブドメインのカプセル化で使用されている最大セット識別子（[RFC8279]のセクション1）をコードする1オクセットフィールド。最初のbift-idはsi = 0、2番目のbift-idはsi = 1などです。最大Siに関連付けられたbift-idが20ビット範囲を超えた場合、Sub-TLVは無視する必要があります。
BS Len:
BSレン：
BitString Length. A 4-bit field encoding the BitString length (as per [RFC8296]) supported for the encapsulation.
ビットストリングの長さ。カプセル化をサポートするビットストリングの長さ（[RFC8296]による）をコードする4ビットフィールド。
BIFT-id:
bift-id：
A 20-bit field representing the first BIFT-id in the BIFT-id range.
最初の贈り物を表す20ビットフィールドは、ギフト範囲にあります。
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-ids are used for BIER forwarding, as described in [RFC8279] and [RFC8296].
「bift-id範囲」は、bift-idで始まり、（bift-id +（max si））で終わる20ビット値のセットです。これらのbift-IDは、[RFC8279]および[RFC8296]で説明されているように、ビア転送に使用されます。
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 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.
BIFT-ID範囲のサイズは、ネットワークで使用されるSIS（[RFC8279]のセクション1）の数によって決定されます。各SIは、Bift-ID範囲の単一のbift-IDにマップします。最初のbift-IDはSi = 0用です。2番目のbift-idはsi = 1などです。
If the BIFT-id associated with the Maximum SI exceeds the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV containing the error MUST be ignored.
最大SIに関連付けられているギフトISが20ビット範囲を超える場合、エラーを含むBier Non-Mplsカプセル化サブTLVを無視する必要があります。
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-TLVs 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 the BIER MPLS Encapsulation sub-TLV.
同じBFRによって宣伝されているすべてのBier Non-Mplsカプセル化サブTLV内のBift-ID範囲は、重複してはなりません。オーバーラップが検出された場合、BFRによって宣伝されているすべてのBier Non-Mplsカプセル化サブTLVを無視する必要があります。ただし、Bift-IDの範囲は、異なるカプセル化タイプで重複する場合があり、許可されています。例として、非MPLSカプセル化Sub-TLVのBIFT-ID値は、BIER MPLSカプセル化Sub-TLVのラベル範囲のラベル値と重複する場合があります。
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-TLVs or in the top-level BIER TLV. It is used when calculating BIFT entries, as described in Section 5 and illustrated in Section 6.
Bier Nexthop Sub-TLVを含めることができ、各MPLSまたは非MPLSカプセル化サブTLVまたはトップレベルのビアTLVに複数回含めることはできません。セクション5で説明され、セクション6に示されているように、BIFTエントリを計算するときに使用されます。
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
4
Length:
長さ：
2 octets. The value is 4 if the Nexthop is an IPv4 address and 16 if the Nexthop is an IPv6 address.
2オクテット。NexthopがIPv4アドレスである場合、値は4、NexthopがIPv6アドレスである場合は16です。
Nexthop:
Nexthop：
4 or 16 octets of an IPv4/IPv6 address.
IPv4/IPv6アドレスの4または16オクテット。
A Bit-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 MAY 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 next hop when calculating BIFT.
少し前向きな出力ルーター（BFer）は、Bier属性を独自の /32（IPv4）または /128（IPv6の場合）ホストBFR-Prefix NLRIに接続する必要があります。Bier属性には、サポートするビアサブドメインごとに1つのビアTLVを含める必要があります。各Bier TLVには、MPLSおよび/または非MPLSカプセル化サブTLVを含める必要があり、BierプレフィックスにセットされたNexthopを備えたビアNexthop Sub-TLVを含めることができます。Bier Nexthop Sub-TLVが含まれていない場合、BIRTを計算するときにBIERの次のホップとしてBFRを受信することにより、Bierプレフィックスを使用します。
When a BFR receives an update with the BIER path attribute, the attribute is parsed with the following validations:
BFRがBier Path属性を使用して更新を受信すると、属性は次の検証で解析されます。
* Syntactic checking based on the Length field of TLVs and sub-TLVs:
* TLVとサブTLVの長さフィールドに基づく構文チェック：
- The total length of BIER TLVs (including the Type and Length fields) MUST be equal to the BIER path attribute length.
- ビアTLVの総長さ（タイプフィールドと長さフィールドを含む）は、ビアパス属性の長さに等しくなければなりません。
- The total length of sub-TLVs (including the Type and Length fields) of a TLV MUST be equal to the length of the TLV.
- TLVのサブTLV（タイプおよび長さフィールドを含む）の総長は、TLVの長さに等しくなければなりません。
* Semantic checking as per Section 3.
* セクション3に従ってセマンティックチェック。
If the syntactic checking fails, the attribute is considered malformed and the "attribute discard" action [RFC7606] for the BIER attribute MUST be taken. If the semantic checking passes, BIFT entries are calculated as described in Section 5. Otherwise (i.e., if semantic checking fails), some or all BIER TLVs are ignored, per the rules given in Section 3, and if the remaining data permits, BIFT entries are calculated per Section 5.
構文チェックが失敗した場合、属性は奇形と見なされ、Bier属性の「属性doctard」アクション[RFC7606]を取得する必要があります。セマンティックチェックが合格した場合、セクション5で説明されているようにBIFTエントリが計算されます。それ以外の場合は（つまり、セマンティックチェックが失敗した場合）、セクション3で指定されたルールに従って、一部またはすべてのビアTLVが無視されます。
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 the MPLS or non-MPLS Encapsulation sub-TLV. If it does not support a sub-domain, it MUST NOT update the corresponding BIER TLV.
BFRがBIER属性を使用してBGP NLRIを再版画するとき、このBFRがサポートするサブドメインについては、対応するビアTLVで、Bier Nexthop sub-TLVを設定/更新して独自のビアのプレフィックスを使用する必要があります。その場合、MPLSまたは非MPLSカプセル化サブTLVを独自のものに置き換える必要があります。つまり、BFRが独自のBierプレフィックスにカプセル化サブTLVを取り付けているかのようです。Bier Nexthop Sub-TLVを更新しない場合、MPLSまたは非MPLSカプセル化サブTLVを更新してはなりません。サブドメインをサポートしていない場合は、対応するビアTLVを更新してはなりません。
It's possible that the BFR supports some but not all BitStringLengths (BSLs) in the received MPLS or non-MPLS Encapsulation sub-TLVs. 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 BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation sub-TLVs. For the BSLs that it does not support:
BFRは、受信したMPLSまたは非MPLSカプセル化サブTLVのすべてではなく、一部ではなく一部をサポートしている可能性があります。トップビアTLVのBier Nexthop Sub-TLVをそれ自体に設定/更新した後、それがサポートするBSLのために、BFRは、対応するカプセル化サブTLVでビアNexthop Sub-TLV（存在する場合）を削除する必要があります。サポートしていないBSLの場合：
* If a BIER Nexthop sub-TLV is included in the Encapsulation sub-TLV, it MUST NOT be updated.
* Bier Nexthop Sub-TLVがカプセル化Sub-TLVに含まれている場合、更新してはなりません。
* Otherwise, if a BIER Nexthop sub-TLV is included in the received BIER TLV, its original value (before changed for supported BSLs by this BFR) MUST be copied into the Encapsulation sub-TLV.
* それ以外の場合、Bier Nexthop Sub-TLVが受信ビアTLVに含まれている場合、その元の値（このBFRによってサポートされているBSLのために変更される前）をカプセル化Sub-TLVにコピーする必要があります。
* Otherwise, a BIER Nexthop sub-TLV MUST be added to the Encapsulation sub-TLV with its value set to the BFR-prefix.
* それ以外の場合は、BIRE NEXTHOP SUB-TLVをBFR-PREFIXに設定して、カプセル化サブTLVに追加する必要があります。
All impacted Length fields (e.g., the Encapsulation sub-TLV Length and the top-level BIER TLV Length) MUST be updated accordingly.
それに応じて、すべての衝撃を受けた長さフィールド（例：カプセル化サブTLV長さとトップレベルのビアTLV長）を更新する必要があります。
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.
BIER属性はオプションの推移的なBGPパス属性であるため、非BFR BGPスピーカーは、Bier属性で受信ルートを再承認することができます。
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 the BFR-prefixes with the same BFR-ID for BIFT calculation for the sub-domain and an error SHOULD be logged.
2つの異なるBFR-Prefixesは、同じサブドメインで同じ非ゼロBFR-IDを持たない必要があります。複製が検出された場合、受信BFRは、サブドメインのBIFT計算のために同じBFR-IDを持つBFR-Prefixesを使用してはなりません。エラーを記録する必要があります。
As pointed out in [RFC8279], BIFTs are derived from the unicast FIB by adding BIER-specific information.
[RFC8279]で指摘されているように、ビフトはビア固有の情報を追加することにより、ユニキャストFIBから派生しています。
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 BIER Nexthop sub-TLV. If there is no BIER Nexthop sub-TLV at all, the entry's BFR-NBR 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.
各サブドメインについて、BFRは、サブドメイン用のビアTLVが含まれるビア属性が含まれるビアプレフィックスを通過することにより、対応するバイフトを計算します。Bier TLVの非ゼロBFR-IDの場合、BIFTエントリが作成または更新されます。エントリーのBFR隣人（BFR-NBR）[RFC8279]は、カプセル化サブTLVがBier Nexthop Sub-TLVを持っていない場合、対応するカプセル化サブTLVまたはトップレベルのビアTLVのBier Nexthop Sub-TLVのNexthopです。Bier Nexthop Sub-TLVがまったくない場合、エントリのBFR-NBRはビアプレフィックス自体です。エントリ用のBierラベルまたはBift-IDは、MPLSカプセル化Sub-TLVのラベル範囲または非MPLSカプセル化サブTLVのBIFT-ID範囲から派生しています。
BIER traffic is sent to the BFR-NBR either directly (BIER header directly follows a Layer 2 header) if the BFR-NBR is directly connected or via a tunnel. Notice that, if a non-BFR BGP speaker re-advertises a BIER prefix (in this case, it cannot 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.
BFR-NBRが直接接続されている場合、またはトンネルを介して、BIREトラフィックがBFR-NBRに直接送信されます（Bierヘッダーはレイヤー2ヘッダーに直接従います）。非BFR BGPスピーカーがビアプレフィックスを再版画している場合（この場合、bier属性を更新できないため、ビア属性を更新できない）、またはBFR BGPスピーカーがBier nexthop sub-tlvを更新せずにBier Nexthop sub-tlvを更新せずにビアプレフィックスを再版で再版画する場合、BFRはBREを受け取るBIRの交通を再確認するBIRに依存しないBIRに依存しないBIRに依存しないBIRに依存しないBIRに依存しない場合に注意してください。プレフィックス。
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.
トンネルのセットアップと選択された方法は、このドキュメントの範囲外です。トンネルヘッダーがペイロードがビアであることを示すことができる限り、それはあらゆる種類のトンネル、例えば、MPLSラベルスイッチされたパスまたはIP/GREである可能性があります。
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 sub-domain that it 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 included in the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the BFR-prefix of BFER2 and BFER3, respectively.
Bfer1/2/3はそれぞれ、Bier Path属性を備えたループバックアドレスのルートを宣伝し、ゼロ以外のBFR-IDとMPLSカプセル化サブTLVを使用して、各サブドメインに1つのビアTLVをリストします。Bier nexthop sub-tlvはBfer1のものには含まれていませんが、Bfer2/3のものに含まれています。Bier Nexthop Sub-TLVは、それぞれBFer2とBFer3のBFR-Prefixをエンコードします。
When BFR2 receives the route, it calculates its BIFT entries. Because the route from BFER1 does not include a BIER Nexthop, BFR2 uses BFR1's BFR-prefix as the next hop.
BFR2がルートを受信すると、BIFTエントリを計算します。Bfer1からのルートにはBier Nexthopが含まれていないため、BFR2はBFR1のBFR-Prefixを次のホップとして使用します。
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.
BFR2は、ルートを非BFRに再告発すると、BFER1ルートにビアNexthopサブTLVを追加し、BFER2/3ルートのBier Nexthop Sub-TLVを更新します。また、MPLSカプセル化Sub-TLVを更新して、独自のラベルをエンコードします。
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.
非BFRがバイアーをサポートしないため、ルートを受信すると、ビア固有のアクションは取られず、ルートはビアパス属性を変更してBFR1に再承認されます。
When BFR1 receives the routes, it calculates the BIFT entries, using 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.
BFR1がルートを受信すると、次のホップとしてBier Nexthop Sub-TLVでエンコードされたBFR2のアドレスを使用して、BIFTエントリを計算します。BFR2は直接接続されていないため、トンネルを使用する必要があります。
In this document, it is assumed 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.
このドキュメントでは、Bierドメイン[RFC8279]は、複数の自律システムで構成されている可能性のある管理ドメイン（AD）と整合していると想定されています。他のシナリオでのBier属性の使用は、このドキュメントの範囲外です。
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's purposes. This is analogous to the Provider Edge router's loopback addresses that are distributed inside the AD, but they do not need to be distributed outside the AD.
BFR-Prefixesは、通常、BFRのループバックアドレスです。それらは広告全体に配布されますが、ビアの目的のために広告の外に配布する必要はありません。これは、広告内に配布されているプロバイダーEdgeルーターのループバックアドレスに類似していますが、広告の外側に配布する必要はありません。
If prefixes are distributed outside of the AD with the BIER attribute attached and the neighboring AD also deploying BIER, then the two BIER domains, which should be independent of each other, may be incorrectly joined together and most likely have conflicting configurations, causing security risks and operational troubles.
Bier属性が添付され、隣接する広告もビアを展開して、プレフィックスが広告の外側に配布されている場合、互いに独立している2つのビアドメインが誤って結合され、おそらく矛盾する構成があり、セキュリティリスクと運用上の問題を引き起こす可能性があります。
To prevent that, a boundary router of the AD that supports the BIER attribute MUST support a policy based on an External BGP (EBGP) session/group that indicates whether the attribute is allowed; 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.
それを防ぐために、BIER属性をサポートするADの境界ルーターは、属性が許可されているかどうかを示す外部BGP（EBGP）セッション/グループに基づいてポリシーをサポートする必要があります。デフォルトでは、許可されていません。許可されていない場合、Bier属性をセッション/グループのEBGPピアに送信してはなりません。ビア属性がピアから受信された場合、それはまるで認識されていない非転写属性であるかのように正確に扱わなければなりません。つまり、それは静かに無視され、他のBGPピアに渡されないでください。
IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path Attributes" registry <https://www.iana.org/assignments/bgp-parameters> as follows:
IANAは、「BGPパス属性」レジストリ<https://www.iana.org/assignments/bgp-parameters>のbier属性にCodePoint 41をbier属性に割り当てました。
+=======+======+===========+
| Value | Code | Reference |
+=======+======+===========+
| 41 | BIER | RFC 9793 |
+-------+------+-----------+
Table 1
IANA has created the "BGP BIER TLV and Sub-TLV Types" registry within 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].
IANAは、「Border Gateway Protocol（BGP）パラメーター」レジストリグループ内に「BGP Bier TLVおよびSub-TLVタイプ」レジストリを作成しました。レジストリのタイプフィールドは2オクテットで構成され、可能な値は0〜65535（値0は予約されています）。このフィールドの割り当てポリシーは、最初に提供されます[RFC8126]。
The five initial values have been allocated as follows:
5つの初期値は次のように割り当てられています。
+=========+================================+===========+
| Value | Name | Reference |
+=========+================================+===========+
| 0 | Reserved | RFC 9793 |
+---------+--------------------------------+-----------+
| 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
This document introduces no new security considerations beyond those already discussed in [RFC4271], [RFC8279], and the operational considerations (Section 7) of this document.
このドキュメントでは、[RFC4271]、[RFC8279]、およびこのドキュメントの運用上の考慮事項（セクション7）で説明されているもの以外の新しいセキュリティ上の考慮事項を紹介しません。
[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>.
[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-08, 23 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
prefix-redistribute-08>.
[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>.
Thanks to Eric Rosen and Peter Psenak for their valuable comments on this document.
この文書に関する貴重なコメントをしてくれたEric RosenとPeter Psenakに感謝します。
This document has the following contributor:
このドキュメントには次の貢献者があります。
Zheng (Sandy) Zhang
ZTE
Email: zhang.zheng@zte.com.cn
Xiaohu Xu
China Mobile
Email: xuxiaohu@cmss.chinamobile.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
IJsbrand Wijnands
Individual
Email: ice@braindump.be
Tony Przygienda
Juniper
Email: prz@juniper.net
Zhaohui Zhang (editor)
Juniper
Email: zzhang@juniper.net