[要約] RFC 7734は、Ethernet VPN（EVPN）上での最短パスブリッジングMACモードのサポートに関する規格です。このRFCの目的は、EVPNを使用して最短パスブリッジングを実現するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Allan, Ed.
Request for Comments: 7734 J. Tantsura
Category: Standards Track Ericsson
ISSN: 2070-1721 D. Fedyk
HPE
A. Sajassi
Cisco
January 2016
Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
イーサネットVPN（EVPN）を介した最短パスブリッジングMACモードのサポート
Abstract
概要
This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.
このドキュメントでは、PBB-EVPNソリューション（RFC 7623）で説明されているように、イーサネット最短パスブリッジングMACモード（SPBM）をイーサネットVPN（EVPN）と組み合わせてプロバイダーバックボーンブリッジングプロバイダーエッジ（PBB PE）と相互運用する方法について説明します。これは、EVPNコアに接続された各イーサネットネットワークの運用上の分離を通じて実現され、イーサネットネットワークのさまざまなバリエーション間の完全なインターワーキングをサポートします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7734.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7734で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Conventions Used in This Document ...............................3
2.1. Terminology ................................................3
3. Solution Overview ...............................................4
4. Elements of Procedure ...........................................5
4.1. PE Configuration ...........................................5
4.2. DF Election ................................................6
4.3. Control-Plane Interworking ISIS-SPB to EVPN ................6
4.4. Control-Plane Interworking EVPN to ISIS-SPB ................7
4.5. Data-Plane Interworking SPBM Island or PBB PE to EVPN ......8
4.6. Data-Plane Interworking EVPN to SPBM Island ................8
4.7. Data-Plane Interworking EVPN to PBB PE .....................8
4.8. Multicast Support ..........................................8
5. Other Aspects ...................................................8
5.1. Transit ....................................................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) [IEEE.802.1Q] along with Provider Backbone Bridging Provider Edges (PBB PEs) and Provider Backbone Bridged Networks (PBBNs) can be supported by Ethernet VPNs (EVPNs) such that each SPBM island is operationally isolated while providing full L2 connectivity between the different types of PBBNs where desired. Each SPBM island uses its own control-plane instance and multipathing design, be it multiple equal-cost tree sets or multiple spanning trees.
このドキュメントでは、プロバイダーバックボーンブリッジングプロバイダーエッジ（PBB PE）およびプロバイダーバックボーンブリッジドネットワーク（PBBN）とともにイーサネット最短パスブリッジングMACモード（SPBM）[IEEE.802.1Q]を、イーサネットVPN（EVPN）でサポートする方法について説明します。 SPBMアイランドは、必要に応じて、異なるタイプのPBBN間で完全なL2接続を提供しながら、運用上分離されています。各SPBMアイランドは、複数の等コストツリーセットまたは複数のスパニングツリーのいずれであっても、独自のコントロールプレーンインスタンスとマルチパス設計を使用します。
The intention is to permit past, current, and emerging future versions of Ethernet to be seamlessly interconnected to permit large-scale, geographically diverse numbers of Ethernet end systems to be fully supported with EVPN as the unifying system.
意図は、イーサネットの過去、現在、および将来のバージョンをシームレスに相互接続して、大規模で地理的に多様な数のイーサネットエンドシステムを統合システムとしてのEVPNで完全にサポートできるようにすることです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Terms used in this document are used as specified in IEEE 802.1Q-2014, which incorporates earlier IEEE 802.1 projects.
このドキュメントで使用されている用語は、以前のIEEE 802.1プロジェクトを組み込んだIEEE 802.1Q-2014で指定されているとおりに使用されています。
BEB: Backbone Edge Bridge BGP: Border Gateway Protocol B-MAC: Backbone MAC B-VID: Backbone VLAN ID CE: Customer Edge DA: Destination Address DF: Designated Forwarder ESI: Ethernet Segment Identifier EVPN: Ethernet VPN IB-BEB: A BEB that has both an I-component (customer-layer VLAN-aware bridge) and a B-component (backbone-layer VLAN-aware bridge) ISIS-SPB: IS-IS as extended for SPB I-SID: Backbone Service Instance Identifier NLRI: Network Layer Reachability Information PBB: Provider Backbone Bridging as in Clauses 25 and 26 of [IEEE.802.1Q] PBBN: Provider Backbone Bridged Network PBB PE: Co-located BEB and EVPN PE PE: Provider Edge SPB: Shortest Path Bridging SPBM: Shortest Path Bridging MAC mode as in Clauses 27 and 28 of [IEEE.802.1Q] SPBM-PE: Co-located SPBM<->EVPN interworking function and EVPN PE
BEB：バックボーンエッジブリッジBGP：ボーダーゲートウェイプロトコルB-MAC：バックボーンMAC B-VID：バックボーンVLAN ID CE：カスタマーエッジDA：宛先アドレスDF：指定フォワーダーESI：イーサネットセグメント識別子EVPN：イーサネットVPN IB-BEB：A BEB Iコンポーネント（顧客層のVLAN対応ブリッジ）とBコンポーネント（バックボーン層のVLAN対応ブリッジ）の両方を持つISIS-SPB：SPB I-SIDの拡張としてのIS-IS：バックボーンサービスインスタンス識別子NLRI ：ネットワーク層到達可能性情報PBB：[IEEE.802.1Q]の25項と26項にあるプロバイダーバックボーンブリッジングPBBN：プロバイダーバックボーンブリッジドネットワークPBB PE：共存BEBとEVPN PE PE：プロバイダーエッジSPB：最短パスブリッジングSPBM： [IEEE.802.1Q] SPBM-PEの条項27および28にあるような最短パスブリッジングMACモード：同じ場所に配置されたSPBM <-> EVPNインターワーキング機能とEVPN PE
The EVPN solution for SPBM, as specified in [IEEE.802.1Q], incorporates control-plane interworking in the PE to map ISIS-SPB [RFC6329] information elements into the EVPN Next Layer Reachability Information (NLRI) and vice versa. This requires each PE to act both as an EVPN BGP speaker and as an ISIS-SPB edge node. Associated with this are procedures for configuring the forwarding operations of the PE such that an arbitrary number of EVPN-attached SPBM islands can be interconnected without any topological or multipathing dependencies. This model also permits PBB PEs as defined in [RFC7623] to seamlessly communicate with the SPBM islands.
[IEEE.802.1Q]で指定されているSPBMのEVPNソリューションは、PEにコントロールプレーンインターワーキングを組み込んで、ISIS-SPB [RFC6329]情報要素をEVPN Next Layer Reachability Information（NLRI）に、またはその逆にマッピングします。これには、各PEがEVPN BGPスピーカーとISIS-SPBエッジノードの両方として機能する必要があります。これに関連して、トポロジやマルチパスに依存せずに、任意の数のEVPN接続SPBMアイランドを相互接続できるように、PEの転送操作を構成する手順があります。このモデルでは、[RFC7623]で定義されているPBB PEがSPBMアイランドとシームレスに通信することもできます。
+--------------+ +----+ +---+
| | |PBB |---|CE2|
| | |PE3 | +---+
+-----+ +----+ | | +----+
| |-----|SPBM| | |
|SPBM | |PE1 | | IP/MPLS |
+---+ |NTWK1| +----+ | Network |
|CE1|-| | | |
+---+ | | +----+ | |
| |-----|SPBM| | | +----+ +-----+
+-----+ |PE2 | | | |SPBM| |SPBM | +---+
+----+ | | |PE5 |---|NTWK2|-|CE3|
+--------------+ +----+ +-----+ +---+
Figure 1: PBB and SPBM EVPN Network
図1：PBBおよびSPBM EVPNネットワーク
Figure 1 illustrates the generalized space addressed by this memo. SPBM networks may be multihomed onto an IP/MPLS network that implements EVPN for the purpose of interconnecting with other SPBM networks and/or PBB PEs. The multipathing configuration of each SPBM network can be unique as the backbone VLAN ID (B-VID) configuration (how multipathing is performed in SPBM) is not propagated across the IP/MPLS network implementing EVPN. As with PBB networking, the B-VID is local to the SPBM network, so in SPBM a B-MAC associated with the B-VID is advertised with the supported I-SIDs at the PBB gateway.
図1は、このメモが扱う一般化された空間を示しています。 SPBMネットワークは、他のSPBMネットワークやPBB PEと相互接続する目的で、EVPNを実装するIP / MPLSネットワークにマルチホーム化できます。バックボーンVLAN ID（B-VID）構成（SPBMでマルチパスがどのように実行されるか）はEVPNを実装するIP / MPLSネットワーク全体に伝達されないため、各SPBMネットワークのマルチパス構成は一意にすることができます。 PBBネットワーキングと同様に、B-VIDはSPBMネットワークに対してローカルであるため、SPBMでは、B-VIDに関連付けられたB-MACが、PBBゲートウェイでサポートされているI-SIDでアドバタイズされます。
Each EVPN is identified by a route target. I-SID-based load-balancing as specified in [RFC7623] allows multiple gateways per B-VID (each with different I-SIDs) across the EVPN; it is supported by the interworking between PBBNs and SPBM networks. However, SPBM only allows a single active designated forwarder (DF) per B-VID as described below. The route target identifies the set of SPBM islands and PBB PEs that are allowed to communicate. Each SPBM island is administered to have an Ethernet Segment ID (ESI) Label extended community associated with it.
各EVPNはルートターゲットによって識別されます。 [RFC7623]で指定されているI-SIDベースのロードバランシングでは、EVPN全体でB-VIDごとに（それぞれ異なるI-SIDを持つ）複数のゲートウェイを使用できます。 PBBNとSPBMネットワーク間のインターワーキングによってサポートされています。ただし、SPBMでは、以下に説明するように、B-VIDごとに1つのアクティブな指定フォワーダー（DF）のみが許可されます。ルートターゲットは、通信が許可されているSPBMアイランドとPBB PEのセットを識別します。各SPBMアイランドは、それに関連付けられたイーサネットセグメントID（ESI）ラベル拡張コミュニティを持つように管理されます。
BGP acts as a common repository of the I-Component Service ID (I-SID) attachment points for the set of attached PEs / SPBM islands. This is in the form of {B-MAC address, I-SID, Tx-Rx-attribute} tuples. BGP distributes I-SID information into each SPBM island on the basis of locally registered interest. If an SPBM island has no Backbone Edge Bridges (BEBs) registering interest in a particular I-SID, information about that I-SID from other SPBM islands, PBB PEs, or PBBNs MUST NOT be leaked into the local ISIS-SPB routing system. For each B-VID in an SPBM island, a single SPBM-PE MUST be elected the DF for the B-VID. An SPBM-PE can be a DF for more than one B-VID. This is described further in Section 4.2. The SPBM-PE originates IS-IS advertisements as if it were an IB-BEB that proxies for the other SPBM islands and PBB PEs in the EVPN defined by the route target, but the PE typically will not actually host any I-components.
BGPは、接続されたPE / SPBMアイランドのセットのIコンポーネントサービスID（I-SID）接続ポイントの共通リポジトリとして機能します。これは、{B-MACアドレス、I-SID、Tx-Rx-attribute}タプルの形式です。 BGPは、ローカルに登録された関心に基づいて、I-SID情報を各SPBMアイランドに配布します。 SPBMアイランドに特定のI-SIDに関心を登録するバックボーンエッジブリッジ（BEB）がない場合、他のSPBMアイランド、PBB PE、またはPBBNからのそのI-SIDに関する情報をローカルISIS-SPBルーティングシステムに漏出してはなりません。 SPBMアイランド内のB-VIDごとに、単一のSPBM-PEがB-VIDのDFとして選出される必要があります。 SPBM-PEは、複数のB-VIDのDFにすることができます。これについては、セクション4.2で詳しく説明します。 SPBM-PEは、ルートターゲットによって定義されたEVPN内の他のSPBMアイランドおよびPBB PEをプロキシするIB-BEBであるかのようにIS-ISアドバタイズを発信しますが、PEは通常、実際にはIコンポーネントをホストしません。
An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag information from frames relayed towards the EVPN. The DF MUST also insert the appropriate B-VID tag information into frames relayed towards the SPBM island on the basis of the local I-SID/B-VID bindings advertised in ISIS-SPB.
B-VIDのDFであるSPBM-PEは、EVPNに向けてリレーされるフレームからB-VIDタグ情報を削除する必要があります。 DFはまた、ISIS-SPBでアドバタイズされたローカルI-SID / B-VIDバインディングに基づいて、SPBMアイランドに向けて中継されるフレームに適切なB-VIDタグ情報を挿入する必要があります。
A PE MUST implement and perform the following procedures.
PEは、次の手順を実装および実行する必要があります。
At SPBM island commissioning a PE is configured with:
SPBMアイランドの試運転では、PEは次のように構成されます。
1) The route target for the service instance. Where a route target is defined as identifying the set of SPBM islands, PBBNs and PBB PEs are to be interconnected by the EVPN.
1）サービスインスタンスのルートターゲット。ルートターゲットがSPBMアイランドのセットを識別するものとして定義されている場合、PBBNとPBB PEはEVPNによって相互接続されます。
2) The unique ESI for the SPBM island. Mechanisms for deriving a unique ESI for the SPBM island are out of scope.
2）SPBMアイランドに固有のESI。 SPBMアイランドの一意のESIを導出するメカニズムは範囲外です。
The following is configured as part of commissioning an ISIS-SPB node:
以下は、ISIS-SPBノードのコミッショニングの一部として構成されています。
1) A Shortest Path Source ID (SPSourceID) used for algorithmic construction of multicast addresses. Note this is required for SPBM BEB operation independent of the EVPN operation.
1）マルチキャストアドレスのアルゴリズム構築に使用される最短パスソースID（SPSourceID）。これは、EVPN操作とは関係なくSPBM BEB操作に必要です。
2) The set of B-VIDs used in the SPBM island and multipathing algorithm IDs to use for each. The set of B-VIDs and multipathing algorithms used can be different in different domains. Therefore, the B-VID is local to an SPBM domain and is removed for frames carried over the IP/MPLS network.
2）SPBMアイランドで使用されるB-VIDのセットと、それぞれに使用するマルチパスアルゴリズムID。使用されるB-VIDのセットとマルチパスアルゴリズムは、ドメインによって異なる場合があります。したがって、B-VIDはSPBMドメインに対してローカルであり、IP / MPLSネットワークを介して伝送されるフレームから削除されます。
A Type 1 Route Distinguisher for the node can be auto-derived. The actual procedure is out of scope for this document.
ノードのタイプ1ルート識別子は、自動派生させることができます。実際の手順は、このドキュメントの範囲外です。
PEs self-appoint themselves for the role of DF for a B-VID for a given SPBM island. The procedure used is as per Section 8.5 (Designated Forwarder Election) of [RFC7432].
PEは、特定のSPBMアイランドのB-VIDのDFの役割を自分で指定します。使用される手順は、[RFC7432]のセクション8.5（Designated Forwarder Election）のとおりです。
A PE that assumes the role of DF for a given B-VID is responsible for originating specific information into BGP from ISIS-SPB and vice versa. A PE that ceases to perform the role of DF for a given B-VID is responsible for withdrawing the associated information from BGP and ISIS-SPB, respectively. The actual information exchanged is outlined in the following sections.
特定のB-VIDのDFの役割を引き受けるPEは、ISIS-SPBからBGPに特定の情報を発信する責任があり、その逆も同様です。特定のB-VIDのDFの役割の実行を停止するPEは、それぞれBGPおよびISIS-SPBから関連情報を撤回する責任があります。交換される実際の情報は、次のセクションで概説されています。
When a PE receives an SPBM service identifier and unicast address sub-TLV as part of an ISIS-SPB MT capability TLV, the PE checks if it is the DF for the B-VID in the sub-TLV.
PEがSPBMサービスIDとユニキャストアドレスサブTLVをISIS-SPB MT機能TLVの一部として受信すると、PEはそれがサブTLVのB-VIDのDFであるかどうかを確認します。
If it is the DF, and there is new or changed information, then a MAC/IP advertisement route NLRI is created for each new I-SID in the sub-TLV. Changed information that results in modification to existing NLRI is processed accordingly. NLRI creation/modification will ensure:
それがDFであり、新しい情報または変更された情報がある場合、MAC / IPアドバタイズメントルートNLRIがサブTLVの新しいI-SIDごとに作成されます。既存のNLRIを変更する変更情報は、それに応じて処理されます。 NLRIの作成/変更により、以下が保証されます。
- the Route Distinguisher is set to that of the PE.
- ルート識別子はPEのルート識別子に設定されます。
- the ESI is that of the SPBM island.
- ESIはSPBMアイランドのESIです。
- the Ethernet Tag ID contains the I-SID (including the Tx/Rx attributes) copied from the SPBM service identifier and unicast address sub-TLV. The encoding of I-SID information is as per Figure 2. (See [RFC6329] for details on the T bit and R bit.)
- イーサネットタグIDには、SPBMサービス識別子からコピーされたI-SID（Tx / Rx属性を含む）とユニキャストアドレスサブTLVが含まれます。 I-SID情報のエンコーディングは、図2のとおりです（TビットとRビットの詳細については、[RFC6329]を参照してください）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: I-SID Encoding in the Ethernet Tag ID Field
図2：イーサネットタグIDフィールドのI-SIDエンコーディング
- the MAC address is copied from the SPBM service identifier and unicast address sub-TLV
- MACアドレスはSPBMサービス識別子とユニキャストアドレスサブTLVからコピーされます
- a locally assigned MPLS label (which may be common with other NLRI originated by the PE and is used to map EVPN traffic to the SPBM network)
- ローカルに割り当てられたMPLSラベル（PEによって発信された他のNLRIと共通である可能性があり、EVPNトラフィックをSPBMネットワークにマップするために使用されます）
Similarly, in the scenario where a PE became elected DF for a B-VID in an operating network, the IS-IS database would be processed in order to construct the NLRI associated with the new role of the PE.
同様に、PEがオペレーティングネットワークでB-VIDのDFに選出されたシナリオでは、PEの新しい役割に関連付けられたNLRIを構築するために、IS-ISデータベースが処理されます。
If the BGP database has NLRI for the I-SID, and this is the first instance of registration of interest in the I-SID from the SPBM island, the NLRI for the I-SID is processed to construct an updated set of SPBM service identifier and unicast address sub-TLVs to be advertised by the PE.
BGPデータベースにI-SIDのNLRIがあり、これがSPBMアイランドからのI-SIDへの関心のある登録の最初のインスタンスである場合、I-SIDのNLRIが処理され、SPBMサービス識別子の更新されたセットが構築されます。 PEによってアドバタイズされるユニキャストアドレスサブTLV。
The ISIS-SPB information is also used to keep current a local table indexed by I-SID to indicate the associated B-VID for processing of frames received from the EVPN. When an I-SID is associated with more than one B-VID, only one entry is allowed in the table. Rules for preventing this are out of scope for this memo.
ISIS-SPB情報は、EVPNから受信したフレームの処理に関連するB-VIDを示すために、I-SIDによってインデックスが付けられたローカルテーブルを最新に保つためにも使用されます。 I-SIDが複数のB-VIDに関連付けられている場合、テーブルで許可されるエントリは1つだけです。これを防ぐためのルールは、このメモの範囲外です。
When a PE receives a BGP NLRI that has new information, the PE checks if it is the elected DF to communicate this information into ISIS-SPB by checking if the I-SID in the Ethernet Tag ID locally maps to the B-VID for which it is an elected DF. Note that if no BEBs in the SPB island have advertised any interest in the I-SID, it will not be associated with any B-VID locally, and therefore will not be of interest. If the I-SID is of local interest to the SPBM island and the PE is the DF for the B-VID to which the I-SID is locally mapped, a SPBM service identifier and unicast address sub-TLV are constructed/updated for advertisement into ISIS-SPB.
PEは、新しい情報を持つBGP NLRIを受信すると、イーサネットタグIDのI-SIDがローカルにB-VIDにマップされているかどうかをチェックすることにより、この情報がISIS-SPBに通信するために選ばれたDFかどうかをチェックします選出されたDFです。 SPBアイランドのBEBがI-SIDに関心をアドバタイズしていない場合、ローカルでB-VIDに関連付けられていないため、関心がないことに注意してください。 I-SIDがローカルでSPBMアイランドに関係し、PEがI-SIDがローカルにマッピングされているB-VIDのDFである場合、アドバタイズ用にSPBMサービス識別子とユニキャストアドレスサブTLVが構築/更新されます。 ISIS-SPBに。
The NLRI advertised into ISIS-SPB is also used to locally populate a forwarding table indexed by B-MAC + I-SID that points to the label stack to impose on the SPBM frame. The bottom label in the stack is that obtained from the NLRI.
ISIS-SPBにアドバタイズされたNLRIは、B-MAC + I-SIDによってインデックスが付けられた転送テーブルにローカルに入力され、SPBMフレームに課すラベルスタックをポイントします。スタックの一番下のラベルは、NLRIから取得したものです。
When a PE receives a frame from the SPBM island in a B-VID for which it is a DF, it looks up the B-MAC/I-SID information to determine the label stack to be added to the frame for forwarding in the EVPN. The PE strips the B-VID information from the frame, adds the label information to the frame, and forwards the resulting MPLS packet.
PEは、DFであるB-VIDのSPBMアイランドからフレームを受信すると、B-MAC / I-SID情報を検索して、EVPNで転送するためにフレームに追加するラベルスタックを決定します。 PEはフレームからB-VID情報を取り除き、ラベル情報をフレームに追加して、結果のMPLSパケットを転送します。
When a PE receives a packet from the EVPN, it can infer the B-VID to overwrite in the SPBM frame from the I-SID or by other means (such as via the bottom label in the MPLS stack).
PEはEVPNからパケットを受信すると、B-VIDを推測して、SPBMフレームでI-SIDから、または他の手段（MPLSスタックの下部ラベルなど）で上書きすることができます。
If the frame has a local multicast destination address (DA), it overwrites the SPSourceID in the frame with the local SPSourceID.
フレームにローカルマルチキャスト宛先アドレス（DA）がある場合、フレーム内のSPSourceIDがローカルSPSourceIDで上書きされます。
A PBB PE actually has no attached PBBN nor concept of B-VID, so no frame processing is required.
PBB PEには実際にはPBBNもB-VIDの概念もないため、フレーム処理は必要ありません。
A PBB PE is required to accept SPBM-encoded multicast DAs as if they were PBB-encoded (i.e., using the Backbone Service Instance Group address) for multicast DAs. The only information of interest is that it is a multicast frame and the I-SID encoded in the lower 24 bits.
PBB PEは、SPBMエンコードされたマルチキャストDAを、それらがマルチキャストDAに対してPBBエンコードされた（つまり、バックボーンサービスインスタンスグループアドレスを使用した）かのように受け入れるために必要です。関心のある唯一の情報は、それがマルチキャストフレームであり、I-SIDが下位24ビットでエンコードされていることです。
Within a PBBN domain, Ethernet unicast and multicast end services are supported. PBB can tunnel multicast traffic in unicast PBB frames when using head-end replication. This is the only form of multicast traffic interworking supported by this document. Native PBB multicast forwarding over EVPN, PE replication, or optimizing PBB multicast across the EVPN is not addressed by this memo.
PBBNドメイン内では、イーサネットユニキャストおよびマルチキャストエンドサービスがサポートされています。 PBBは、ヘッドエンドレプリケーションを使用する場合、ユニキャストPBBフレームでマルチキャストトラフィックをトンネリングできます。これは、このドキュメントでサポートされている唯一のマルチキャストトラフィックインターワーキングの形式です。 EVPNを介したネイティブPBBマルチキャスト転送、PEレプリケーション、またはEVPN全体でのPBBマルチキャストの最適化については、このメモでは扱いません。
Any PE that does not need to participate in the tandem calculations at the B-MAC layer can use the IS-IS overload bit to exclude SPBM tandem paths and behave as a pure interworking platform.
B-MAC層でのタンデム計算に参加する必要のないPEは、IS-IS過負荷ビットを使用してSPBMタンデムパスを除外し、純粋なインターワーキングプラットフォームとして動作できます。
Security issues associated with incorrect interconnection of customer LANs cannot be directly addressed by implementations of this document, as it requires misconfiguration in the Shortest Path Bridging domains. The identifiers so administered have global significance to the larger system. They are relayed transparently by EVPN and only policed in the SPBM domains. Therefore, care is required in synchronization of identifiers that need to be common for inter-domain operation.
顧客のLANの誤った相互接続に関連するセキュリティの問題は、Shortest Path Bridgingドメインでの設定ミスを必要とするため、このドキュメントの実装では直接対処できません。このように管理された識別子は、より大きなシステムにとってグローバルな意味を持ちます。これらはEVPNによって透過的にリレーされ、SPBMドメインでのみポリシングされます。したがって、ドメイン間の操作に共通である必要がある識別子の同期には注意が必要です。
There are only two identifiers unique to this solution provisioned at an SPBM-PE at service turn-up: the route target and the ESI. The ESI needs to be unique and common to all SPBM-PEs connected to a common SPBM network or PBBN, else portions of the overall network will not share reachability. (The EVPN will assume that separate networks are interconnected by SPBM.) Security issues exist when SPBM domains are incorrectly cross-connected together via EVPN; this will result in black-holing or incorrect delivery of data with associated privacy issues. This error may occur by provisioning the incorrect RT value at an SPBM-PE or associating the RT with the wrong interface. This error can be avoided by consistency-checking the route target provisioning at SPBM-PEs when performing service additions and/or changes.
サービスターンアップ時にSPBM-PEでプロビジョニングされるこのソリューションに固有の識別子は、ルートターゲットとESIの2つだけです。 ESIは一意であり、共通のSPBMネットワークまたはPBBNに接続されているすべてのSPBM-PEに共通である必要があります。そうしないと、ネットワーク全体の一部が到達可能性を共有しません。 （EVPNは、個別のネットワークがSPBMによって相互接続されていると想定します。）SPBMドメインがEVPNを介して誤って相互接続されている場合、セキュリティの問題が存在します。これにより、関連するプライバシーの問題を伴うデータのブラックホール化または誤った配信が発生します。このエラーは、SPBM-PEで誤ったRT値をプロビジョニングするか、RTを誤ったインターフェイスに関連付けることによって発生する可能性があります。このエラーは、サービスの追加や変更を実行するときにSPBM-PEでルートターゲットのプロビジョニングを整合性チェックすることで回避できます。
The behavior that is potentially most destructive to the overall system is frequent changes to the DF elections for a given ESI. This would occur if the SPBM-PEs continuously had their links go up and down in a such a way that the SPBM-PE was being severed from and reconnected to either the IP/MPLS network or the attached SPBM network. Either of these scenarios would result in significant control-plane traffic as DF associated information was advertised and withdrawn from both the SPBM and BGP control planes. Dual-homing of SPBM-PEs on both networks would minimize the likelihood of this scenario occurring.
システム全体を破壊する可能性のある動作は、特定のESIのDF選挙に対する頻繁な変更です。これは、SPBM-PEが切断され、IP / MPLSネットワークまたは接続されたSPBMネットワークのいずれかに再接続されるような方法で、SPBM-PEのリンクが継続的に上下する場合に発生します。これらのシナリオのいずれでも、DF関連情報がアドバタイズされ、SPBMとBGPの両方のコントロールプレーンから取り消されるため、かなりのコントロールプレーントラフィックが発生します。両方のネットワークでSPBM-PEをデュアルホーミングすると、このシナリオが発生する可能性が最小限になります。
The issues associated with securing the BGP control plane (independent of this particular memo) are reflected in the Security Considerations section of [RFC4761].
BGPコントロールプレーンの保護に関連する問題（この特定のメモとは無関係）は、[RFC4761]のセキュリティに関する考慮事項のセクションに反映されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "Virtual Private LAN Service（VPLS）Using BGP for Auto-Discovery and Signaling"、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<http ：//www.rfc-editor.org/info/rfc4761>。
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.
[RFC6329] Fedyk、D.、Ed。、Ashwood-Smith、P.、Ed。、Allan、D.、Bragg、A.、and P. Unbehagen、 "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging"、 RFC 6329、DOI 10.17487 / RFC6329、2012年4月、<http://www.rfc-editor.org/info/rfc6329>。
[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, <http://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A。、編、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J。、およびW. Henderickx、「BGP MPLSベースのイーサネットVPN」、 RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<http://www.rfc-editor.org/info/rfc7432>。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, December 2014.
[IEEE.802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、IEEE 802.1Q-2014、DOI 10.1109 / ieeestd.2014.6991462、2014年12月。
[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, <http://www.rfc-editor.org/info/rfc7623>.
[RFC7623] Sajassi、A。、編、Salam、S.、Bitar、N.、Isaac、A。、およびW. Henderickx、「Provider Backbone Bridging Combined with Ethernet VPN（PBB-EVPN）」、RFC 7623、DOI 10.17487 / RFC7623、2015年9月、<http://www.rfc-editor.org/info/rfc7623>。
Acknowledgments
謝辞
The authors would like to thank Peter Ashwood-Smith, Martin Julien, and Janos Farkas for their detailed reviews of this document.
このドキュメントの詳細なレビューを提供してくれたPeter Ashwood-Smith、Martin Julien、Janos Farkasに感謝します。
Authors' Addresses
著者のアドレス
Dave Allan (editor) Ericsson 300 Holger Way San Jose, CA 95134 United States
Dave Allan（editor）Ericsson 300 Holger Way San Jose、CA 95134アメリカ合衆国
Email: david.i.allan@ericsson.com
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States
Jeff Tantsura Ericsson 300 Holger Way San Jose、CA 95134アメリカ合衆国
Email: jeff.tantsura@ericsson.com
Don Fedyk Hewlett-Packard Enterprise 153 Taylor Street Littleton, MA 01460 United States
Don Fedyk Hewlett-Packard Enterprise 153 Taylor Streetリトルトン、MA 01460アメリカ合衆国
Email: don.fedyk@hpe.com
Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Ali Sajassi Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: sajassi@cisco.com