Internet Engineering Task Force (IETF) J. Rabadan, Ed.
Request for Comments: 9541 S. Sathappan
Category: Standards Track K. Nagaraj
ISSN: 2070-1721 Nokia
M. Miyake
T. Matsuda
Softbank
March 2024
Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPNs) to deploy Ethernet Local Area Network (E-LAN) services in large Multiprotocol Label Switching (MPLS) networks. That combination is what we refer to as "PBB-EVPN." Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active multihomed Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called "C-MAC flush" that works for different Ethernet Segment Backbone MAC (B-MAC) address allocation models. This document complements those C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined (i.e., the attachment circuit is associated with a zero Ethernet Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level granularity.
プロバイダーバックボーンブリッジング（PBB）をイーサネット仮想プライベートネットワーク（EVPN）と組み合わせて、イーサネットローカルエリアネットワーク（E-LAN）サービスを大規模なマルチプロトコルラベルスイッチング（MPLS）ネットワークで展開できます。その組み合わせは、「PBB-EVPN」と呼ばれるものです。シングルアクティブなマルチホミングおよびサービスごとのインスタンス識別子（I-SID）ロードバランスを提供して、デバイスと集約ネットワークにアクセスすることができます。単一活性マルチホームのイーサネットセグメント（ESS）の障害が発生した場合にネットワークの収束を高速化するために、PBB-EVPNは、異なるイーサネットで機能する「C-MACフラッシュ」と呼ばれる顧客MAC（C-MAC）のフラッシュメカニズムを定義します。セグメントバックボーンMAC（B-MAC）アドレス割り当てモデル。このドキュメントは、PBB-EVPN ESSが定義されていない場合のC-MACフラッシュ手順を補完します（つまり、アタッチメント回路はゼロイーサネットセグメント識別子（ESI）に関連付けられ、C-MACフラッシュにはI-SID-レベルが必要です粒度。
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/rfc9541.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9541で取得できます。
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ライセンステキストを含める必要があります。
1. Introduction
1.1. Abbreviations
1.2. Terminology and Conventions
2. Solution Requirements
3. EVPN BGP Encoding for I-SID-Based C-MAC Flush
4. Solution Description
4.1. I-SID-Based C-MAC Flush Activation Procedures
4.2. C-MAC Flush Generation
4.3. C-MAC Flush Process upon Receiving a C-MAC Flush
Notification
5. Conclusions
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
[RFC7623] defines how Provider Backbone Bridging (PBB) can be combined with Ethernet Virtual Private Networks (EVPNs) to deploy E-LAN services in very large MPLS networks. [RFC7623] also describes how Single-Active multihoming and per-I-SID load-balancing can be provided to access devices and aggregation networks. When Access Ethernet and/or MPLS networks exist, [EVPN-VIRTUAL-ES] describes how virtual Ethernet Segments (ESs) can be associated with a group of Ethernet Virtual Circuits (EVCs) or even pseudowires (PWs). In order to speed up the network convergence in case of failures on Single-Active multihomed ESs, [RFC7623] defines a Customer MAC flush mechanism that works for different ES B-MAC address allocation models.
[RFC7623]は、プロバイダーのバックボーンブリッジング（PBB）をイーサネット仮想プライベートネットワーク（EVPN）と組み合わせて、非常に大きなMPLSネットワークにE-LANサービスを展開する方法を定義します。[RFC7623]は、デバイスと集約ネットワークにアクセスするために、単一活動的なマルチホームとI-SIDごとの負荷分散をどのように提供できるかについても説明しています。アクセスイーサネットおよび/またはMPLSネットワークが存在する場合、[EVPN-Virtual-ES]は、仮想イーサネットセグメント（ESS）がイーサネット仮想回路（EVC）または擬似動物（PWS）のグループにどのように関連付けられるかを説明します。単一活動的なマルチホームESSの障害が発生した場合にネットワークの収束をスピードアップするために、[RFC7623]は、異なるES B-MACアドレス割り当てモデルで機能する顧客MACフラッシュメカニズムを定義します。
In some cases, the administrative entities that manage the access devices or aggregation networks do not demand multihomed ESs from the PBB-EVPN provider, but simply demand multiple single-homed ESs. Single-homed ESs use null ESIs, whereas multihomed ESs use non-null ESIs. If using single-homed ESs, the PBB-EVPN network is no longer aware of the redundancy offered by the access administrative entity. Figure 1 shows an example where the PBB-EVPN network provides four different Attachment Circuits (ACs) for I-SID1, with those ACs not being part of any ES or virtual ES. (Therefore, they are referred to as null virtual Ethernet Segments.)
場合によっては、アクセスデバイスまたは集約ネットワークを管理する管理エンティティには、PBB-EVPNプロバイダーにマルチホームのESSを要求しませんが、単純に複数の単一給のESSを要求します。シングルホームのessはnull esisを使用しますが、マルチホームのessは非ヌルESIを使用します。シングルホームESSを使用している場合、PBB-EVPNネットワークは、アクセス管理エンティティが提供する冗長性を認識しなくなります。図1は、PBB-EVPNネットワークがI-SID1に4つの異なるアタッチメントサーキット（ACS）を提供し、それらのACSがESまたは仮想ESの一部ではない場合の例を示しています。（したがって、それらはnull仮想イーサネットセグメントと呼ばれます。）
<----G.8032----><--PBB-EVPN Network-----><----MPLS---->
Access MPLS Access
Ring Network
I-SID1 ESI +------+ +------+
+----+ null| PE1 |---------| PE3 |
|CE1 |----------|B-MAC1| |B-MAC3| ESI null
+----+ active| | | |----+ PW
| +------+ +------+ \active
| | | \ +----+
| | | ==|CE3 |I-SID1
| | | / +----+
|standby ESI +------+ +------+ / PW
+----+ null| PE2 | | PE4 |----+ standby
|CE2 |----------|B-MAC2| |B-MAC4| ESI null
+----+ active| |---------| |
I-SID1 +------+ +------+
Figure 1: PBB-EVPN and Non-ES-Based Redundancy
図1：PBB-EVPNおよび非ESベースの冗長性
In the example in Figure 1, CE1, CE2, and CE3 are attached to the same service, identified by I-SID1, in the PBB-EVPN PEs. CE1 and CE2 are connected to the PEs via "Ethernet ring protection switching" as specified in [G.8032], and their ACs to PE1 and PE2 are represented by a port and VLAN identifier. CE3 is dual-homed to PE3 and PE4 through an active/standby PW, and its AC to the PEs is represented by a PW. Each of the four PEs uses a dedicated Backbone MAC address as a source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4, respectively) when encapsulating customer frames in PBB packets and forwarding those PBB packets to the remote PEs as per [RFC7623]. There are no multihomed ESs defined in the PBB-EVPN network of the example; that is why the four ACs in Figure 1 show the text "ESI null", which means the Ethernet Segment Identifier on those ACs is zero. Since there are no multihomed ESs defined, the PEs keep their ACs active as long as the physical connectivity is established and the CEs are responsible for managing the redundancy, avoiding loops, and providing per-I-SID load-balancing to the PBB-EVPN network. Examples of CEs managing their own redundancy are described in [G.8032], or [RFC4762] for active/standby PWs.
図1の例では、Ce1、Ce2、およびCe3は、PBB-EVPN PESでI-SID1によって識別される同じサービスに接続されています。Ce1とCe2は[G.8032]で指定されている「イーサネットリング保護スイッチング」を介してPESに接続され、PE1とPE2へのACSはポートおよびVLAN識別子で表されます。CE3は、アクティブ/スタンバイPWを介してPE3とPE4にデュアルホームされており、PESへのACはPWで表されます。4つのPESのそれぞれは、PBBパケットの顧客フレームをカプセル化し、それらのPBBパケットをPBBパケットを転送するときに、ソースMACアドレス（それぞれB-MAC1、B-MAC2、B-MAC3、およびB-MAC4）として専用のバックボーンMACアドレスを使用します。[RFC7623]に従ってリモートPE。この例のPBB-EVPNネットワークには、多目的なESSが定義されていません。そのため、図1の4つのACSがテキスト「ESI Null」を示しています。つまり、これらのACSのイーサネットセグメント識別子はゼロです。マルチホームのESSが定義されていないため、PESは物理的な接続性が確立され、CESが冗長性の管理、ループの回避、PBB-EVPNへの一人当たりの負荷分散を提供する限り、ACSをアクティブに保ちます。通信網。独自の冗長性を管理するCESの例は、アクティブ/スタンバイPWSの[G.8032]、または[RFC4762]に記載されています。
For instance, in normal conditions, CE2 will block its link to CE1 and CE3 will block its forwarding path to PE4. In this situation, a failure in one of the redundant ACs will trigger the CEs to start using their redundant paths; however, those failures will not trigger any C-MAC flush procedures in the PEs that implement [RFC7623], since the PEs are not using the PBB-EVPN multihoming procedures. For example:
たとえば、通常の条件では、CE2はCE1へのリンクをブロックし、CE3はPE4への転送パスをブロックします。この状況では、冗長なACSの1つでの障害により、CESが冗長パスの使用を開始するようになります。ただし、PESがPBB-EVPNマルチホーム手順を使用していないため、これらの障害は[RFC7623]を実装するPESでC-MACフラッシュ手順をトリガーしません。例えば：
* If the active PW from CE3 (to PE3) fails and the failure is due to the entire PE3 node failing, then the procedures in [RFC7623] guarantee that all the remote PEs flush all the C-MACs associated with B-MAC3 (the B-MAC of PE3). In this case, CE3 detects the fault due to the PW going operationally down.
* CE3からのアクティブなPW（PE3）が故障し、障害がPE3ノード全体が故障しているためである場合、[RFC7623]の手順は、すべてのリモートPEがB-MAC3に関連付けられたすべてのC-MACをフラッシュすることを保証します。-mac of pe3）。この場合、CE3はPWが動作的にダウンするため、障害を検出します。
* However, if the active PW from CE3 (to PE3) fails (but PE3 is still operationally up), following the procedures in [RFC7623], neither PE3 nor PE4 issue a C-MAC flush message. Therefore, the remote PEs will continue pointing at PE3's B-MAC to reach CE3's C-MACs, until the C-MACs age out in the I-SID1 forwarding tables. In this case, PE3 may use any of the existing PW notifications so that CE3 switches the active PW to PE4.
* ただし、[RFC7623]の手順に従って、CE3（ただしPE3）からのアクティブなPWが故障している場合（ただし、PE3はまだ動作中に操作されています）、PE3もPE4もC-Macフラッシュメッセージを発行しません。したがって、リモートPEは、C-MACがI-SID1転送テーブルで齢を測定するまで、CE3のC-MACに到達するためにPE3のB-MACを指し続けます。この場合、PE3は既存のPW通知のいずれかを使用して、CE3がアクティブなPWをPE4に切り替えるようにすることができます。
* The same issue is exposed when the active PW from CE3 switches over from PE3 to PE4 due to a manual operation on CE3; that is, neither PE3 nor PE4 trigger any C-MAC flush notification and the remote PEs continue sending the traffic to PE3 until the C-MACs age out.
* CE3の手動操作により、CE3からのアクティブなPWがPE3からPE4に切り替わると、同じ問題が公開されます。つまり、PE3もPE4もC-MACフラッシュ通知をトリガーせず、リモートPEはC-MACSが老化するまでトラフィックをPE3に送信し続けます。
[RFC7623] provides a C-MAC flush solution based on a shared B-MAC update along with the MAC Mobility extended community where the sequence number is incremented. However, the procedure is only used along with multihomed ESs. Even if that procedure could be used for null ESs, as in the example of Figure 1, the Customer MAC flush procedure in [RFC7623] would result in unnecessary flushing of unaffected I-SIDs on the remote PEs, and subsequent flooding of unknown unicast traffic in the network. For instance, in the case that CE3 switches its active PW over to PE4, a potential solution reusing the existing C-MAC flush notifications in [RFC7623] is for PE3 to issue an update for the MAC/IP Advertisement route of B-MAC3 with a higher sequence number. However, this update would cause unnecessary Customer MAC flushing for all the I-SIDs attached to PE3 (supposing multiple I-SIDs in PE3) rather than for only I-SID1.
[RFC7623]は、シーケンス番号が増加するMACモビリティ拡張コミュニティとともに、共有B-MACアップデートに基づいたC-MACフラッシュソリューションを提供します。ただし、この手順は、マルチホームのESSと一緒にのみ使用されます。図1の例のように、その手順をnull essに使用できたとしても、[RFC7623]の顧客Macフラッシュ手順は、リモートPEで影響を受けていないI-SIDの不必要な洗浄、およびそれに続くユニキャストトラフィックの未知の洪水をもたらします。ネットワーク内。たとえば、CE3がアクティブPWをPE4に切り替える場合、[RFC7623]の既存のC-MACフラッシュ通知を再利用する潜在的なソリューションは、PE3がB-MAC3のMAC/IP広告ルートの更新を発行するためです。より高いシーケンス番号。ただし、この更新により、I-SID1のみではなく、PE3に接続されたすべてのI-SID（PE3の複数のI-SIDを想定）に不必要な顧客Macフラッシュが発生します。
This document describes an extension of the Customer MAC flush procedures in [RFC7623], so that in the failure example above, PE3 can trigger a Customer MAC flush notification that makes PE1, PE2, and PE4 flush all the Customer MACs associated with PE3's B-MAC3 and (only) I-SID1. In order to do so, this specification introduces the encoding of the I-SID in the MAC/IP Advertisement routes advertised for the B-MACs. The C-MAC flush procedure explained in this document is referred to as "PBB-EVPN I-SID-based C-MAC flush" and can be used in PBB-EVPN networks with null or non-null (virtual) ESs.
このドキュメントでは、[RFC7623]の顧客Macフラッシュ手順の拡張機能について説明しているため、上記の障害例では、PE3がPE1、PE2、およびPE4がPE3のB-に関連付けられたすべての顧客Macをフラッシュする顧客MACフラッシュ通知をトリガーできます。Mac3および（のみ）i-sid1。そうするために、この仕様では、B-MACに宣伝されているMAC/IP広告ルートでのI-SIDのエンコードを紹介します。このドキュメントで説明されているC-MACフラッシュ手順は、「PBB-EVPN I-SIDベースのC-MACフラッシュ」と呼ばれ、NULLまたは非ヌル（仮想）ESSを使用してPBB-EVPNネットワークで使用できます。
This specification assumes that the reader is familiar with the procedures in [RFC7623].
この仕様は、読者が[RFC7623]の手順に精通していることを前提としています。
AC:
AC:
Attachment Circuit
アタッチメント回路
B-MAC:
b-mac：
Backbone MAC
バックボーンMac
CE:
CE:
Customer Edge
顧客のエッジ
C-MAC:
c-mac：
Customer MAC
カスタマーマック
ES:
ES:
Ethernet Segment
イーサネットセグメント
ESI:
ESI:
Ethernet Segment Identifier
イーサネットセグメント識別子
EVI:
EVI:
EVPN Instance
EVPNインスタンス
EVPN:
EVPN：
Ethernet Virtual Private Network (as in [RFC7432])
イーサネット仮想プライベートネットワーク（[RFC7432]のように）
I-SID:
i-sid：
Service Instance Identifier
サービスインスタンス識別子
MAC:
MAC:
Media Access Control
報道規制
MAC-VRF:
MAC-VRF：
MAC Virtual Routing and Forwarding
Mac仮想ルーティングと転送
PBB-EVPN:
PBB-EVPN：
Provider Backbone Bridging and EVPN (as in [RFC7623])
プロバイダーバックボーンブリッジングとEVPN（[RFC7623]のように）
PE:
PE:
Provider Edge
プロバイダーエッジ
Familiarity with the terminology in [RFC7623] is expected.
[RFC7623]の用語に精通していることが予想されます。
B-MAC/0 route:
b-mac/0ルート：
This is an EVPN MAC/IP Advertisement route that uses a B-MAC in the MAC address field and a zero Ethernet Tag ID.
これは、MACアドレスフィールドでB-MACとゼロイーサネットタグIDを使用するEVPN MAC/IP広告ルートです。
B-MAC/I-SID route:
b-mac/i-sidルート：
This is an EVPN MAC/IP Advertisement route that uses a B-MAC in the MAC address field and an I-SID in the Ethernet Tag field. It is used to notify remote PEs about the required C-MAC flush procedure for the C-MACs associated with the advertised B-MAC and I-SID.
これは、MACアドレスフィールドでB-MACとイーサネットタグフィールドにI-SIDを使用するEVPN MAC/IP広告ルートです。これは、広告されたB-MACおよびI-SIDに関連付けられたC-MACに必要なC-MACフラッシュ手順についてリモートPEに通知するために使用されます。
G.8032:
G.8032：
Refers to Ethernet ring protection switching as described in [G.8032].
[G.8032]に記載されているように、イーサネットリング保護スイッチングを指します。
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]で説明されているように解釈されます。
The following requirements are followed by the C-MAC flush solution described in this document:
次の要件に続いて、このドキュメントで説明されているC-MACフラッシュソリューションが続きます。
a. The solution MUST prevent packet-loss scenarios in case of failures on null ES ACs (Attachment Circuits not associated with an ES; that is, their corresponding ESI is zero) when the access device or access network is responsible for the redundancy.
a. このソリューションは、アクセスデバイスまたはアクセスネットワークが冗長性に責任を負う場合、null ES ACS（ESに関連付けられていないアタッチメントサーキット、つまり対応するESI）の場合のパケット損失シナリオを防ぐ必要があります。
b. This extension described in this document MUST work with Single-Active non-null ESs and virtual ESs, irrespective of the PE B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC, as in [RFC7623]).
b. このドキュメントで説明されているこの拡張機能は、PE B-MACアドレスの割り当て（[RFC7623]のように、専用のPER-ES B-MACまたは共有B-MAC）に関係なく、単一活性の非ヌルESSおよび仮想ESSで動作する必要があります。
c. In case of failure on the egress PE, the solution MUST provide a C-MAC flush notification at the B-MAC and I-SID granularity level.
c. 出力PEが故障した場合、ソリューションはB-MACおよびI-SID粒度レベルでC-MACフラッシュ通知を提供する必要があります。
d. The solution MUST provide a reliable C-MAC flush notification in PBB-EVPN networks that use Route Reflectors (RRs). MAC flushing needs to be provided to all affected I-SIDs in spite of the BGP flush notification messages being aggregated at the RR.
d. このソリューションは、ルートリフレクター（RRS）を使用するPBB-EVPNネットワークで信頼できるC-MACフラッシュ通知を提供する必要があります。RRで集約されているBGPフラッシュ通知メッセージにもかかわらず、Macフラッシュをすべての影響を受けるI-SIDに提供する必要があります。
e. The solution MUST coexist in [RFC7623] networks where there are PEs that do not support this specification.
e. ソリューションは、この仕様をサポートしていないPESがある[RFC7623]ネットワークに共存する必要があります。
f. The solution SHOULD be enabled or disabled by an administrative option on a per-PE and per-I-SID basis (as opposed to always being enabled for all the I-SIDs).
f. ソリューションは、すべてのI-SIDで常に有効にされているのではなく、PEごととPER-I-SIDベースで管理オプションによって有効または無効にする必要があります。
The solution does not use any new BGP attributes but reuses the MAC Mobility extended community as an indication of C-MAC flush (as in [RFC7623]) and encodes the I-SID in the Ethernet Tag field of the EVPN MAC/IP advertisement route. As a reference, Figure 2 shows the MAC Mobility extended community and the EVPN MAC/IP advertisement route that are used as specified in [RFC7432] and used in this document as a C-MAC flush notification message.
ソリューションは、新しいBGP属性を使用せず、Mac Movility ExtendedコミュニティをC-Mac Flush（[RFC7623]のように）の指標として再利用し、EVPN MAC/IP広告ルートのイーサネットタグフィールドのI-SIDをエンコードします。参照として、図2は、[RFC7432]で指定され、C-MACフラッシュ通知メッセージとしてこのドキュメントで使用されているMACモビリティ拡張コミュニティとEVPN MAC/IP広告ルートを示しています。
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=0x06 | Sub-Type=0x03 | Flags | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------------------------------+
| Route Distinguisher |
+---------------------------------------+
| ESI = 0 |
+---------------------------------------+
| Ethernet Tag ID = I-SID |
+---------------------------------------+
| MAC Address Length = 48 |
+---------------------------------------+
| B-MAC Address |
+---------------------------------------+
| IP Address Length = 0 |
+---------------------------------------+
| MPLS Label1 |
+---------------------------------------+
Figure 2: C-MAC Flush Notification Encoding: B-MAC/I-SID Route
図2：C-MACフラッシュ通知エンコード：B-MAC/I-SIDルート
Where:
ただし：
* The route's route distinguisher and route targets are the ones corresponding to its EVI. Alternatively to the EVI's Route Target (RT), the route MAY be tagged with an RT auto-derived from the Ethernet Tag (I-SID) instead. [RFC7623] describes how the EVPN MAC/IP Advertisement routes can be advertised along with the EVI RT or an RT that is derived from the I-SID.
* ルートのルートの区別器とルートのターゲットは、そのEVIに対応するものです。代わりに、EVIのルートターゲット（RT）に代わって、代わりにイーサネットタグ（I-SID）から自動由来のRTでタグ付けされる場合があります。[RFC7623]は、EVPN MAC/IP広告ルートを、I-SIDから派生したEVI RTまたはRTとともにどのように宣伝できるかを説明しています。
* The Ethernet Tag encodes the I-SID. This indicates to the PE that it must flush the C-MACs for that encoded I-SID, upon reception of the route.
* イーサネットタグはI-SIDをエンコードします。これは、ルートを受信したときに、エンコードされたI-SIDのためにC-Macsをフラッシュする必要があることをPEに示します。
* The MAC address field encodes the B-MAC address. This indicates to the PE that it must flush the C-MACs associated with that encoded B-MAC, upon reception of the route.
* MACアドレスフィールドは、B-MACアドレスをエンコードします。これは、ルートを受信すると、エンコードされたB-MACに関連付けられたC-MACをフラッシュする必要があることをPEに示します。
* The MAC Mobility extended community is used as in [RFC7623], where an increment in the sequence number between two updates for the same B-MAC/I-SID will be interpreted as a C-MAC flush notification for the corresponding B-MAC and I-SID.
* Mac Mobility Extendedコミュニティは[RFC7623]のように使用されます。ここでは、同じB-MAC/I-SIDの2つの更新の間のシーケンス番号の増分が、対応するB-MACおよび対応するB-MACのC-MACフラッシュ通知として解釈されます。i-sid。
All the other fields are set and used as defined in [RFC7623]. This document will refer to this route as the "B-MAC/I-SID route", as opposed to the EVPN MAC/IP Advertisement route used in [RFC7623] that contains a specific B-MAC and the Ethernet Tag ID set to zero. This document uses the term "B-MAC/0 route" to represent a B-MAC route advertised with an Ethernet Tag ID = 0.
他のすべてのフィールドは設定され、[RFC7623]で定義されているように使用されます。このドキュメントは、このルートを[B-MAC/I-SIDルート]と呼びます。これは、特定のB-MACとゼロに設定されたイーサネットタグIDを含む[RFC7623]で使用されるEVPN MAC/IP広告ルートとは対照的です。。このドキュメントでは、「B-Mac/0ルート」という用語を使用して、イーサネットタグID = 0で宣伝されているB-MACルートを表します。
Note that this B-MAC/I-SID route will be accepted and reflected by any RR as specified in [RFC7432], since no new attributes or values are used. A PE receiving the route will process the received B-MAC/ I-SID update only in the case of supporting the procedures described in this document.
このb-mac/i-sidルートは、新しい属性または値が使用されないため、[RFC7432]で指定されているRRによって受け入れられ、反映されることに注意してください。ルートを受信するPEは、このドキュメントで説明されている手順をサポートする場合にのみ、受信したB-MAC/ I-SIDアップデートを処理します。
Figure 1 will be used in the description of the solution. CE1, CE2, and CE3 are connected to ACs associated with I-SID1, where no (multihomed) ESs have been enabled, and the ACs and PWs are in active or standby state as per Figure 1.
図1は、ソリューションの説明で使用されます。Ce1、Ce2、およびCe3は、I-SID1に関連付けられたACSに接続されており、NO（MultiHomed）ESSが有効になっており、ACSとPWは図1に従ってアクティブまたはスタンバイ状態です。
Enabling or disabling I-SID-based C-MAC flush SHOULD be an administrative choice on the system that MAY be configured per I-SID (I-Component, Service Instance Component), as opposed to being configured for all I-SIDs. When enabled on a PE:
I-SIDベースのC-MACフラッシュの有効化または無効化は、すべてのI-SIDで構成されているのではなく、I-SID（i-Component、Service Instanceコンポーネント）ごとに構成される可能性のあるシステム上の管理的な選択である必要があります。PEで有効になった場合：
a. The PE will be able to generate B-MAC/I-SID routes as C-MAC Flush notifications for the remote PEs.
a. PEは、リモートPEのC-MACフラッシュ通知としてB-MAC/I-SIDルートを生成できます。
b. The PE will be able to process B-MAC/I-SID routes received from remote PEs.
b. PEは、リモートPEから受信したB-MAC/I-SIDルートを処理できます。
The PE MUST follow the procedures in [RFC7623] for C-MAC flush. This specification provides some additional procedures when I-SID-based C-MAC flush is enabled.
PEは、C-MACフラッシュの[RFC7623]の手順に従う必要があります。この仕様は、I-SIDベースのC-MACフラッシュが有効になっている場合、いくつかの追加手順を提供します。
This C-MAC flush specification is described in three sets of procedures:
このC-Macフラッシュ仕様は、3つの手順で説明されています。
* I-SID-based C-MAC flush activation
* I-SIDベースのC-MACフラッシュアクティベーション
* C-MAC flush notification generation upon AC failures
* AC障害時のC-MACフラッシュ通知生成
* C-MAC flush process upon receiving a C-MAC flush notification
* C-MACフラッシュ通知を受信したC-MACフラッシュプロセス
The following behavior MUST be followed by the PBB-EVPN PEs following this specification. Figure 1 is used as a reference.
次の動作に続いて、この仕様に従ってPBB-EVPN PESが続く必要があります。図1は参照として使用されます。
* As in [RFC7623], each PE advertises a shared B-MAC in a B-MAC/0 route (with B-MAC1, B-MAC2, B-MAC3, and B-MAC4 in the MAC address field, respectively). This is the B-MAC that each PE will use as B-MAC SA (Source Address) when encapsulating the frames received on any local single-homed AC. Each PE will import the received B-MAC/0 routes from the remote PEs and will install the B-MACs in its B-component (Backbone Component) MAC-VRF. For instance, PE1 will advertise B-MAC1/0 and will install B-MAC2, B-MAC3, and B-MAC4 in its MAC-VRF.
* [RFC7623]のように、各PEはB-MAC/0ルートで共有B-MACを宣伝します（それぞれB-MAC1、B-MAC2、B-MAC3、およびB-MAC4をMACアドレスフィールドでB-MAC4を使用）。これは、ローカルシングルホームACで受信したフレームをカプセル化するときに、各PEがB-MAC SA（ソースアドレス）として使用するB-MACです。各PEは、リモートPEから受信したB-MAC/0ルートをインポートし、B-MACSをB-MACS（バックボーンコンポーネント）MAC-VRFにインストールします。たとえば、PE1はB-MAC1/0を宣伝し、MAC-VRFにB-Mac2、B-Mac3、およびB-Mac4をインストールします。
* Assuming I-SID-based C-MAC flush is activated for I-SID1, the PEs will advertise the shared B-MAC with I-SID1 encoded in the Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will receive B-MAC2/1, B-MAC3/1, and B-MAC4/1. The receiving PEs MUST use these B-MAC/I-SID routes only for C-MAC flush procedures and they MUST NOT be used to add/withdraw any B-MAC entry in the MAC-VRFs. As per [RFC7623], only B-MAC/0 routes can be used to add/ withdraw B-MACs in the MAC-VRFs.
* I-SIDベースのC-MACフラッシュがI-SID1に対してアクティブになっていると仮定すると、PESはイーサネットタグでエンコードされたI-SID1を使用して共有B-MACを宣伝します。つまり、PE1はB-Mac1/1を宣伝し、B-Mac2/1、B-Mac3/1、およびB-Mac4/1を受け取ります。受信PEは、これらのB-MAC/I-SIDルートをC-MACフラッシュ手順にのみ使用する必要があり、MAC-VRFのB-MACエントリを追加/撤回するために使用してはなりません。[RFC7623]によると、B-MAC/ 0ルートのみを使用して、MAC-VRFSにB-MACを追加/撤回できます。
* The above procedure MAY also be used for dedicated B-MACs (B-MACs allocated per ES).
* 上記の手順は、専用のB-MAC（ESごとに割り当てられたB-MAC）にも使用できます。
If, for instance, there is a failure on PE1's AC, PE1 will generate an update including B-MAC1/1 along with the MAC Mobility extended community where the Sequence Number has been incremented. The reception of the B-MAC1/1 with an increment in the sequence number will trigger the C-MAC flush procedures on the receiving PEs.
たとえば、PE1のACに障害がある場合、PE1はB-MAC1/1を含むアップデートを生成し、MACモビリティ拡張コミュニティがシーケンス番号が増加しました。シーケンス番号の増分を使用したB-MAC1/1の受信は、受信PESのC-MACフラッシュ手順をトリガーします。
* An AC going operationally down MUST generate a B-MAC/I-SID with a higher Sequence Number. If the AC going down makes the entire local I-SID go operationally down, the PE will withdraw the B-MAC/ I-SID route for the I-SID.
* ACは動作的にダウンする必要がありますが、シーケンス番号が高いB-MAC/I-SIDを生成する必要があります。ACが下がっていると、ローカルI-SID全体が動作して操作されている場合、PEはI-SIDのB-MAC/ I-SIDルートを引き出します。
* An AC going operationally up SHOULD NOT generate any B-MAC/I-SID update, unless it activates its corresponding I-SID, in which case the PE will advertise the B-MAC/I-SID route.
* ACが動作することは、対応するI-SIDをアクティブにしない限り、B-MAC/I-SIDアップデートを生成してはなりません。この場合、PEはB-MAC/I-SIDルートを宣伝します。
* An AC receiving a G.8032 flush notification or a flush message in any other protocol from the access network MAY propagate it to the remote PEs by generating a B-MAC/I-SID route update with a higher Sequence Number.
* アクセスネットワークから他のプロトコルにG.8032フラッシュ通知またはフラッシュメッセージを受信するACは、より高いシーケンス番号でB-MAC/I-SIDルートアップデートを生成することにより、リモートPEに伝播する場合があります。
A PE receiving a C-MAC flush notification will follow these procedures:
C-MACフラッシュ通知を受け取るPEは、次の手順に従います。
* A received B-MAC/I-SID route (with a non-zero I-SID) MUST NOT add/ remove any B-MAC to/from the MAC-VRF.
* 受信したB-MAC/I-SIDルート（ゼロ以外のI-SIDを使用）は、MAC-VRFにb-macを追加/削除してはなりません。
* An update of a previously received B-MAC/I-SID route with an increment Sequence Number MUST flush all the C-MACs associated with that I-SID and B-MAC. C-MACs associated with the same I-SID but different B-MAC MUST NOT be flushed.
* 以前に受け取ったB-MAC/I-SIDルートの更新は、インクリメントシーケンス番号を使用して、そのI-SIDおよびB-MACに関連付けられたすべてのC-MACをフラッシュする必要があります。同じI-SIDに関連付けられているが、異なるB-MACに関連付けられたC-MACSをフラッシュしてはなりません。
* A received B-MAC/I-SID withdraw (with a non-zero I-SID) MUST flush all the C-MACs associated with that B-MAC and I-SID.
* 受信したB-MAC/I-SID撤退（非ゼロI-SIDを使用）は、そのB-MACおよびI-SIDに関連付けられたすべてのC-MACをフラッシュする必要があります。
Note that the C-MAC flush procedures described in [RFC7623] for B-MAC/0 routes are still valid and a PE receiving [RFC7623] C-MAC flush notification messages MUST observe the behavior specified in [RFC7623].
B-MAC/0ルートの[RFC7623]で説明されているC-MACフラッシュ手順はまだ有効であり、[RFC7623] C-MACフラッシュ通知メッセージを受信するPEは[RFC7623]で指定された動作を観察する必要があることに注意してください。
The I-SID-based C-MAC flush solution described in this document has the following benefits:
このドキュメントで説明されているI-SIDベースのC-MACフラッシュソリューションには、次の利点があります。
a. The solution solves packet-loss scenarios in case of failures on null ES ACs, since the C-MAC flush procedures are independent of the ES definition.
a. C-Macフラッシュ手順はESの定義とは無関係であるため、このソリューションは、null es ACSの障害が発生した場合にパケット損失シナリオを解決します。
b. This extension can also be used with Single-Active non-null ESs and virtual ESs, irrespective of the PE B-MAC address assignment (dedicated per-ES B-MAC or shared B-MAC).
b. この拡張機能は、PE B-MACアドレスの割り当て（専用のPER-ES B-MACまたは共有B-MAC）に関係なく、単一活性の非ヌルESSおよび仮想ESSで使用することもできます。
c. It provides a C-MAC flush notification at B-MAC and I-SID granularity level, therefore flushing a minimum number of C-MACs and reducing the amount of unknown unicast flooding in the network.
c. B-MACおよびI-SID粒度レベルでC-MACフラッシュ通知を提供するため、最小数のC-MACSを洗い流し、ネットワーク内の不明なユニキャスト洪水の量を減らします。
d. It provides a reliable C-MAC flush notification in PBB-EVPN networks that use RRs. RRs will propagate the C-MAC flush notifications for all the affected I-SIDs, irrespective of the order in which the notifications make it to the RR.
d. RRSを使用するPBB-EVPNネットワークで信頼できるC-MACフラッシュ通知を提供します。RRSは、通知がRRに到達する順序に関係なく、影響を受けるすべてのI-SIDのC-MACフラッシュ通知を伝播します。
e. The solution can coexist in a network with systems supporting or not supporting this specification. Non-supporting systems ignore the B-MAC/I-SID routes; however, they still follow the C-MAC flush procedures in [RFC7623].
e. ソリューションは、この仕様をサポートまたはサポートしていないシステムとのネットワークに共存できます。非サポートシステムは、B-MAC/I-SIDルートを無視します。ただし、[RFC7623]のC-MACフラッシュ手順にまだ従います。
Security considerations described in [RFC7623] apply to this document.
[RFC7623]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。
In addition, this document suggests additional procedures that can be activated on a per I-SID basis and generate additional EVPN MAC/IP Advertisement routes in the network. The format of these additional EVPN MAC/IP Advertisement routes is backwards compatible with the procedures in [RFC7623] and should not create any issues for receiving PEs that do not follow this specification. However, the additional routes may consume extra memory and processing resources on the receiving PEs. Because of that, it is RECOMMENDED to activate this feature only when necessary (when multihomed networks or devices are attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN PE.
さらに、このドキュメントでは、I-SIDごとにアクティブ化できる追加の手順を提案し、ネットワーク内の追加のEVPN MAC/IP広告ルートを生成します。これらの追加のEVPN MAC/IP広告ルートの形式は、[RFC7623]の手順と後方互換性があり、この仕様に従わないPEを受信するための問題を作成するべきではありません。ただし、追加のルートでは、受信PEで追加のメモリと処理リソースを消費する場合があります。そのため、必要に応じてこの機能をアクティブにすることをお勧めします（必要な場合にのみ（MultihomedネットワークまたはデバイスがPBB-EVPN PESに接続されている場合）、PBB-EVPN PEではデフォルトではありません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Henderickx, "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[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>.
[EVPN-VIRTUAL-ES]
Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
Rabadan, "EVPN Virtual Ethernet Segment", Work in
Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
eth-segment-15, 28 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-virtual-eth-segment-15>.
[G.8032] ITU-T, "Ethernet ring protection switching", ITU-T
Recommendation G.8032/Y.1344, March 2020,
<https://www.itu.int/rec/T-REC-G.8032-202003-I/en>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi Padakanti, and Ranganathan Boovaraghavan for their review and contributions.
著者は、レビューと貢献について、Vinod Prabhu、Sriram Venkateswaran、Laxmi Padakanti、Ranganathan Boovaraghavanに感謝したいと考えています。
Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
Senthil Sathappan
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: senthil.sathappan@nokia.com
Kiran Nagaraj
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: kiran.nagaraj@nokia.com
M. Miyake
Softbank
Email: masahiro.miyake@g.softbank.co.jp
T. Matsuda
Softbank
Email: taku.matsuda@g.softbank.co.jp