Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 9573 Juniper Networks
Updates: 6514, 7432, 7582 E. Rosen
Category: Standards Track Individual
ISSN: 2070-1721 W. Lin
Juniper Networks
Z. Li
Huawei Technologies
IJ. Wijnands
Individual
May 2024
The Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.
マルチキャストVPN（MVPN）仕様により、単一のポイントツーマルチポイント（P2MP）トンネルが複数のIP VPN（このドキュメントのVPNと呼ばれる）のトラフィックを運ぶことができます。EVPN仕様により、単一のP2MPトンネルが複数のブロードキャストドメイン（BDS）のトラフィックを運ぶことができます。これらの機能には、各VPNまたは各BDに上流で割り当てられたMPLSラベルを割り当てるために、P2MPトンネルの侵入ルーターが必要です。P2MPトンネルに送信されたパケットは、VPNまたはBDにマッピングされたラベルを運びます（場合によっては、各フローに異なるアップストリーム割り当てのラベルが必要です。）各イングレスルーターは独立してラベルを割り当て、調整がないため、侵入ルーター、出力ルーターは、多数のラベルを追跡する必要がある場合があります。ラベルの数は、VPNまたはBDSの数の倍の侵入ルーターの数と同じか大きい、またはそれ以上のものである必要がある場合があります。ただし、ラベルとVPNまたはBDの関連がプロビジョニングによって作成された場合、ラベルの数は大幅に削減できます。これにより、すべてのイングレスルーターが同じラベルを特定のVPNまたはBDに割り当てます。このような提供されたラベルを活用するには、新しい手順が必要です。これらの新しい手順は、Multipoint-to-Multipoint（MP2MP）トンネルにも適用されます。このドキュメントは、必要な手順を指定することにより、RFCS 6514、7432、および7582を更新します。
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/rfc9573.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9573で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Problem Description
3. Proposed Solutions
3.1. MP2MP Tunnels
3.2. Segmented Tunnels
3.3. Summary of Label Allocation Methods
4. Specifications
4.1. Context-Specific Label Space ID Extended Community
4.2. Procedures
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
A Multicast VPN (MVPN) can use Point-to-Multipoint (P2MP) tunnels (set up by RSVP-TE, Multipoint LDP (mLDP), or PIM) to transport customer multicast traffic across a service provider's backbone network. Often, a given P2MP tunnel carries the traffic of only a single VPN. However, there are procedures defined that allow a single P2MP tunnel to carry traffic of multiple VPNs. In this case, the P2MP tunnel is called an "aggregate tunnel". The Provider Edge (PE) router that is the ingress node of an aggregate P2MP tunnel allocates an "upstream-assigned MPLS label" [RFC5331] for each VPN, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's VPN.
マルチキャストVPN（MVPN）は、ポイントツーマルチポイント（P2MP）トンネル（RSVP-TE、マルチポイントLDP（MLDP）、またはPIMによって設定）を使用して、サービスプロバイダーのバックボーンネットワーク全体で顧客マルチキャストトラフィックを輸送できます。多くの場合、特定のP2MPトンネルは、単一のVPNのみのトラフィックを運びます。ただし、単一のP2MPトンネルが複数のVPNのトラフィックを運ぶことができる手順が定義されています。この場合、P2MPトンネルは「集計トンネル」と呼ばれます。集約P2MPトンネルの侵入ノードであるプロバイダーエッジ（PE）ルーターは、各VPNに対して「上流で割り当てられたMPLSラベル」[RFC5331]を割り当て、P2MPトンネルに送信される各パケットには、上流で割り当てられたMPLSラベルが搭載されています。Ingress PEはパケットのVPNに縛られています。
Similarly, an EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to transport Broadcast, Unknown Unicast, or Multicast (BUM) traffic across the provider network. Often, a P2MP tunnel carries the traffic of only a single Broadcast Domain (BD). However, there are procedures defined that allow a single P2MP tunnel to be an aggregate tunnel that carries traffic of multiple BDs. The procedures are analogous to the MVPN procedures -- the PE router that is the ingress node of an aggregate P2MP tunnel allocates an upstream-assigned MPLS label for each BD, and each packet sent on the P2MP tunnel carries the upstream-assigned MPLS label that the ingress PE has bound to the packet's BD.
同様に、EVPNはP2MPトンネル（RSVP-TE、MLDP、またはPIMによって設定された）を使用して、プロバイダーネットワーク全体で放送、不明なユニキャスト、またはマルチキャスト（BUM）トラフィックを輸送できます。多くの場合、P2MPトンネルは、単一のブロードキャストドメイン（BD）のみのトラフィックを運びます。ただし、単一のP2MPトンネルを複数のBDSのトラフィックを運ぶ総合トンネルにすることを可能にする手順が定義されています。手順はMVPN手順に類似しています - 集約P2MPトンネルの侵入ノードであるPEルーターは、各BDに上流で割り当てられたMPLSラベルを割り当て、P2MPトンネルで送信される各パケットには、アップストリームが割り当てられたMPLSラベルが搭載されています。イングレスPEはパケットのBDに縛られています。
An MVPN or EVPN can also use Bit Index Explicit Replication (BIER) [RFC8279] to transmit VPN multicast traffic [RFC8556] or EVPN BUM traffic [BIER-EVPN]. Although BIER does not explicitly set up P2MP tunnels, from the perspective of an MVPN/EVPN, the use of BIER transport is very similar to the use of aggregate P2MP tunnels. When BIER is used, the PE transmitting a packet (the "Bit-Forwarding Ingress Router" (BFIR) [RFC8279]) must allocate an upstream-assigned MPLS label for each VPN or BD, and the packets transmitted using BIER transport always carry the label that identifies their VPN or BD. (See [RFC8556] and [BIER-EVPN] for details.) In the remainder of this document, we will use the term "aggregate tunnels" to include both P2MP tunnels and BIER transport.
MVPNまたはEVPNは、ビットインデックス明示的複製（BIER）[RFC8279]を使用して、VPNマルチキャストトラフィック[RFC8556]またはEVPN BUMトラフィック[Bier-EVPN]を送信することもできます。BierはMVPN/EVPNの観点からP2MPトンネルを明示的にセットアップしていませんが、ビア輸送の使用は、凝集P2MPトンネルの使用に非常に似ています。Bierを使用すると、パケットを送信するPE（「ビットフォワードイングレスルーター」（BFIR）[RFC8279]）が各VPNまたはBDの上流で割り当てられたMPLSラベルを割り当てる必要があり、Bier輸送を使用して送信されるパケットは常に常に搭載されています。VPNまたはBDを識別するラベル。（詳細については[RFC8556]および[Bier-EVPN]を参照してください。）このドキュメントの残りの部分では、「集計トンネル」という用語を使用して、P2MPトンネルとビア輸送の両方を含めます。
When an egress PE receives a packet from an aggregate tunnel, it must look at the upstream-assigned label carried by the packet and must interpret that label in the context of the ingress PE. Essentially, for each ingress PE, the egress PE has a context-specific label space [RFC5331] that matches the default label space from which the ingress PE assigns the upstream-assigned labels. When an egress PE looks up the upstream-assigned label carried by a given packet, it looks it up in the context-specific label space for the ingress PE of the packet. How an egress PE identifies the ingress PE of a given packet depends on the tunnel type.
出力PEが集計トンネルからパケットを受け取った場合、パケットによって運ばれる上流で割り当てられたラベルを調べる必要があり、イングレスPEのコンテキストでそのラベルを解釈する必要があります。基本的に、侵入PEごとに、出口PEには、イングレスPEがアップストリーム割り当てのラベルを割り当てるデフォルトのラベル空間と一致するコンテキスト固有のラベル空間[RFC5331]があります。出力PEが特定のパケットによって運ばれるアップストリーム割り当てのラベルを調べると、パケットの入り口PEのコンテキスト固有のラベル空間でそれを調べます。特定のパケットの侵入PEがどのようにトンネルの種類に依存するか。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Familiarity with MVPN/EVPN protocols and procedures is assumed. Some terms are listed below for convenience.
MVPN/EVPNプロトコルと手順に精通していることが想定されています。便利なために、いくつかの用語を以下にリストします。
VPN:
VPN:
Virtual Private Network. In this document, "VPN" specifically refers to an IP VPN [RFC4364].
仮想プライベートネットワーク。このドキュメントでは、「VPN」はIP VPN [RFC4364]を具体的に指します。
BUM [RFC7432]:
Bum [RFC7432]：
Broadcast, Unknown Unicast, or Multicast (traffic).
ブロードキャスト、不明なユニキャスト、またはマルチキャスト（トラフィック）。
BD [RFC7432]:
BD [RFC7432]：
Broadcast Domain.
ブロードキャストドメイン。
EC [RFC4360]:
EC [RFC4360]：
Extended Community.
拡張コミュニティ。
PMSI [RFC6513]:
PMSI [RFC6513]：
Provider Multicast Service Interface. A pseudo-overlay interface for PEs to send certain overlay/customer multicast traffic via underlay/provider tunnels. It includes Inclusive/Selective PMSIs (I/S-PMSIs) (often referred to as x-PMSIs). A PMSI is instantiated by the underlay/provider tunnel.
プロバイダーマルチキャストサービスインターフェイス。アンダーレイ/プロバイダートンネルを介して特定のオーバーレイ/顧客マルチキャストトラフィックを送信するためのPESの擬似オーバーレイインターフェイス。包括的/選択的PMSIS（I/S-PMSIS）（X-PMSISと呼ばれることが多い）が含まれます。PMSIは、アンダーレイ/プロバイダートンネルによってインスタンス化されます。
Inclusive PMSI (I-PMSI):
包括的PMSI（I-PMSI）：
A PMSI that enables traffic to be sent to all PEs of a VPN/BD. The underlay/provider tunnel that instantiates the I-PMSI is referred to as an inclusive tunnel.
トラフィックをVPN/BDのすべてのPESに送信できるようにするPMSI。I-PMSIをインスタンス化するアンダーレイ/プロバイダートンネルは、包括的トンネルと呼ばれます。
Selective PMSI (S-PMSI):
選択的PMSI（S-PMSI）：
A PMSI that enables traffic to be sent to a subset of PEs of a VPN/BD. The underlay/provider tunnel that instantiates the S-PMSI is referred to as a selective tunnel.
トラフィックをVPN/BDのPESのサブセットに送信できるようにするPMSI。S-PMSIをインスタンス化するアンダーレイ/プロバイダートンネルは、選択的トンネルと呼ばれます。
Aggregate Tunnel:
集約トンネル：
A tunnel that instantiates x-PMSIs of multiple MVPNs or EVPN BDs.
複数のMVPNまたはEVPN BDSのX-PMSIをインスタンス化するトンネル。
IMET [RFC7432]:
IMET [RFC7432]：
Inclusive Multicast Ethernet Tag. An EVPN-specific name for an I-PMSI Auto-Discovery (A-D) route.
包括的マルチキャストイーサネットタグ。I-PMSIオートディスコービリ（A-D）ルートのEVPN固有の名前。
PTA [RFC6514]:
PTA [RFC6514]：
PMSI Tunnel Attribute. A BGP attribute that may be attached to a BGP-MVPN/EVPN x-PMSI A-D route.
PMSIトンネル属性。BGP-MVPN/EVPN X-PMSI A-Dルートに接続できるBGP属性。
ASBR:
ASBR：
Autonomous System Border Router.
自律システムボーダールーター。
RBR:
RBR:
Regional Border Router. A border router between segmentation regions that participates in segmentation procedures.
地域の国境ルーター。セグメンテーション手順に参加するセグメンテーション領域間の境界ルーター。
(C-S,C-G):
（C-S、C-G）：
A Customer/overlay <S,G> multicast flow.
顧客/オーバーレイ<s、g>マルチキャストフロー。
(C-*,C-G):
（c-*、c-g）：
Customer/overlay <*,G> multicast flows.
顧客/オーバーレイ<*、g>マルチキャストフロー。
(C-*,C-*):
（c-*、c-*）：
All Customer/overlay multicast flows.
すべての顧客/オーバーレイマルチキャストフロー。
ES:
ES:
Ethernet Segment.
イーサネットセグメント。
ESI [RFC7432]:
ESI [RFC7432]：
ES Identifier.
ES識別子。
ESI Label [RFC7432]:
ESIラベル[RFC7432]：
A label that identifies an ES.
ESを識別するラベル。
SRGB [RFC8402]:
SRGB [RFC8402]：
Segment Routing (SR) Global Block. The set of global segments in the SR domain. In SR-MPLS [RFC8660], an SRGB is a local property of a node and identifies the set of local labels reserved for global segments.
セグメントルーティング（SR）グローバルブロック。SRドメインのグローバルセグメントのセット。SR-MPLS [RFC8660]では、SRGBはノードのローカルプロパティであり、グローバルセグメント専用のローカルラベルのセットを識別します。
DCB:
DCB:
Domain-wide Common Block. A common block of labels reserved on all nodes in a domain.
ドメイン全体の共通ブロック。ドメイン内のすべてのノードに予約されているラベルの一般的なブロック。
Context-Specific Label Space [RFC5331]:
コンテキスト固有のラベル空間[RFC5331]：
A router may maintain additional label spaces besides its default label space. When the label at the top of the stack is not from the default label space, there must be some context in the packet that identifies which one of those additional label spaces is to be used to look up the label; hence, those label spaces are referred to as context-specific label spaces.
ルーターは、デフォルトのラベルスペース以外に追加のラベルスペースを維持する場合があります。スタックの上部にあるラベルがデフォルトのラベルスペースからのものではない場合、パケットには、それらの追加ラベルスペースのいずれかがラベルを検索するために使用するものを識別するコンテキストがある必要があります。したがって、これらのラベルスペースは、コンテキスト固有のラベルスペースと呼ばれます。
Upstream Assigned [RFC5331]:
上流の割り当て[RFC5331]：
When the label at the top of the label stack is not assigned by the router receiving the traffic from its default label space, the label is referred to as upstream assigned. Otherwise, it is downstream assigned. An upstream-assigned label must be looked up in a context-specific label space specific for the assigner.
ラベルスタックの上部にあるラベルが、デフォルトのラベルスペースからトラフィックを受信するルーターによって割り当てられていない場合、ラベルは上流と呼ばれます。それ以外の場合は、下流に割り当てられています。上流で割り当てられたラベルは、割り当てに固有のコンテキスト固有のラベル空間で調べる必要があります。
Note that the upstream-assigned label procedures may require a very large number of labels. Suppose that an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 VPNs/BDs. Each ingress PE has to assign 1000 labels, and each egress PE has to be prepared to interpret 1000 labels from each of the ingress PEs. Since each ingress PE allocates labels from its own label space and does not coordinate label assignments with others, each egress PE must be prepared to interpret 1,000,000 upstream-assigned labels (across 1000 context-specific label spaces -- one for each ingress PE). This is an evident scaling problem.
上流に割り当てられたラベル手順には、非常に多数のラベルが必要になる場合があることに注意してください。MVPNまたはEVPN展開には1001個のPESがあり、それぞれが1000 VPN/BDSをホストしているとします。各イングレスPEは1000のラベルを割り当てる必要があり、各出口PEを各侵入PEから1000のラベルを解釈する準備をする必要があります。各イングレスPEは、独自のラベル空間からラベルを割り当て、ラベルの割り当てを他の人と調整しないため、各出口PEは、1,000,000の上流で割り当てられたラベル（1000のコンテキスト固有のラベルスペースを超えて）を解釈するために準備する必要があります。これは明らかなスケーリングの問題です。
So far, few if any MVPN/EVPN deployments use aggregate tunnels, so this problem has not surfaced. However, the use of aggregate tunnels is likely to increase due to the following two factors:
これまでのところ、MVPN/EVPNの展開が総合的なトンネルを使用している場合、この問題は浮上していません。ただし、骨材の使用は、次の2つの要因により増加する可能性があります。
* In an EVPN, a single customer ("tenant") may have a large number of BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may become important, since each tunnel creates state at the intermediate nodes.
* EVPNでは、単一の顧客（「テナント」）が多数のBDSを持っている可能性があり、各トンネルが中間ノードで状態を作成するため、総計RSVP-TEまたはMLDP P2MPトンネルの使用が重要になる可能性があります。
* The use of BIER as the transport for an MVPN/EVPN is becoming more and more attractive and feasible.
* MVPN/EVPNの輸送としてのビアの使用は、ますます魅力的で実行可能になりつつあります。
A similar problem also exists with EVPN ESI labels used for multihoming. A PE attached to a multihomed ES advertises an ESI label in its Ethernet A-D per ES route. The PE imposes the label when it sends frames received from the ES to other PEs via a P2MP/ BIER tunnel. A receiving PE that is attached to the source ES will know from the ESI label that the packet originated on the source ES and thus will not transmit the packet on its local Attachment Circuit to that ES. From the receiving PE's point of view, the ESI label is (upstream) assigned from the source PE's label space, so the receiving PE needs to maintain context-specific label tables, one for each source PE, just like the VPN/BD label case above. If there are 1001 PEs, each attached to 1000 ESs, this can require each PE to understand 1,000,000 ESI labels. Notice that the issue exists even when no P2MP tunnel aggregation (i.e., one tunnel used for multiple BDs) is used.
同様の問題は、マルチホームに使用されるEVPN ESIラベルにも存在します。マルチホームのESに接続されたPEは、ESルートごとにイーサネットA-DにESIラベルを宣伝しています。PEは、P2MP/ビアトンネルを介してESから受け取ったフレームを他のPEに送信するときにラベルを課します。ソースESに接続されている受信PEは、ESIラベルからパケットがソースESに発信されたため、ローカルアタッチメント回路でパケットをそのESに送信しないことがわかります。受信PEの観点から、ESIラベルはソースPEのラベルスペースから割り当てられているため、VPN/BDラベルケースと同様に、各ソースPE用のコンテキスト固有のラベルテーブルを維持する必要があります。その上。それぞれが1000 ESSに接続されている1001個のPESがある場合、これには各PEが1,000,000のESIラベルを理解する必要があります。P2MPトンネルの凝集（つまり、複数のBDSに使用される1つのトンネル）が使用されていない場合でも、問題が存在することに注意してください。
The number of labels could be greatly reduced if a central entity in the provider network assigned a label to each VPN, BD, or ES and if all PEs used that same label to represent a given VPN, BD, or ES. Then, the number of labels needed would just be the sum of the number of VPNs, BDs, and/or ESs.
プロバイダーネットワークの中央エンティティが各VPN、BD、またはESにラベルを割り当て、すべてのPEがその同じラベルを使用して特定のVPN、BD、またはESを表す場合、ラベルの数を大幅に削減できます。次に、必要なラベルの数は、VPN、BDS、および/またはESSの数の合計にすぎません。
One method of achieving this is to reserve a portion of the default label space for assignment by a central entity. We refer to this reserved portion as the DCB of labels. This is analogous to the concept of using identical SRGBs on all nodes, as described in [RFC8402]. A PE that is attached (via L3VPN Virtual Routing and Forwarding (VRF) interfaces or EVPN Attachment Circuits) would know by provisioning which label from the DCB corresponds to which of its locally attached VPNs, BDs, or ESs.
これを達成する1つの方法は、中央エンティティによる割り当てのためのデフォルトのラベルスペースの一部を予約することです。この予約された部分をラベルのDCBと呼びます。これは、[RFC8402]で説明されているように、すべてのノードで同一のSRGBを使用するという概念に類似しています。接続されているPE（L3VPN仮想ルーティングと転送（VRF）インターフェイスまたはEVPNアタッチメントサーキットを介して）は、DCBのどのラベルが局所的に付属しているVPN、BD、またはESSのどれに対応するかをプロビジョニングすることにより知ります。
For example, all PEs could reserve a DCB [1000~2000], and they would all be provisioned so that label 1000 maps to VPN 0, label 1001 maps to VPN 1, and so forth. Now, only 1000 labels instead of 1,000,000 labels are needed for 1000 VPNs.
たとえば、すべてのPESはDCB [1000〜2000]を予約することができ、それらはすべてVPN 0にラベル1000マップ、1001マップのラベル1001マップなどをプロビジョニングします。現在、1000 VPNに必要なラベルの代わりに1000のラベルのみが必要です。
In this document, "domain" is defined loosely; it simply includes all the routers that share the same DCB, and it only needs to include all PEs of an MVPN/EVPN.
このドキュメントでは、「ドメイン」がゆるく定義されています。同じDCBを共有するすべてのルーターを含むだけで、MVPN/EVPNのすべてのPESを含める必要があります。
The "domain" could also include all routers in the provider network, making it not much different from a common SRGB across all the routers. However, that is not necessary, as the labels used by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives at the PEs. Therefore, it is better to not include internal P routers in the "domain". That way, they do not have to set aside the same DCB used for the purposes defined in this document.
「ドメイン」には、プロバイダーネットワーク内のすべてのルーターを含めることもでき、すべてのルーターの一般的なSRGBとそれほど違いはありません。ただし、このドキュメントで定義されている目的でPESが使用するラベルは、トラフィックがPESに到着したときにラベルスタックの上部にのみ上昇するため、それは必要ありません。したがって、「ドメイン」に内部Pルーターを含めないことをお勧めします。そうすれば、このドキュメントで定義されている目的に使用される同じDCBを脇に置く必要はありません。
In some deployments, it may be impractical to allocate a DCB that is large enough to contain labels for all the VPNs/BDs/ESs. In this case, it may be necessary to allocate those labels from one or a few context-specific label spaces that are independent of each PE. For example, if it is too difficult to have a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESs that need to be supported, a separate context-specific label space can be dedicated to those 10,000 labels. Each separate context-specific label space is identified in the forwarding plane by a label from the DCB (which does not need to be large). Each PE is provisioned with the label-space-identifying DCB label and the common VPN/BD/ES labels allocated from that context-specific label space. When sending traffic, an ingress PE imposes all necessary service labels (for the VPN/BD/ES) first, then imposes the label-space-identifying DCB label. From the label-space-identifying DCB label, an egress PE can determine the label space where the inner VPN/BD/ES label is looked up.
一部の展開では、すべてのVPN/BDS/ESSのラベルを含めるのに十分な大きさのDCBを割り当てることは非現実的かもしれません。この場合、これらのラベルを、各PEから独立した1つまたはいくつかのコンテキスト固有のラベルスペースから割り当てる必要がある場合があります。たとえば、サポートする必要があるすべてのVPNS/BDS/ESSのすべてのPESに10,000個のDCBを持つことが難しすぎる場合、個別のコンテキスト固有のラベルスペースを10,000個のラベルに専念させることができます。各コンテキスト固有のラベルスペースは、DCBからのラベルによって転送面で識別されます（これは大きくする必要はありません）。各PEには、そのコンテキスト固有のラベル空間から割り当てられたラベル空間識別DCBラベルと、共通のVPN/BD/ESラベルがプロビジョニングされます。トラフィックを送信するとき、Ingress PEは、最初に必要なすべてのサービスラベル（VPN/BD/ES用）を課します。次に、ラベルスペースを特定するDCBラベルを課します。ラベル空間識別DCBラベルから、出口PEは、内側のVPN/BD/ESラベルが検索されるラベル空間を決定できます。
The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes that certain MPLS labels are allocated from a context-specific label space for a particular ingress PE. In this document, we augment the signaling procedures so that it is possible to signal that a particular label is from the DCB, rather than from a context-specific label space for an ingress PE. We also augment the signaling so that it is possible to indicate that a particular label is from an identified context-specific label space that is not for an ingress PE.
[RFC6514]および[RFC7432]で定義されているMVPN/EVPNシグナル伝達は、特定のMPLSラベルが特定の侵入PE用のコンテキスト固有のラベル空間から割り当てられていることを前提としています。このドキュメントでは、シグナル伝達手順を強化して、特定のラベルがイングレスPEのコンテキスト固有のラベル空間からではなく、DCBからであることを信号することができるようにします。また、特定のラベルが侵入PE用ではない特定のコンテキスト固有のラベル空間からであることを示すことができるように、シグナリングを補強します。
Notice that the VPN/BD/ES-identifying labels from the DCB or from those few context-specific label spaces are very similar to Virtual eXtensible Local Area Network (VXLAN) Network Identifiers (VNIs) in VXLANs. Allocating a label from the DCB or from a context-specific label space and communicating the label to all PEs is not different from allocating VNIs and is especially feasible with controllers.
DCBまたはそれらの少数のコンテキスト固有のラベルスペースからのVPN/BD/ES-識別ラベルは、VXLANの仮想拡張可能なローカルエリアネットワーク（VXLAN）ネットワーク識別子（VNI）に非常に似ていることに注意してください。DCBまたはコンテキスト固有のラベルスペースからラベルを割り当て、ラベルをすべてのPEに通信することは、VNIの割り当てと違いはなく、特にコントローラーで実現可能です。
Multipoint-to-Multipoint (MP2MP) tunnels present the same problem (Section 2) that can be solved the same way (Section 3), with the following additional requirement.
Multipoint-to-Multipoint（MP2MP）トンネルは、同じ方法（セクション3）と同じ問題（セクション2）を提示し、次の追加要件を伴います。
Per [RFC7582] ("Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels"), when MP2MP tunnels are used for an MVPN, the root of the MP2MP tunnel is required to allocate and advertise "PE Distinguisher Labels" (Section 4 of [RFC6513]). These labels are assigned from the label space used by the root node for its upstream-assigned labels.
[RFC7582]ごとに、 "マルチキャスト仮想プライベートネットワーク（MVPN）：双方向Pトゥンネルを使用します"）、MP2MPトンネルがMVPNに使用される場合、MP2MPトンネルのルートは「PE disutiustiutiserラベル」を割り当てて宣伝するために必要です（セクション」（セクション」[RFC6513]の4）。これらのラベルは、ルートノードがアップストリーム割り当てのラベルに使用するラベルスペースから割り当てられます。
It is REQUIRED by this document that the PE Distinguisher Labels allocated by a particular node come from the same label space that the node uses to allocate its VPN-identifying labels.
このドキュメントでは、特定のノードによって割り当てられたPE違いのラベルは、ノードがVPNを識別するラベルを割り当てるために使用する同じラベル空間から得られることが必要です。
There are some additional issues to be considered when an MVPN or EVPN is using "tunnel segmentation" (see [RFC6514], [RFC7524], and Sections 5 and 6 of [RFC9572]).
MVPNまたはEVPNが「トンネルセグメンテーション」を使用している場合に考慮すべきいくつかの追加の問題があります（[RFC6514]、[RFC7524]、および[RFC9572]のセクション5および6）。
For selective tunnels that instantiate S-PMSIs (see Sections 2.1.1 and 3.2.1 of [RFC6513] and Section 4 of [RFC9572]), the procedures outlined above work only if tunnel segmentation is not used.
S-PMSISをインスタンス化する選択的トンネル（[RFC6513]のセクション2.1.1および3.2.1および[RFC9572]のセクション4を参照）については、トンネルセグメンテーションが使用されない場合にのみ、上記で概説した手順が機能します。
A selective tunnel carries one or more particular sets of flows to a particular subset of the PEs that attach to a given VPN or BD. Each set of flows is identified by an S-PMSI A-D route [RFC6514]. The PTA of the S-PMSI route identifies the tunnel used to carry the corresponding set of flows. Multiple S-PMSI routes can identify the same tunnel.
選択的トンネルは、特定のVPNまたはBDに付着するPESの特定のサブセットへの1つまたは複数の特定のフローセットを運びます。フローの各セットは、S-PMSI A-Dルート[RFC6514]によって識別されます。S-PMSIルートのPTAは、対応するフローセットを運ぶために使用されるトンネルを識別します。複数のS-PMSIルートは同じトンネルを識別できます。
When tunnel segmentation is applied to an S-PMSI, certain nodes are "segmentation points". A segmentation point is a node at the boundary between two segmentation regions. Let's call these "region A" and "region B". A segmentation point is an egress node for one or more selective tunnels in region A and an ingress node for one or more selective tunnels in region B. A given segmentation point must be able to receive traffic on a selective tunnel from region A and label-switch the traffic to the proper selective tunnel in region B.
トンネルセグメンテーションがS-PMSIに適用される場合、特定のノードは「セグメンテーションポイント」です。セグメンテーションポイントは、2つのセグメンテーション領域間の境界にあるノードです。これらの「リージョンA」と「リージョンB」と呼びましょう。セグメンテーションポイントは、領域Aの1つまたは複数の選択的トンネルの出力ノードと、領域Bの1つまたは複数の選択的トンネルの侵入ノードです。特定のセグメンテーションポイントは、領域Aおよびラベルから選択的トンネルのトラフィックを受信できる必要があります。トラフィックを地域Bの適切な選択トンネルに切り替えます
Suppose that one selective tunnel (call it "T1") in region A is carrying two flows, Flow-1 and Flow-2, identified by S-PMSI routes Route-1 and Route-2, respectively. However, it is possible that in region B, Flow-1 is not carried by the same selective tunnel that carries Flow-2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 and Flow-2 by tunnel T3. Then, when the segmentation point receives traffic from T1, it must be able to label-switch Flow-1 from T1 to T2, while also label-switching Flow-2 from T1 to T3. This implies that Route-1 and Route-2 must signal different labels in the PTA. For comparison, when segmentation is not used, they can all use the common per-VPN/BD DCB label.
領域Aの1つの選択トンネル（「T1」と呼ぶ）が、それぞれS-PMSIルートルート1とルート2で識別される2つのフロー、フロー1とフロー-2を搭載していると仮定します。ただし、領域Bでは、フロー-1が流れ2を運ぶのと同じ選択トンネルによって運ばれない可能性があります。領域Bでは、フロー-1がトンネルT2およびフロー-2によってトンネルT3によって運ばれているとしましょう。次に、セグメンテーションポイントがT1からトラフィックを受信すると、T1からT1へのラベルスイッチフロー1にラベルを付けることができ、同時にT1からT3にラベルスイッチフロー-2も表示できなければなりません。これは、ルート1とルート2がPTAの異なるラベルを信号する必要があることを意味します。比較のために、セグメンテーションを使用しない場合、それらはすべて一般的なVPN/BD DCBラベルを使用できます。
In this case, it is not practical to have a central entity assign domain-wide unique labels to individual S-PMSI routes. To address this problem, all PEs can be assigned their own disjoint label blocks in those few context-specific label spaces; each PE will independently allocate labels for a segmented S-PMSI from its own assigned label block. For example, PE1 allocates from label block [101~200], PE2 allocates from label block [201~300], and so on.
この場合、中央エンティティが個々のS-PMSIルートにドメイン全体の一意のラベルを割り当てることは実用的ではありません。この問題に対処するために、すべてのPESに、これらの少数のコンテキスト固有のラベルスペースに独自のdisjointラベルブロックを割り当てることができます。各PEは、独自の割り当てられたラベルブロックからセグメント化されたS-PMSIのラベルを独立して割り当てます。たとえば、PE1はラベルブロック[101〜200]から割り当てられ、PE2はラベルブロック[201〜300]などから割り当てます。
Allocating from disjoint label blocks can be used for VPN/BD/ES labels as well, though it does not address the original scaling issue, because there would be 1,000,000 labels allocated from those few context-specific label spaces in the original example, instead of just 1000 common labels.
Disjointラベルブロックからの割り当ては、VPN/BD/ESラベルにも使用できますが、元のスケーリングの問題には対処されていません。わずか1000の一般的なラベル。
Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-region I-PMSI) tunnels [RFC6514] [RFC7432] [RFC9572], labels need to be allocated per PMSI route. In the case of a per-PE PMSI route, the labels should be allocated from the label block allocated to the advertising PE. In the case of a per-AS/region PMSI route, different ASBRs/RBRs attached to the same source AS/region will advertise the same PMSI route. The same label could be used when the same route is advertised by different ASBRs/RBRs, though that requires coordination; a simpler way is for each ASBR/RBR to allocate a label from the label block allocated to itself (see Section 3.2.1).
同様に、PE（MVPN（C-*、C-*）S-PMSIまたはEVPN IMET）またはPER-AS/領域（MVPN INTER-AS I-PMSIまたはEVPN PER-REGION I-PMSI）トンネル[RFC6514] [RFC7432] [RFC9572]、ラベルはPMSIルートごとに割り当てる必要があります。PE PER PMSIルートの場合、ラベルは広告PEに割り当てられたラベルブロックから割り当てる必要があります。AS/地域PMSIルートごとに、/地域と同じソースに接続された異なるASBRS/RBRが同じPMSIルートを宣伝します。同じルートが異なるASBR/RBRによって宣伝されている場合、同じラベルを使用できますが、それには調整が必要です。より簡単な方法は、各ASBR/RBRがそれ自体に割り当てられたラベルブロックからラベルを割り当てることです（セクション3.2.1を参照）。
In the rest of this document, we call the label allocated for a particular PMSI a "(per-)PMSI label", just like we have (per-)VPN/BD/ ES labels. Notice that using a per-PMSI label in the case of a per-PE PMSI still has the original scaling issue associated with the upstream-assigned label, so per-region PMSIs are preferred. Within each AS/region, per-PE PMSIs are still used, though they do not go across borders and per-VPN/BD labels can still be used.
このドキュメントの残りの部分では、特定のPMSIに割り当てられたラベルを「（パー）PMSIラベル」と呼びます。PE PRPE PMSIの場合にPMSIあたりのラベルを使用すると、アップストリーム割り当てラベルに関連付けられた元のスケーリング問題があるため、領域ごとのPMSIが推奨されていることに注意してください。それぞれのAS/領域内で、PE PMSIごとに使用されていますが、境界を越えず、VPN/BDごとのラベルを使用できます。
Note that when a segmentation point re-advertises a PMSI route to the next segment, it does not need to re-advertise a new label unless the upstream or downstream segment uses ingress replication.
セグメンテーションポイントが次のセグメントへのPMSIルートを再承認した場合、上流または下流のセグメントがイングレスレプリケーションを使用しない限り、新しいラベルを再承認する必要はないことに注意してください。
Per-PMSI label allocation in the case of segmentation, whether for S-PMSIs or per-PE/region I-PMSIs, is applied so that segmentation points are able to label-switch traffic without having to do IP or Media Access Control (MAC) lookups in VRFs (the segmentation points typically do not have those VRFs at all). Alternatively, if the label scaling becomes a concern, the segmentation points could use (C-S,C-G) lookups in VRFs for flows identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/BD to share a VPN/BD-identifying label that leads to lookups in the VRFs. That label needs to be different from the label used in the per-PE/region I-PMSIs though, so that the segmentation points can label-switch other traffic (not identified by those S-PMSIs). However, this moves the scaling problem from the number of labels to the number of (C-S/*,C-G) routes in VRFs on the segmentation points.
S-PMSISであろうとPE/リージョンI-PMSISの場合、セグメンテーションの場合のPMSIラベルの割り当てが適用されるため、セグメンテーションポイントがIPまたはメディアアクセス制御を行わずにスイッチトラフィックにラベルを付けることができます（Mac）VRFのルックアップ（通常、セグメンテーションポイントにはこれらのVRFがまったくありません）。あるいは、ラベルのスケーリングが懸念になる場合、S-PMSISによって識別されるフローに対して、VRFのセグメンテーションポイントが（C-S、C-G）ルックアップを使用できます。これにより、同じVPN/BDのS-PMSISは、VRFSのルックアップにつながるVPN/BD識別ラベルを共有できます。ただし、このラベルは、PE/Region I-PMSISで使用されるラベルとは異なる必要があります。そのため、セグメンテーションポイントは他のトラフィックにラベルを付けることができます（これらのS-PMSISで識別されません）。ただし、これにより、スケーリングの問題がラベルの数から、セグメンテーションポイントのVRFの（C-S/*、C-G）ルートの数に移動します。
In summary, labels can be allocated and advertised in the following ways:
要約すると、ラベルは次の方法で割り当てられ、宣伝できます。
1. A central entity allocates per-VPN/BD/ES labels from the DCB. PEs advertise the labels with an indication that they are from the DCB.
1. 中央エンティティは、DCBからVPN/BD/ESラベルごとを割り当てます。PESは、それらがDCBからのものであることを示すラベルを宣伝しています。
2. A central entity allocates per-VPN/BD/ES labels from a few common context-specific label spaces and allocates labels from the DCB to identify those context-specific label spaces. PEs advertise the VPN/BD labels along with the context-identifying labels.
2. 中央エンティティは、いくつかの一般的なコンテキスト固有のラベルスペースからVPN/BD/ESラベルを割り当て、DCBからラベルを割り当てて、それらのコンテキスト固有のラベルスペースを識別します。PESは、VPN/BDラベルをコンテキスト識別ラベルとともに宣伝します。
3. A central entity assigns disjoint label blocks from a few context-specific label spaces to each PE and allocates labels from the DCB to identify those context-specific label spaces. A PE independently allocates a label for a segmented S-PMSI from its assigned label block and advertises the label along with the context-identifying label.
3. 中央のエンティティは、いくつかのコンテキスト固有のラベルスペースから各PEに分離ラベルブロックを割り当て、DCBからラベルを割り当てて、これらのコンテキスト固有のラベルスペースを識別します。PEは、割り当てられたラベルブロックからセグメント化されたS-PMSIのラベルを独立して割り当て、コンテキストを特定するラベルとともにラベルを宣伝します。
Option 1 is simplest, but it requires that all the PEs set aside a common label block for the DCB that is large enough for all the VPNs/BDs/ESs combined. Option 3 is needed only for segmented selective tunnels that are set up dynamically. Multiple options could be used in any combination, depending on the deployment situation.
オプション1は最も単純ですが、すべてのPESがすべてのVPNS/BDS/ESSを組み合わせて十分に大きいDCBに共通のラベルブロックを確保する必要があります。オプション3は、動的にセットアップされるセグメント化された選択的トンネルに対してのみ必要です。展開の状況に応じて、任意の組み合わせで複数のオプションを使用できます。
The Context-Specific Label Space ID Extended Community (EC) is a new Transitive Opaque EC with the following structure:
コンテキスト固有のラベルスペースID拡張コミュニティ（EC）は、次の構造を備えた新しい推移的な不透明ECです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 or 0x43 | 8 | ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID-Type:
IDタイプ：
A 2-octet field that specifies the type of Label Space ID. In this document, the ID-Type is 0, indicating that the ID-Value field is a label.
ラベルスペースIDのタイプを指定する2-OCTETフィールド。このドキュメントでは、IDタイプは0であり、ID-Valueフィールドがラベルであることを示しています。
ID-Value:
id-value：
A 4-octet field that specifies the value of the Label Space ID. When it is a label (with ID-Type 0), the most significant 20-bit portion is set to the label value.
ラベルスペースIDの値を指定する4-OCTETフィールド。ラベル（IDタイプ0を使用）の場合、最も重要な20ビット部分がラベル値に設定されます。
This document introduces a DCB-flag (Bit 47 as assigned by IANA) in the "Additional PMSI Tunnel Attribute Flags" BGP Extended Community [RFC7902].
このドキュメントでは、「追加のPMSIトンネル属性フラグ」BGP拡張コミュニティ[RFC7902]にDCB-FLAG（IANAによって割り当てられたビット47）を紹介します。
In the remainder of this document, when we say that a BGP-MVPN/EVPN A-D route carries a DCB-flag or has a DCB-flag attached to it, we mean the following:
このドキュメントの残りの部分では、BGP-MVPN/EVPN A-DルートにDCB-FLAGが搭載されているか、DCB-FLAGが付いていると言うと、次のことを意味します。
* The route carries a PTA and its Flags field has the Extension bit set, AND
* ルートにはPTAがあり、そのフラグフィールドには拡張ビットが設定されています。
* The route carries an "Additional PMSI Tunnel Attribute Flags" EC and its DCB-flag is set.
* ルートには「追加のPMSIトンネル属性フラグ」ECが搭載されており、DCB-FLAGが設定されています。
The protocol and procedures specified in this section MAY be used when BIER or P2MP/MP2MP tunnel aggregation is used for an MVPN/EVPN or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. When these procedures are used, all PE routers and segmentation points MUST support the procedures. How to ensure this behavior is outside the scope of this document.
このセクションで指定されたプロトコルと手順は、BierまたはP2MP/MP2MPトンネルの凝集がMVPN/EVPNに使用される場合、またはBier/P2MP/MP2MPトンネルがEVPNマルチホームで使用される場合に使用されます。これらの手順を使用する場合、すべてのPEルーターとセグメンテーションポイントは手順をサポートする必要があります。この動作がこのドキュメントの範囲外にあることを確認する方法。
Via methods outside the scope of this document, each VPN/BD/ES is assigned a label from the DCB or one of those few context-specific label spaces, and every PE that is part of the VPN/BD/ES is aware of the assignment. The ES label and the BD label MUST be assigned from the same label space. If PE Distinguisher Labels are used [RFC7582], they MUST be allocated from the same label space as well.
このドキュメントの範囲外のメソッドを介して、各VPN/BD/ESにはDCBまたはそれらの数少ないコンテキスト固有のラベルスペースの1つからのラベルが割り当てられ、VPN/BD/ESの一部であるすべてのPEは割り当て。ESラベルとBDラベルは、同じラベルスペースから割り当てる必要があります。PE違いラベルを使用している場合[RFC7582]、同じラベルスペースからも割り当てる必要があります。
In the case of tunnel segmentation, each PE is also assigned a disjoint label block from one of those few context-specific label spaces, and it allocates labels for its segmented PMSI routes from its assigned label block.
トンネルセグメンテーションの場合、各PEには、これらの少数のコンテキスト固有のラベルスペースの1つからの馬鹿げたラベルブロックも割り当てられ、割り当てられたラベルブロックからセグメント化されたPMSIルートのラベルを割り当てます。
When a PE originates/re-advertises an x-PMSI/IMET route, the route MUST carry a DCB-flag if and only if the label in its PTA is assigned from the DCB.
PEがX-PMSI/IMETルートを起源/再承認する場合、PTAのラベルがDCBから割り当てられている場合にのみ、ルートはDCB-FLAGを運ぶ必要があります。
If the VPN/BD/ES/PMSI label is assigned from one of those few context-specific label spaces, a Context-Specific Label Space ID EC MUST be attached to the route. The ID-Type in the EC is set to 0, and the ID-Value is set to a label allocated from the DCB and identifies the context-specific label space. When an ingress PE sends traffic, it imposes the DCB label that identifies the context-specific label space after it imposes the label (that is advertised in the Label field of the PTA in the x-PMSI/IMET route) for the VPN/ BD and/or the label (that is advertised in the ESI Label EC) for the ESI, and then imposes the encapsulation for the transport tunnel.
VPN/BD/ES/PMSIラベルが、これらの数少ないコンテキスト固有のラベルスペースのいずれかから割り当てられている場合、コンテキスト固有のラベルスペースID ECをルートに接続する必要があります。ECのIDタイプは0に設定され、ID値はDCBから割り当てられたラベルに設定され、コンテキスト固有のラベル空間を識別します。イングレスPEがトラフィックを送信すると、VPN/ BDのラベル（X-PMSI/ IMETルートのPTAのラベルフィールドに宣伝されている）を課すと、コンテキスト固有のラベル空間を識別するDCBラベルを課します。および/またはESIのラベル（ESIラベルECで宣伝されている）は、輸送トンネルのカプセル化を課します。
When a PE receives an x-PMSI/IMET route with the Context-Specific Label Space ID EC, it MUST place an entry in its default MPLS forwarding table to map the label in the EC to a corresponding context-specific label table. That table is used for the next label lookup for incoming data traffic with the label signaled in the EC.
PEがコンテキスト固有のラベルスペースID ECを使用してX-PMSI/IMETルートを受信する場合、ECのラベルを対応するコンテキスト固有のラベルテーブルにマッピングするために、デフォルトのMPLS転送テーブルにエントリを配置する必要があります。そのテーブルは、ECで合図されたラベルを使用して、着信データトラフィックの次のラベル検索に使用されます。
Then, the receiving PE MUST place an entry for the label that is in the PTA or ESI Label EC in either the default MPLS forwarding table (if the route carries the DCB-flag) or the context-specific label table (if the Context-Specific Label Space ID EC is present) according to the x-PMSI/IMET route.
次に、受信PEは、PTAまたはESIラベルECにあるラベルのエントリを、デフォルトのMPLS転送テーブル（ルートにDCB-FLAGを運ぶ場合）またはコンテキスト固有のラベルテーブル（コンテキスト - の場合）に配置する必要があります。X-PMSI/IMETルートに従って、特定のラベルスペースID ECが存在します。
An x-PMSI/IMET route MUST NOT carry both the DCB-flag and the Context-Specific Label Space ID EC. A received route with both the DCB-flag set and the Context-Specific Label Space ID EC attached MUST be treated as withdrawn. If neither the DCB-flag nor the Context-Specific Label Space ID EC is attached, the label in the PTA or ESI Label EC MUST be treated as the upstream-assigned label from the label space of the source PE, and procedures provided in [RFC6514] and [RFC7432] MUST be followed.
X-PMSI/IMETルートは、DCB-FLAGとコンテキスト固有のラベルスペースID ECの両方を搭載してはなりません。DCB-FLAGセットとコンテキスト固有のラベルスペースID ECの両方を備えた受信ルートは、撤回されたときに扱う必要があります。DCB-FLAGもコンテキスト固有のラベルスペースID ECも添付されていない場合、PTAまたはESIラベルECのラベルは、ソースPEのラベル空間から上流のラベルとして扱わなければなりません。RFC6514]および[RFC7432]に従う必要があります。
If a PE originates two x-PMSI/IMET routes with the same tunnel, it MUST ensure that one of the following scenarios applies, so that the PE receiving the routes can correctly interpret the label that follows the tunnel encapsulation of data packets arriving via the tunnel:
PEが同じトンネルを持つ2つのX-PMSI/IMETルートを発信する場合、ルートを受信するPEが到着するデータパケットのトンネルカプセル化に続くラベルを正しく解釈できるように、次のシナリオのいずれかが適用されることを確認する必要があります。トンネル：
* They MUST all have the DCB-flag,
* 彼らはすべてDCBフラグを持っている必要があります、
* They MUST all carry the Context-Specific Label Space ID EC,
* 彼らはすべて、コンテキスト固有のラベルスペースID ECを運ぶ必要があります。
* None of them have the DCB-flag, or
* それらのどれもDCB-FLAGを持っていません
* None of them carry the Context-Specific Label Space ID EC.
* それらのどれも、コンテキスト固有のラベルスペースID ECを運ぶものはありません。
Otherwise, a receiving PE MUST treat the routes as if they were withdrawn.
それ以外の場合、受信PEはルートを撤回したかのように扱う必要があります。
This document allows three methods (Section 3.3) of label allocation for MVPN PEs [RFC6514] or EVPN PEs [RFC7432] and specifies corresponding signaling and procedures. The first method (Option 1) is the equivalent of using common SRGBs [RFC8402] from the regular per-platform label space. The second method (Option 2) is the equivalent of using common SRGBs from a third-party label space [RFC5331]. The third method (Option 3) is a variation of the second in that the third-party label space is divided into disjoint blocks for use by different PEs, where each PE will use labels from its respective block to send traffic. In all cases, a receiving PE is able to identify one of the few label forwarding tables to forward incoming labeled traffic.
このドキュメントでは、MVPN PES [RFC6514]またはEVPN PES [RFC7432]のラベル割り当ての3つの方法（セクション3.3）を許可し、対応するシグナル伝達と手順を指定します。最初のメソッド（オプション1）は、通常のプラットフォームラベル空間から一般的なSRGBS [RFC8402]を使用することと同等です。2番目の方法（オプション2）は、サードパーティのラベル空間[RFC5331]から一般的なSRGBを使用することと同等です。3番目のメソッド（オプション3）は、サードパーティのラベルスペースが異なるPESで使用するための分離ブロックに分割され、各PEがそれぞれのブロックからラベルを使用してトラフィックを送信するという点で、2番目の方法のバリエーションです。すべての場合において、受信PEは、数少ないラベル転送テーブルの1つを特定して、着信ラベルのトラフィックを転送することができます。
[RFC6514], [RFC7432], [RFC8402], and [RFC5331] do not list any security concerns related to label allocation methods, and this document does not introduce any new security concerns in this regard.
[RFC6514]、[RFC7432]、[RFC8402]、および[RFC5331]は、ラベル割り当て方法に関連するセキュリティ上の懸念をリストしていません。
IANA has made the following assignments:
IANAは次の割り当てを行いました。
* Bit 47 (DCB) in the "Additional PMSI Tunnel Attribute Flags" registry:
* 「追加のPMSIトンネル属性フラグ」レジストリのビット47（DCB）：
+==========+======+===========+
| Bit Flag | Name | Reference |
+==========+======+===========+
| 47 | DCB | RFC 9573 |
+----------+------+-----------+
Table 1
* Sub-type 0x08 for "Context-Specific Label Space ID Extended Community" in the "Transitive Opaque Extended Community Sub-Types" registry:
* 「コンテキスト固有のラベルスペースID拡張コミュニティ」のサブタイプ0x08「Transitive Opaque Extended Community Sub-Types」レジストリ：
+================+=============================+===========+
| Sub-Type Value | Name | Reference |
+================+=============================+===========+
| 0x08 | Context-Specific Label | RFC 9573 |
| | Space ID Extended Community | |
+----------------+-----------------------------+-----------+
Table 2
IANA has created the "Context-Specific Label Space ID Type" registry within the "Border Gateway Protocol (BGP) Extended Communities" group of registries. The registration procedure is First Come First Served [RFC8126]. The initial assignment is as follows:
IANAは、「Border Gateway Protocol（BGP）拡張コミュニティ」レジストリグループ内の「コンテキスト固有のラベルスペースIDタイプ」レジストリを作成しました。登録手順は、最初に提供されます[RFC8126]。最初の割り当ては次のとおりです。
+============+============+===========+
| Type Value | Name | Reference |
+============+============+===========+
| 0 | MPLS Label | RFC 9573 |
+------------+------------+-----------+
| 1-254 | Unassigned | |
+------------+------------+-----------+
| 255 | Reserved | |
+------------+------------+-----------+
Table 3
[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>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>.
[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>.
[BIER-EVPN]
Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-evpn-14, 2 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
evpn-14>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or
Multicast (BUM) Procedures", RFC 9572,
DOI 10.17487/RFC9572, May 2024,
<https://www.rfc-editor.org/info/rfc9572>.
The authors thank Stephane Litkowski, Ali Sajassi, and Jingrong Xie for their reviews of, comments on, and suggestions for this document.
著者は、この文書のレビュー、コメント、提案について、Stephane Litkowski、Ali Sajassi、Jingrong Xieに感謝します。
The following individual also contributed to this document:
次の個人もこの文書に貢献しました。
Selvakumar Sivaraj
Juniper Networks
Email: ssivaraj@juniper.net
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Eric Rosen
Individual
Email: erosen52@gmail.com
Wen Lin
Juniper Networks
Email: wlin@juniper.net
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.com
IJsbrand Wijnands
Individual
Email: ice@braindump.be