はじめに

この文書は RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスが欠けた文章になっている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

はじめに
- 免責
目次
Abstract
1. はじめに
2. Requirements Notation and Conventions
3. 用語
4. EVPNの特徴
5. EVPNオーバーレイのためのカプセル化方式
- 5.1. VXLAN/NVGREカプセル化
- 5.2. MPLS over GRE
6. 複数のデータプレーンカプセル化のEVPN
7. シングルホームNVE - ハイパーバイザに存在するNVE
- 7.1. VXLAN/NVGREカプセル化のEVPN BGP経路と属性への影響
- 7.2. VXLAN/NVGREカプセル化のEVPN手順への影響
8. マルチホームNVE - ToRスイッチに存在するNVE
9. マルチキャストのサポート
10. データセンター相互接続(DCI)
- 10.1. GWを使用したDCI
- 10.2. ASBRを使用したDCI
  - 10.2.1. シングルホームNVEとASBR機能
  - 10.2.2. マルチホームNVEとASBR機能
11. セキュリティについての考察
12. IANAについての考察
13. 参考文献

Abstract

この文書はEthernet VPN (EVPN)がNetwork Virtualization Overlay (NVO)ソリューションとして使用できることを明示し、IP越しのさまざまなトンネルのカプセル化方式とそれらがEVPNのコントロールプレーンと手順に及ぼす影響について探究します。特に次のカプセル化方式について分析します: Virtual Extensible LAN (VXLAN)、Network Virtualization using Generic Routing Encapsulation (NVGRE)、MPLS over GRE。この仕様はGeneric Network Virtualization Encapsulation (GENEVE)にも適用することができますが、もうひと仕事必要ですので別の文書で補足します。この文書はスプリットホライズン・フィルタリングとMass Withdrawalのための新しいマルチホームの手順を仕様化します。また、VXLAN/NVGREでのカプセル化のためのEVPN経路の構築方法や、Network Virtualization Edge (NVE)機器のマルチホーミングのためのAutonomous System Border Router (ASBR)の手順についても仕様化します。

1. はじめに

この文書はEthernet VPN (EVPN)がNetwork Virtualization Overlay (NVO)ソリューションとして使用できることを明示し、IP越しのさまざまなトンネルのカプセル化方式とそれらがEVPNのコントロールプレーンと手順に及ぼす影響について探究します。特に次のカプセル化の選択肢について分析します: Virtual Extensible LAN (VXLAN, RFC7348)、Network Virtualization using Generic Routing Encapsulation (NVGRE, RFC7637)、MPLS over Generic Routing Encapsulation (GRE, RFC4023)。この仕様はGeneric Network Virtualization Encapsulation (GENEVE)にも適用することができますが、もうひと仕事必要ですので別の文書で補足します。この文書はスプリットホライズン・フィルタリングとmass withdrawalのための新しいマルチホームの手順を仕様化します。また、VXLAN/NVGREでのカプセル化のためのEVPN経路の構築方法や、Network Virtualization Edge (NVE)機器のマルチホーミングのためのAutonomous System Border Router (ASBR)の手順についても仕様化します。

この文書の文脈においてNVOとは、特に仮想マシン(VM)や仮想ワークロードなどの仮想化されたホストのためのマルチテナントデータセンタの要件を満たすための解決策のことです。このような解決策の主要な要件はRFC7364に記載されているように次のとおりです:

テナントごとのネットワークトラフィックの隔離
大量のテナントのサポート(1万から10万規模)
与えられたテナントセグメント(サブネット)に属する異なるVM間について、データセンター内や異なるデータセンター間にある異なるPoints of Delivery (PoDs)にまたがるレイヤー2(L2)接続性の延伸
与えられたVMについて、与えられたL2セグメント内の異なる物理接続点の間で移動できること

NVOソリューションのためのアンダーレイネットワークはNVOのエンドポイント間でIP接続性を提供しているものと仮定します。

この文書ではEVPNがNVOソリューションとして使用できることを記述し、EVPNの機能と手順の適用性を探究します。特にこのIP越しのEVPNのための様々なトンネルのカプセル化方式とそれらがEVPNのコントロールプレーンと主に2つのシナリオの手順に与える影響について記述します。

(a) シングルホームNVE - NVEがハイパーバイザに収容されているとき

(b) マルチホームNVE - NVEがTop-of-Rack (ToR)機器に収容されているとき

EVPNオーバーレイとしてこの文書で分析する可能なカプセル化方式は次のとおりです:

VXLANとNVGRE
MPLS over GRE

IP越しのEVPNのための異なるカプセル化方式について述べる前に、EVPNソリューションの主要な特徴、それらの特徴が現在どのようにサポートされているか、カプセル化がそれらの機能に与える影響に注目することが重要です。

2. Requirements Notation and Conventions

いつもの

3. 用語

この文書で使用されるほとんどの用語はRFC7432とRFC7365からきています。

VXLAN: Virtual Extensible LAN

GRE: Generic Routing Encapsulation

NVGRE: Network Virtualization using Generic Routing Encapsulation

GENEVE: Generic Network Virtualization Encapsulation

PoD: Point of Delivery

NV: Network Virtualization

NVO: Network Virtualization Overlay

NVE: Network Virtualization Edge

VNI: VXLAN Network Identifier

VSID: (NVGREのための)Virtual Subnet Identifier

I-SID: Service Instance Identifier

EVPN: Ethernet VPN

EVI: EVPNインスタンス(EVPN Instance)。EVPNに参加しているProvidor Edge(PE)機器にまたがるEVPNインスタンス。

MAC-VRF: PEにおけるMedia Access Control (MAC)アドレスのためのVirtual Routing and Forwardingテーブル。

IP-VRF: PEにおけるInternet Protocol (IP)アドレスのためのVirtual Routing and Forwardingテーブル。

ES: イーサネットセグメント(Ethernet Segment)。カスタマーサイト(機器またはネットワーク)が1つ以上のPEにイーサネットのリンクで接続しているとき、この一連のリンクを「イーサネットセグメント」と呼びます。

Ethernet Segment Identifier (ESI): イーサネットセグメントを識別するためのゼロでない一意の識別子をEthernet Segment Identifierと呼びます。

Ethernet Tag: イーサネットタグはVLANなどの特定のブロードキャストドメインを識別するものです。EVPNインスタンスは1つ以上のブロードキャストドメインで構成されます。

PE: Provider Edge

Single-Active冗長モード(Single-Active Redundancy Mode): ESに接続された複数のPEのうち単一のPEだけが、ある与えられたVLANについてトラフィックをESと交換できるとき、このイーサネットセグメントはSingle-Active冗長モードで動作していると定義されます。

All-Active冗長モード(All-Active Redundancy Mode): イーサネットセグメントに接続されたすべてのPEが、ある与えられたVLANについてESとknownユニキャストのトラフィックを交換できるとき、このイーサネットセグメントはAll-Active冗長モードで動作している定義されます。

PIM-SM: Protocol Independent Multicast - Sparse-Mode

PIM-SSM: Protocol Independent Multicast - Source-Specific Multicast

BIDIR-PIM: Bidirectional PIM

4. EVPNの特徴

RFC7432のEVPNは元々はRFC7209に述べられた要件を満たすために設計されたもので、それゆえコントロールプレーンのスケールとデプロイの簡単さの問題を直接的に解決するように次のような特徴を備えています。

コントロールプレーンの情報はBGPで配布され、ブロードキャストとマルチキャストのトラフィックは共有マルチキャストツリーもしくはIngress Replicationを使用して送信されます。
MAC(IP)アドレスのためにデータプレーン学習の代わりにコントロールプレーン学習が使用されます。前者はUnknownユニキャストやAddress Resolution Protocol(ARP)フレームのフラッディングを必要としますが、後者はいかなるフラッディングも必要としません。
ルートリフレクタ(RR)を使用することでPE機器間のフルメッシュのBGPセッションをPEとルートリフレクタの間の単一のBGPセッションに減らします。さらにRR階層化によりRRのBGP経路数をスケールすることができます。
与えられたVPNに参加しているPE機器や与えられた冗長グループに参加しているPE機器、トンネルカプセル化方式、マルチキャストトンネル方式、マルチキャストメンバーなどを発見するためにBGPによる自動発見が使用されます。
All-Activeマルチホーミングが使用されます。与えられたCustomer Edge (CE)機器が複数のPEに対して複数のリンクを持ち、CEから/CEへのトラフィックはこれらのすべてのリンクを完全に有効活用することが可能になります。
CEとPEの間のリンクに障害が発生したときは、そのEVIのPEに対して単一のEVPN経路のwithdrawによって障害が通知されます。これによりこれらのPEは、障害が起きたリンクに関連するそれぞれのMACアドレスについて、withdrawしているPEをネクストホップから削除することができます。これを「Mass Withdrawal」と呼びます。
BGP経路フィルタと制約付き経路配布が、与えられたEVIコントロールプレーントラフィックをそのEVIに属するPEだけに配布することを確実にします。
IEEE 802.1QインターフェイスがCEとPEの間で使われているとき、そのインターフェイスのそれぞれのVLAN ID(VID)をブリッジテーブルに(最大4094個のブリッジテーブル)にマップすることができます。これらのブリッジテーブルはすべて単一のMAC-VRFにマップすることができます(VLAN-aware Bundleサービスの場合)
VMモビリティの仕組みによって、与えられたEVIに属するすべてのPEは、MACアドレスとIPアドレスで識別されれる与えられたVMが現在関連付けられているESを知ることができます。
RTによって運用者(または顧客)がメッシュやハブアンドスポークを含む論理ネットワークトポロジーと外部ネットワーク(異なるエンタープライズにサイトが所有されているVPN)の範囲を、プロプライエタリなソフトウェアや仮想または物理デバイスの助けを必要とせずに、決定することができます。

共通のインフラごとに数百万のインスタンスをNVOのための設計の目標としているため、NVOのコントロールプレーンのスケールの特性は極めて重要です。ここで記述するEVPNとその拡張はこの水準でのスケーラビリティで設計するよう心がけています。

5. EVPNオーバーレイのためのカプセル化方式

5.1. VXLAN/NVGREカプセル化

VXLANもNVGREも、例えばVXLANネットワークにおけるVXLAN Tunnel End Points (VTEP)などのNetwork Virtualization Edges (NVE)の間の共通の物理IPインフラ越しにパケットを運ぶために使われるデータプレーンのカプセル化を提供する技術の例です。どちらの技術もNVOインスタンスに固有の識別子をパケットに含んでいます。VXLANではVNI、NVGREではVSIDです。カプセル化がNVGREでもVSIDはVNIと同様に使用することができるため、この文書の以降の部分では、特に断りがなければNVOインスタンスを表現するためにVNIを使用します。

PEはNVE/VTEPと等価であることに留意してください。

VXLANのカプセル化はUDPに基づいており、UDPヘッダに続いて8バイトのヘッダがあります。VXLANは24ビットのVNIを提供し、RFC7348に記述されるように典型的にはテナントのVIDと一対一のマッピングが行われます。このシナリオにおいて、ingress VTEPはカプセル化されたフレームにinner VLANタグを含まず、egress VTEPはinner VLANタグが含まれたフレームを破棄します。RFC7348におけるこの動作モードはRFC7432のVLAN-Basedサービスにマップされ、テナントVIDがEVIにマップされます。

VXLANではVTEPで明示的に設定を行えばカプセル化されたフレームにinner VLANタグを含むオプションも提供しています。この運用モードはRFC7432のVLAN Bundleサービスにマップすることができます。なぜならすべてのテナントのtaggedのフレームが単一のブリッジテーブル、MAC-VRFにマップすることができ、RFC7348の6節に記載されているようにdisposition PEがVXLANのカプセル化解除を行うときには、inner VLANタグをルックアップのために使用しないからです。

RFC7637のカプセル化はGREによるカプセル化に基づいています。そしてこれはVSIDを運ぶために、任意であるGRE Keyフィールドを含むことを義務化しています。RFC7637に記載されているようにVSIDとテナントVIDの間には一対一マッピングの関係があります。inner VLANタグを含めることは禁止されています。RFC7637の動作モードはRFC7432のVLAN Basedサービスにマップされます。

次節で記述する通り、VXLANまたはNVGREカプセル化をサポートするために、カプセル化方式(VXLANまたはNVGRE)を指定するBGP Encapsulation拡張コミュニティの使用方法以外にはEVPN経路のエンコーディングを変更する必要はありません。しかしNVEが位置する場所(ハイパーバイザまたはToR)やマルチホーミングの能力の必要性に依存する潜在的な影響がEVPNの手順に発生します。

5.1.1. 仮想識別子のスコープ

VNIは24ビットのグローバルで一意な値だと定義されていますが、データセンター相互接続の文脈においては、VNIをローカルで意味を持つ値とすることが望ましいようなシナリオが存在します。

5.1.1.1. ゲートウェイを使ったデータセンター相互接続

異なるデータセンターにあるNVEが相互接続し、NVEがVNIをデータセンター内でグローバルで一意な識別子として使う必要があるケースでは、データセンターネットワーク(DCN)のエッジにおいてゲートウェイ(GW)を導入する必要があります。これはなぜかというと、ゲートウェイは事業者の管理限界の境界に沿うようなネットワーク境界をまたがる際にVNIを変換する機能を提供するからです。例として図1のネットワークを考えてください。ここに3つのネットワーク事業者があります。それぞれDC1, DC2, WANです。ゲートウェイはデータセンターのエッジに位置し、それぞれのDCNとWANで使われる値の間でVNIを変換することに責任を持ちます。

                             +--------------+
                             |              |
           +---------+       |     WAN      |       +---------+
   +----+  |        +---+  +----+        +----+  +---+        |  +----+
   |NVE1|--|        |   |  |WAN |        |WAN |  |   |        |--|NVE3|
   +----+  |IP      |GW |--|Edge|        |Edge|--|GW | IP     |  +----+
   +----+  |Fabric  +---+  +----+        +----+  +---+ Fabric |  +----+
   |NVE2|--|         |       |              |       |         |--|NVE4|
   +----+  +---------+       +--------------+       +---------+  +----+

   |<------ DC 1 ------>                          <------ DC2  ------>|

          図1: ゲートウェイを使ったデータセンター相互接続

5.1.1.2. ゲートウェイを使わないデータセンター相互接続

異なるデータセンターにあるNVEが相互接続し、NVEが(MPLSラベルのように)ローカルで割り当てられたVNIを使用する必要があるケースでは、DCNのエッジにゲートウェイを導入する必要はないでしょう。さらに特にNVEが転送するのに使われるVNIはトラフィックを受信するNVEによって割り振られるものです(言い換えると「downstreamで割り当てられる」MPLSラベルに似ています)。これによって、データセンターのエッジに置かれた専用のゲートウェイを必要とすることなく、異なるデータセンターの間でVNIの空間を分離することが可能になるということです。この話題は10.2節でも扱います。

                             +--------------+
                              |              |
              +---------+     |     WAN      |    +---------+
      +----+  |         |   +----+        +----+  |         |  +----+
      |NVE1|--|         |   |ASBR|        |ASBR|  |         |--|NVE3|
      +----+  |IP Fabric|---|    |        |    |--|IP Fabric|  +----+
      +----+  |         |   +----+        +----+  |         |  +----+
      |NVE2|--|         |     |              |    |         |--|NVE4|
      +----+  +---------+     +--------------+    +---------+  +----+

      |<------ DC 1 ----->                        <---- DC2  ------>|

           図2: ASBRによるデータセンター相互接続

5.1.2. 仮想識別子のEVIへのマッピング

ちょうどRFC7432にあるように、(VLAN IDで表現される)複数のブロードキャストドメインを1つのEVIにマッピングするにあたって2つの選択肢が存在しますが、EVPNコントロールプレーンがVXLAN(またはNVGREカプセル化)と結合されて使用されているときにも、VXLAN VNI(またはNVGRE VSID)で表現される複数のブロードキャストドメインを1つのEVIにマッピングするために2つの選択肢が存在します。

Option 1: EVIごとに単一のブロードキャストドメイン

この選択肢では、VNIで表現される単一のイーサネットブロードキャストドメイン(サブネットなど)は一意のEVIにマップされます。これはRFC7432のVLAN-Basedサービスに対応します。テナント向かいのインターフェイス、(VIDで表現される)論理インターフェイス、物理インターフェイスがEVIにマップされます。そのためBGPのRoute Distinguisher (RD)とRoute Target (RT)はそれぞれのNVEにおいてVNIごとに必要になります。このモデルの利点は、与えられたVNIに関心のあるNVEだけに経路を配布・インポートさせることができるBGPのRT Constraintの仕組みを使うことが可能になるということです。このモデルの欠点はRDとRTがVNIから自動的に計算できない場合のプロビジョニングのオーバーヘッドになるでしょう。

この選択肢では、MAC-VRFテーブルはコントロールプレーンのRTとデータプレーンのVNIによって定義されます。この選択肢では特定のMAC-VRFテーブルは単一のブリッジテーブルに対応します。

Option 2: EVIごとに複数のブロードキャストドメイン

この選択肢では、それぞれが一意のVNIで表現される複数のサブネットが単一のEVIにマップされます。例えば1つのテナントにそれぞれがVNIで表現される複数のセグメント/サブネットがある場合、このテナントのためのすべてのVNIが単一のEVIにマップされます。この場合のEVIはサブネットではなくテナントを表現するものです。これはRFC7432のVLAN-aware Bundleサービスに対応します。このモデルの利点はVNIごとにRD/RTのプロビジョニングを必要としないことです。しかし自動的に計算できるOption 1と比較したときには議論の余地のあるポイントです。このモデルの欠点は与えられたVNIに関心のないNVEでも経路がインポートさてしまうことです。

この選択肢では、MAC-VRFテーブルはコントロールプレーンのRTによって定義されます。つまりこのMAC-VRFの特定のブリッジテーブルはコントロールプレーンの<RT、イーサネットタグID>によって定義されます。この選択肢ではデータプレーンのVNIは特定のブリッジテーブルを識別するために十分なものです。

5.1.2.1. RTの自動計算

設定を簡素化するために、EVIごとに単一のVNIを使用する選択肢では、EVPNに使用するRTを自動計算することができます。RTはRFC7432に記載されているように自動的に生成されます。RTは次に述べるように自動計算できます。

図1に描かれたゲートウェイPEはDCNとWANの両方のBGPセッションに参加しているため、それぞれのネットワークが同一のASで運用されていることを仮定すると、RTの値がVNIから自動計算できて、かつ、DCNとWANの間でRT空間が衝突しないことが重要です。VXLANとNVGREの両方のカプセル化を同一のDCNの中で使用しなければならないようなシナリオも考えられます。これはVNI空間が重複することを意味します。RT空間での衝突を避けるために、2オクテットAS番号を使用するDCNでの6バイトのRT値は次のように自動計算します。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Global Administrator      |    Local Administrator        |
   +-----------------------------------------------+---------------+
   | Local Administrator (Cont.)   |
   +-------------------------------+

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Global Administrator      |A| TYPE| D-ID  | Service ID    |
   +-----------------------------------------------+---------------+
   |       Service ID (Cont.)      |
   +-------------------------------+

6オクテットのRTフィールドは2つのサブフィールドで構成されています。

Global Administratorサブフィールド: 2オクテット。このサブフィールドはIANAによって割り当てられたAS番号を含んでいます。
Local Administratorサブフィールド: 4オクテット。
- A: RTが自動計算されたかどうかを示す単一のビット
  
  0: 自動計算 1: 手動設定
- Type: 残り3バイトが定義されている空間を示すための3ビットのフィールド。以下の空間が定義されています。
  
  0 : VID (802.1Q VLAN ID) 1 : VXLAN 2 : NVGRE 3 : I-SID 4 : EVI 5 : dual-VID (QinQ VLAN ID)
- D-ID: ドメインIDを識別するための4ビットのフィールド。ドメインIDのデフォルト値は0で、与えられた技術に対して単一の番号空間しか無いことを意味します。しかし与えられた技術に対して1つ以上の番号空間が存在するとき(たとえばVXLAN空間の重複)、それぞれの番号空間は識別される必要があるため、1から始まるドメインIDを対応させることによってこれを識別します。
- Service ID: この3オクテットのフィールドにはVNI、VSID、I-SIDまたはVIDが設定されます。

RTの自動計算は2オクテットAS番号に対して適用可能であることを述べておくべきでしょう。4オクテットAS番号については、RTは手動で設定される必要があります。なぜなら3オクテットのVNIフィールドが2オクテットのlocal administratorフィールドに収まらないからです。

5.1.3. EVPN BGP経路の構築

EVPNにおいて、たとえばフォワーディングテーブルを識別するMPLSラベルは、egress PEによってEVPNコントロールプレーンを通じて配布され、ingress PEによって与えられたパケットのMPLSヘッダーに設定されます。このラベルはパケットがegress PEに受信されたときにパケットをdispositionするために使用されます。これはegress NVEがVNIを使用する方法ととても良く似ていますが、MPLSラベルがローカルでのみ意味を持つ値であるのに対し、VNIはグローバルで意味のある値である点が異なります。したがって、ローカルで割り当てられたVNIを使用する方式をサポートするときには特に、MAC/IP Advertisement経路のMPLS Label 1フィールド、Ethernet A-D per EVI経路のMPLSラベルフィールド、Inclusive Multicast Ethernet Tag (IMET)経路のP-Multicast Service Interface (PMSI) Tunnel属性のMPLSラベルフィールドはVNIを運ぶために使用されます。このメモのバランスを取るため、上記のMPLSラベルフィールドはVNIフィールドとして参照します。VNIフィールドはローカルVNIにもグローバルVNIにも両方に使用します。いずれの場合でも24ビットのフィールド全体でVNIの値をエンコードします。

VLAN-Basedサービス(MAC-VRFごとに単一のVNI)については、MAC/IP Advertisement経路、Ethernet A-D per EVI経路、IMET経路の中のEthernet Tagフィールドは、RFC7432のVLAN-Basedサービスにあるように、0に設定しなければなりません(MUST)。

VLAN-Aware Bundleサービス(MAC-VRFごとに複数のVNIで、それぞれのVNIが自身のブリッジテーブルに関連付けられる)については、MAC/IP Advertisement経路、Ethernet A-D per EVI経路、IMET経路の中のEthernet Tagフィールドは、MAV-VRF内部のブリッジテーブルを識別しなければなりません(MUST)。つまりそのEVIに対する一連のEthernnet Tagは、EVIに属するすべてのPEにおいて一貫して設定される必要があります。ローカルに割り当てられるVNIについては、Ethetnet Tagフィールドで広告される値がRFC7432のVLAN-Aware BundleサービスのようにVIDに設定されなくてはなりません(MUST)。このような設定は与えられたドメインにおいてそのEVNIに参加するすべてのPE機器において一貫して設定される必要があります。グローバルVNIについては、Ethetnet Tagフィールドで広告される値が、既存のイーサネットタグの意味に適合する限りにおいてはVNIに設定されるべきです(SHOULD)。つまりVNIがMAC-VRFにあるブリッジテーブルを識別し、一連のVNIはそのEVIに属するそれぞれのPEにおいて一貫して設定されます。

どのタイプのデータプレーンカプセル化(VXLAN、NVGRE、MPLS、MPLS in GRE)であるのかを示すために使用されるものが、RFC5512で定義されるBGP Encapsulation拡張コミュニティです。これはegress PEによって広告されるすべてのEVPN経路(MAC Advertisement、Ethrenet A-D per EVI、Ethrenet A-D per ESI、IMET、Ethernet Segment)に含まれます。RFC5512に定義されているカプセル化の方式のリストに5つの新しい値がIANAによって割り当てられました。これらは11節に掲載します。

11節に掲載しているMPLSカプセル化トンネル方式は、MPLSでないカプセル化方式だけをサポートする広告ノードと、MPLSとMPLSでないカプセル化方式の両方をサポートする広告ノードを区別するために必要です。MPLSカプセル化のみをサポートする広告ノードはどのカプセル化トンネル方式も広告する必要ありません。BGP Encapsulation拡張コミュニティがない場合は、MPLSカプセル化であるか静的に設定されたカプセル化が仮定されるということです。

経路のMP_REACH_NLRI属性のNext HopフィールドはNVEのIPv4アドレスまたはIPv6アドレスに設定されなければなりません(MUST)。残りのフィールドはRFC7432に従って設定されます。

ここで定義した手順、つまりMPLS Labelフィールドを使用してVNIを運び、Tunnel Encapsulation拡張コミュニティでVNIの使用方法を指定する手順は、draft-ietf-idr-tunnel-encaps-09の8.2.2.2節「有効なVNIが伝達されない場合」に沿ったものになっています。

5.2. MPLS over GRE

EVPNデータプレーンは、MPLS PSNトンネルサーバレイヤー越しにあるEVPN MPLSクライアントレイヤーのようにモデル化されています。EVPN機能のいくつか(スプリットホライズン、エイリアシング、バックアップパス)はMPLSクライアントレイヤーに紐付いています。MPLS over GRE カプセル化を使用する場合、EVPN MPLSクライアントレイヤーはIP PSNトンネルを透過的に運ぶことができます。そのためEVPN手順と関連するデータプレーンの運用に影響はありません。

RFC4023ではMPLS over GRE カプセル化を使用する標準を定義しており、この目的に使用することができます。しかしMPLS over GREをEVPNと結合して使用する場合、PノードがGREキーに基づいて等コストマルチパス(ECMP)を実行するのであれば、GREキーフィールドを使用し、32ビットのエントロピー値を提供することが推奨されます。そうでなければGREヘッダにはGREキーフィールドを含めるべきではありません(SHOULD NOT)。ChecksumフィールドとSequence Numberフィールドは含めてはいけません(MUST NOT)。GREヘッダ中の対応するCビットとSビットはゼロに設定されなければなりません(MUST)。このカプセル化方式をサポートする能力のあるPEは、前節で記載したようにMPLS over GRE カプセル化を示すTunnel Encapsulation拡張コミュニティを付与したEVPN経路を広告するべきです(SHOULD)。

6. 複数のデータプレーンカプセル化のEVPN

RFC5512のBGP Encapsulation拡張コミュニティを使用することによって、与えられたEVIに属するそれぞれのNVEは、そのEVIに属する他のNVEのそれぞれがサポートするカプセル化方式を知ることができるようになります。つまり与えられたEVIに属するそれぞれのNVEは複数のデータプレーンカプセル化をサポートすることができます。egress NVEから広告された一連のカプセル化方式とingress PEがサポートするカプセル化方式の和集合が空集合でない場合に限って、ingress NVEはegress NVEにフレームを送ることができます。和集合の中からどのカプセル化方式を選択するのかはingress PEが自由に判断できます(5.1.3節で述べたとおり、BGP Encapsulation拡張コミュニティがない場合はデフォルトでMPLSカプセル化かローカルで設定されたカプセル化方式が仮定されます)。

PEが複数のサポートしているカプセル化方式を広告する場合、8.3.1節で記述されるスプリットホライズン・フィルタリングに関連する手順を含むEVPN手順を使用するようなカプセル化方式を広告しなければなりません(MUST)。たとえばVXLANとNVGRE(またはMPLSとMPLS over GRE)カプセル化方式は同じEVPN手順を使用します。そのためPEはこれらの両方を広告することができますし、どちらか一方または両方を同時にサポートすることができます。しかしPEはVXLANとMPLSをカプセル化方式として広告してはなりません(MUST NOT)。なぜなら(a)EVPN経路のMPLSフィールドがMPLSフィールドラベルもしくはVNIのいずれか一方に設定され両方ではないし、(b)(スプリットホライズン・フィルタリングのような)EVPN手順がVXLAN/NVGREカプセル化とMPLSカプセル化では異なるからです。

ブロードキャストフレームとマルチキャストフレームを送信するために共有マルチキャストツリーを使用するingressノードは、それぞれの異なるカプセル化方式について区別されたツリーを維持することができます。

与えられたEVIについてそのEVIに属するすべてのNVEが少なくとも1つの共通のカプセル化方式をサポートすることを保証することは事業者の責任です。もしこの条件が破られた場合、サービス断や障害になりえます。BGP Encapsulation拡張コミュニティを使用することで、この条件が破られたときにそれを検知することができますが、どのような対応をとるかは事業者の自由な判断であり、この文書の範囲外とします。

7. シングルホームNVE - ハイパーバイザに存在するNVE

もしNVEとそのホストやVMが同じ物理デバイスに同居するとき、例えば1つのサーバにあるとき、その間のリンクは仮想的なものであり、典型的には運命共同体です。つまり配下にあるホストやVMは典型的にはマルチホームしていなかったりマルチホームしていても単にVMをホストするサーバとNVEのローカルの問題であって、その他のサーバに存在する他のNVEにとっては「見える」必要がありません。そのためいかなる特別なプロトコルの仕組みも必要としません。

続く小節では、NVEがハイパーバイザに存在していてVXLAN(またはNVGRE)がカプセル化に使用されている場合のEVPN手順への影響について考察したいと思います。

7.1. VXLAN/NVGREカプセル化のEVPN BGP経路と属性への影響

異なるグループのデータセンターが異なる管理ドメインにあり、これらのデータセンターがRFC7365に記載されているような1つ以上のバックボーンコアプロバイダによって接続されているようなシナリオにおいて、RFC7432に記述されているように、RDはEVIごとまたはNVEごとに一意な値でなければなりません。言い換えると、グローバルVNIに対して2つ以上の管理ドメインが存在しているときには必ず一意なRDが使われなくてはなりません。もしくはVNIがローカルで意味を持つ値であるときは必ず一意なRDが使われなくてはなりません。そのためRFC7432に記述されているように一意なRDを常に使用することが推奨されます。

NVEがハイパーバイザに存在するとき、マルチホーミングに関連するEVPN BGP経路と属性は必要ありません。これによって必要な経路や属性をRFC7432の7節に一覧された8個から部分集合である次の4個に減らすことができます。

MAC/IP Advertisement経路
Inclusive Multicast Ethernet Tag経路
MAC Mobility拡張コミュニティ
Default Gateway拡張コミュニティ

しかし、RFC7432の8.6節で留意されているように、与えられたESに接続されているマルチホームのegress NVEと連携して、シングルホームのingress NVEが高速収束やエイリアシング、バックアップパスなどを使用するためには、シングルホームのingress NVEもEthernet A-D per ES経路やEthernet A-D per ESなどの経路を受信して処理できるようにしておくべきです。

7.2. VXLAN/NVGREカプセル化のEVPN手順への影響

NVEがハイパーバイザに存在するとき、マルチホーミングに関連するEVPNの手順は必要ありません。これはNVEで実行する手順を以下の部分集合に制限します。

RFC7432 10.1節に基づいて、VMからのMACアドレスをローカル学習する
ローカルで学習したMACアドレスをMAC/IP Advertisement経路を使ってBGPで広告する
RFC7432 9節に基づいてBGPを用いてリモート学習する
IMET経路を使用して他のNVEを発見してマルチキャストトンネルを構築する
RFC7432の15節の手順に基づいてMACアドレスモビリティのイベントを処理する

しかし、RFC7432の8.6節で留意されているように、与えられたESに接続されているマルチホームのegress NVEと連携して、シングルホームのingress NVEが高速収束やエイリアシング、バックアップパスなどを使用するためには、シングルホームのingress NVEも、RFC7432の8.2節「高速収束」と8.4節「エイリアシングとバックアップパス」に定義されているようにEthernet A-D per ES経路やEthernet A-D per ESなどの経路をingress nodeとして処理できるような実装をしておくべきです。

8. マルチホームNVE - ToRスイッチに存在するNVE

この節ではNVEがToRスイッチに存在して、(VMが収容されている)サーバがこのToRスイッチにマルチホームしているようなシナリオについて考察します。マルチホームのNVEはAll-ActiveまたはSingle-Activeの冗長モードで動作しています。もしサーバがシングルホームでToRスイッチに接続している場合、必要なEVPNの機能が考慮されている限り、このシナリオは7節で考察したNVEがハイパーバイザに存在するときと似たものになります。

RFC7432ではマルチホーミングをサポートするための一連のBGP経路、属性、手順が定義されています。まずこれらの機能と手順について印、VXLAN(またはNVGRE)によってこれらのうちのどれが影響を受けるのかとどのような修正が必要なのかについて検討したいと思います。この節の後半で見るように、MPLSでないオーバーレイカプセル化(VXLANやNVGREなど)によって影響を受けるEVPN手順は、ラベルのスタックではなくひとつのIDのための空間を提供するものです。これに当てはまるのが8.3.1節に記載しているマルチホームESIのためのスプリットホライズン・フィルタリング手順です。

8.1. EVPNマルチホーミングの特徴

この節ではカプセル化の依存関係に注目するためにEVPNのマルチホーミングの特徴を要約したいと思います。この節ではハイレベル電の特徴と機能についてだけ記述します。より詳細な内容についてはRFC7432を参照してください。

8.1.1. マルチホームしているESの自動発見

同じESに(例えば同じサーバにLink Aggregation Group (LAG)を用いて)接続しているEVPN NVE(PE)は、BGP経路の交換によって設定無しでお互いを自動的に発見することができます。

8.1.2. 高速収束とMass Withdrawal

EVPNでは、ESへの接続に障害(リンクやポートの障害)が起こったときにフォワーディングテーブルを更新できるよう、リモートNVEに効率的かつ迅速に信号を送る仕組みを定義しています。これはそれぞれのNVEがEtherent A-D per ES経路をローカルに接続されたそれぞれのセグメントに対して広告することで実現されています。接続されているセグメントの接続性に障害があったときに、NVEは対応するEthernet A−D経路をwithdrawします。これに応じてこのwithdrawを受信したすべてのNVEはそのESに関連付けられたすべてのMACアドレスに対してネクストホップ隣接性を更新します。もし他に同じセグメントのEthernet A-D経路を広告しているNVEがいなければ、withdrawを受信したNVEは単にそのセグメントのMACエントリーを無効化します。そうでなければNVEはネクストホップ隣接性リストを適切に更新します。

8.1.3. スプリットホライズン

もしサーバが2つ以上のNVEにマルチホームしていて(ES1というESで表します)、All-Active冗長モードで動作していて、BUM(ブロードキャスト, Unknownユニキャスト、マルチキャスト)パケットをいずれかのNVEに送信するとき、このサーバに接続された別のNVEを経由してそのパケットがループしてサーバに送り返されないようにすることが重要です。NVEにおけるフィルタリングの仕組みによりこのようなループとパケットの重複を防ぎます。これはスプリットホライズンと呼ばれます。

8.1.4. エイリアシングとバックアップパス

ステーションが複数のNVEにマルチホームしているような場合、そのステーションが送信するトラフィックに関連する一連のMACアドレスを単一のNVEだけが学習するような可能性があります。これによって複数のNVEがマルチホームしているステーションに接続しているにもかかわらず、リモートNVEは単一のNVEからこれらのMACアドレスについてのMAC Advertisement経路を受信することになります。結果としてリモートNVEはマルチホームしているESに接続されたNVEの間で効果的にロードバランスすることができなくなります。例えばNVEがアクセスでデータパス学習を実行しているときに、ステーションのロードバランス機能がトラフィックの送信元アドレスでハッシュしたときに単一のNVEに向いてしまうような場合がこれに該当します。これが起こるその他のシナリオとしては、NVEがアクセスでのコントロールプレーン学習(ARPを使うなど)に頼っているが、ARP トラフィックがLAGの単一のリンクにハッシュされるような場合です。

この問題を緩和するためにEVPNは「エイリアシング」という概念を導入しました。これはローカルにアタッチされたESでMACアドレスを学習していないときでも、そのESへの到達性があることをNVEが伝えられるようにする機能です。このためにEthernnet A-D per EVI経路が使用されます。非ゼロのESIを含んだMAC Advertisement経路を受信したリモートNVEは、そのESIを含んでいてSingle-Activeフラグが設定されていないEthernet A-D経路を使用して対応するセグメントへの到達性を広告しているすべてのNVEを通じて、このMACアドレスが到達可能であるとみなします。

バックアップパスはこれに近い機能で、冗長モードがSingle-Activeである場合に適用されるものです。この場合NVEはローカルにアタッチされたESについて到達可能であることを、同様にEthernet A-D経路を使用して伝達します。非ゼロのESIを含んだMAC Advertisement経路を受信したリモートNVEは、経路を広告しているNVEを通じてそのMACアドレスが到達可能であるとみなします。さらにリモートNVEは、そのESIを含んでいてSingle-Activeフラグが設定されているEthernet A-D経路を使用して対応するセグメントへの到達性を広告しているNVEを、そのMACアドレスに対するバックアップパスとしてインストールします。

8.1.5. DF選出

もしホストがAll-Active冗長モードで動作しているES上で2つ以上のNVEにマルチホームしているとき、与えられたEVIに対して、これらのうちの1つのNVEだけが「Designated Forwarder」(DF)と呼ばれ、ブロードキャスト、マルチキャスト、もしそのEVIで設定されている場合はユニキャストも、を送信する責任を持ちます。

これはAll-Active冗長モードでマルチホームしているホストやVMへの複数宛先トラフィックが重複して配送されることを防ぐために必要です。

IEEE802.1Qのtaggedのフレームをホストから受信したNVEにおいて、RFC7432の8.5節に従ってホストのVIDに基づいてDF選出が行われます。さらに与えられたESのマルチホームのPEにおいてIDがそれらの間で一貫して設定されている限りにおいては、VNIやEVIや標準化されたVIDなどの設定されたIDをDF選出に使用することができます(MAY)。

VXLANでカプセル化されたフレームを受信したGWにおいて、VNIを使用してDF選出が行われます。繰り返しになりますが、与えられたイーサネットセグメントについてVNIは一意で一貫性がある(重複したVNIが存在しない)ことが仮定されいます。

8.2. EVPN BGP経路と属性に対する影響

このシナリオにおいてはマルチホーミングがサポートされているので、RFC7432に定義されているBGP経路と属性をすべて使用することになります。MAC Advertisement経路およびEthernet A-D per EVI経路、IMET経路に含まれるイーサネットタグIDは5.1.3節に従って設定されます。さらにMAC Advertisement経路よEthernet A-D per EVI経路のVNIフィールドも5.1.3節に従って設定されます。

8.3. EVPN手順に対する影響

ここではNVEがSingle-Active冗長モードとAll-Active冗長モードのいずれで動作しているかに基づいて、2つのケースについて検証する必要があります。

はじめにホストが一連のNVEにマルチホームしているSingle-Active冗長モードの場合を考えます。与えられたVNIについて、ある時点においてはただ一つのNVEだけがactiveになります。この場合エイリアシングは必要なく、スプリットホライズン・フィルタリングも必要にならないでしょう。しかしマルチホームのESの自動発見や高速収束、mass withdrawal、バックアップパス、DF選出などの機能は必要となります。

次にAll-Active冗長モードの場合を考えます。この場合8.1節に羅列したすべてのEVPNマルチホーミングの機能のうち、スプリットホライズンとエイリアシングがVXLANまたはNVGREカプセル化の使用により影響を受けます。これら2つの機能はMPLSクライアントレイヤーに依存しているからです。これらのカプセル化方式においてはMPLSクライアントレイヤーが存在しないため、代替の手順と仕組みによって必要な機能を提供します。詳しくは次に記載します。

8.3.1. スプリットホライズン

EVPNにおいて、All-Activeマルチホーミングをサポートするスプリットホライズン・フィルタリングのためにMPLSラベルを使用しています。ungress NVEがパケットをカプセル化するときにsite of originに対応するラベル(ESIラベル)を加えます。egress NVEは複数宛先トラフィックのフレームをインターフェイスから転送しようと試みるときにESIラベルを確認して、そのインターフェイスに関連付けられた識別子(ESI)が同じsiteに対応するものであるとき、パケットを破棄します。これによって転送ループを防ぎます。

VXLANとNVGREによるカプセル化はESIラベルを含んでいないため、これらのカプセル化に対してこのスプリットホライズン・フィルタリングの機能を実行するための他の手段を考え出す必要があります。スプリットホライズン・フィルタリングのために次のアプローチがVXLAN(またはNVGRE)カプセル化が使用されているときに推奨されます。

それぞれのNVEは、マルチホームESを共有している他のNVEに関連付けられたIPアドレスを追跡します。NVEが複数宛先フレームをオーバーレイネットワークから受信したとき、そのNVEはトンネルヘッダ内の送信元IPアドレス(ingress NVEに対応する)を検査し、そのingress NVEと共有しているESに接続されたすべてのローカルインターフェイスにおいてフレームをフィルタします。このアプローチによって、(ホストからなどの)アクセスインターフェイスから入ってきてフラッディングされるすべてのトラフィックに対して、ingress NVEは(DF選出の状態にかかわらず)すべての直接続されたイーサネットセグメントにローカルで複製を行うことが必要となりあます。このアプローチは「ローカルバイアス」と呼ばれ、スプリットホライズン・フィルタリングのためにNVEごに使用されるIPアドレスが、NVEごとのイーサネットセグメントごとにIPアドレスが必要になるものに対して、ただ一つであるという利点があります。

マルチホームしているPE機器のグループ内で適切にスプリットホライズン・フィルタリングを動作させるためには、スプリットホライズン・フィルタリングのためにRFC7432の手順を実行しているMPLS over GRE カプセル化のPE機器と、ローカルバイアスの手順を実行しているVXLAN/NVGREのPE機器を同じイーサネットセグメント上に設定してはなりません(MUST NOT)

8.3.2. エイリアシングとバックアップパス

VXLAN/NVGREカプセル化に対するエイリアシングとバックアップの手順はMPLSのものと非常に似ています。MPLSの場合、対応するESがAll-Activeのマルチホームで動作しているときはエイリアシングにEthetnet A-D per EVI経路が使用されます。Single-Activeのマルチホーミングで動作しているときはバックアップパスに同じ経路が使用されます。VXLAN/NVGREの場合、同じ経路がエイリアシングとバックアップパスの両方に使用されますが、Ethenret A-D per EVI経路のEthernet TagフィールドとVNIフィールドが5.1.3節に記載したように設定される部分が異なります。

8.3.3. Unknownユニキャストトラフィックの指定

EVPNにおいて、egress PEに対してUnknownユニキャストトラフィックをフラッディングするためにingress PEがIngress Replicationを使用するとき、ingress PEはそのようなBUMトラフィックを識別するために(Knownユニキャストに使うものとは)異なるEVPNラベルを使用します。egress PEはこのラベルを使ってそうしたBUMトラフィックを識別子、All-Activeでマルチホームしているサイトに対してDFフィルタリングを適用します。Unknownユニキャストトラフィックの指定がない状態でUnknownユニキャストのフラッディングを有効化する場合、次の条件下においてAll-Activeのマルチホームに対して一過性のトラフィックの重複が発生しえます: ホストのMACアドレスがegress PEによって学習されているが、MAC Advertismenetがingress PEにおいて受信されていないか処理されていないような場合、そのホストのMACアドレスはingress PEではUnknownになりますがegress PEではKnownになります。そのためそのホストのMACアドレス宛のパケットがingress PEに到着したときに、ingress PEはすべてのegress PEに対してIngress Replicationでフラッディングをします。そしてegress PEではKnownであるため、複数のコピーがAll-Activeなマルチホームのサイトに転送されてしまいます。このような一過性のパケットの重複は、a) 宛先のホストがAll-Active冗長モードで運用されていて、b) Unknownユニキャストのフラッディングがネットワークで有効化されていて、c) Ingress Replicationが使用されていて、d) ingress PEがBGP EVPN広告でそのホストのMACアドレスを学習する前にそのホスト宛のトラフィックが到着した、ときだけに発生することは述べておくべきでしょう。もしそのような一過性のパケットの重複が起こることが望ましくないのであれば(起こる可能性は低いと思いますが)、VXLAN-GPEカプセル化をこれらのPEの間で使用し、ingress PRがBUMトラフィックビット(Bビット)を設定してIngress ReplicationのBUMトラフィックであることを示す必要があります。

9. マルチキャストのサポート

VLAN-Basedサービスの場合は与えられたEVI(例えば与えられたVNI)、VLAN-Aware Bundleサービスの場合は与えられた<EVI, VLAN>に関連付けられたエンドポイントの間でマルチキャストトンネルを発見するためにEVPN IMET経路が使用されます。この経路のすべてのフィールドは5.1.3節に記載したとおりに設定されます。生成元ルータIPアドレスフィールドはNVEのIPアドレスに設定されます。この経路はPMSI Tunnel属性でタグ付けられ、使用されるマルチキャストトンネルの方式とマルチキャストトンネルの識別子をエンコードしています。トンネルカプセル化方式は5.1.1節に従ってBGP Encapapsulation拡張コミュニティを付加することでエンコードされます。例えばPMSI Tunnel属性がマルチキャストトンネルの方式をProtocol Independent Multicast - Sparse-Mode (PIM-SM)であることを示し、BGP Encapapsulation拡張コミュニティがそのトンネルのカプセル化方式をVXLANであると示すこともできます。RFC6514で定義されている次のトンネル方式をVXLAN/NVGREのPMSI Tunnel属性として使用することができます。

3 - PIM-SSM Tree
4 - PIM-SM Tree
5 - BIDIR-PIM Tree
6 - Ingress Replication

VXLANとNVGREカプセル化でローカルでVNIを割り当てる場合、RFC7432にある通り、それぞれのPEは使用するマルチキャストトンネルタイプ(Ingress Replication, PIM-SM, PIM-SSMまたはBIDIR-PIMトンネル)のためにIMET経路をEVPNインスタンスに属する他のPEに対して広告しなければなりません(MUST)。しかしVNIをグローバルで割り当てる場合、それぞれのPEは、Ingress ReplicationとPIM-SSMトンネルに対してはIMET経路をEVPNインスタンスに属する他のPEに対して広告しなければなりません(MUST)が、PIM-SMまたはBIDIR-PIMトンネルの場合は任意です(MAY)。PIM-SMまたはBIDIR-PIMトンネルの場合、IMET経路を経路に含まれている情報はトンネルを構築するために必要ありません。

マルチキャストトンネルがツリーである品折尾に置いて、InclusiveとAggregate Inclusiveの派生の両方を使うことができます。前者の場合、マルチキャストツリーはVNIに専属するものです。一方で後者は複数のVNIにまたがってマルチキャストツリーが共有されます。VLAN-Basedサービスにおいては、Aggregate Inclusiveモードは、NVEが複数のIMET経路を異なるRT(VNIごとに1つ)で広告しながら、同じトンネル識別子をPMSI Tunnel属性にエンコードすることで実現できます。VLAN-Aware Bundleサービスにおいては、Aggregate Inclusiveモードは、NVEがEthernet Tagフィールドに異なるVNIをエンコードした複数のIMET経路を広告しながら、同じトンネル識別子をPMSI Tunnel属性にエンコードすることで実現できます。

10. データセンター相互接続(DCI)

DCIについて、MPLS/IPコアネットワーク越しに(ここで記述している)EVPNオーバーレイを動作させているデータセンターを接続するときに主に次の2つのシナリオが考えられます。

シナリオ1: GWを使用したDCI
シナリオ2: ASBRを使用したDCI

次の2つの小節ではそれぞれのシナリオの運用について記載します。

10.1. GWを使用したDCI

これはWAN越しにデータセンターを相互接続するための典型的なシナリオです。このシナリオではEVPN経路はそれぞれのGWで終端して処理され、MAC/IP経路は常にDCからWAN2再広告されますが、NVEにおいてUnknown MACアドレス(とデフォルトIPアドレス)が使用されていない場合はWANからDCには再広告されません。このシナリオではそれぞれのGWはそれぞれのVNIのためのMAC-VRF(と/またはIP-VRF)を保持しています。このアプローチの主な利点は、デフォルトIP経路とUnknown MAC経路が使用されている場合、リモートデータセンターからのいかなるMACアドレスとIPアドレスについてもNVEで保持しておく必要がないことです。つまり、自身のデータセンターにローカルな経路だけを保持しておけばよいのです。デフォルトIP経路とUnknown MAC経路が使用されているとき、NVEからのいかなるUnknown IP/MACパケットは、すべてのVPN MAC経路とIP経路が維持されているGWに転送されます。このアプローチによってNVEにおいてMAC-VRFとIP-VRFのサイズを劇的に減らすことができます、さらに、マルチホームのネットワークや機器冗長化のシナリオにおいてリンクやNVEの障害時に収束時間をより高速にすることができます。なぜなら(大量のwithdrawメッセージなどの)障害に関係するBGP経路がリモートDCのすべてのリモートNVEに対して伝搬される必要がないからです。このアプローチはDCI-EVPN-OVERLAYの3.4節に記載されています。

10.2. ASBRを使用したDCI

このアプローチは最初のアプローチと反対のものだと考えることができます。このアプローチではNVEよりもDCI機器を単純化することを好んでいます。NVEで維持される必要があるMAC-VRF(とIP-VRF)テーブルのサイズが大きくなる一方で、DCI機器がMAC(とIP)の転送テーブルを維持する必要がありません。さらにDCI機器はマルチホーミングに関連する経路を終端し処理する必要がありませんが、これらのメッセージをend-to-endのLabel Switched Path(LSP)を確立するためにリレーする必要があります。言い換えるとこのアプローチでのDCI機器はinter-AS Option BのASBR(RFC4364の10節を見てください)によく似た動作をします。これにはdownstreamで割り当てられたMPLS VPNラベルのように使われるローカルで割り当てられたVNIが必要になり、すべての実用的な目的のためにVNIが24bitのVPNラベルのように機能します。このアプリーチはMPLSカプセル化のデータセンター(またはキャリアのイーサネットネットワーク)にも同様に適用可能です。

inter-AS Option Bにおいて、ASBRがそのDCから内部BGP(iBGP)越しにEVPN経路を受信し、それを他のASBRのに再広告したとき、EVPN経路のBGPネクストホップを自分自身に書き換えて再広告します。そのため広告を生成したPEを識別する情報が失われます。このBGPネクストホップの書き換えはEVPNのMass Withdrawal経路(Ethernet A-D per ES経路)とその手順に逆に影響を与えます。しかしEVPNエイリアシングの仕組みと手順には影響を与えません。なぜならエイリアシングの経路(Ethernet A-D per EVI経路)が広告されているとき、受信したPEはまず、与えられたEVIについてMACアドレスを対応する<ES, EVI>に解決し、続いて<ES, EVI>を<ES, EVI>が到達可能であるような複数のパス(とそれに関連付けられるネクストホップ)に解決します。エイリアシングとMAC経路は両方ともEVIごとに広告され、同じRDとRDを(EVIごとに)使用するため、受信したPEはそれらをBGPパスごとに(例えば生成元のPEごとに)関連付けることができます。そのため、例えばあるMACアドレスがある<ES, EVI>経由で到達可能であり、つづいて、それがある一連のBGPパスを経由して到達可能であるから、このMACはこの一連のBGPパスから到達可能である、といったように、再帰的な経路解決を行うことが可能です。EVIごとに動作するため、MAC経路と対応するエイリアシング経路の関連付けは同じRDとRTによって固定・決定されます。つまり、これらの経路がASBRを経由してBGPネクストホップが書き換えられたとしても曖昧さはありません。すなわち、受信したPEは複数のエイリアシング経路を同じEVIについて単一のネクストホップ(単一のASBR)から受信することがありますが、その<ES, EVI>に対して複数のパスを構築することが依然として可能です。

しかし、生成元PEに対応するBGPネクストホップアドレスが書き換えられたとき、Mass Withdrawal経路(Etherent A-D per ES経路)とそれに対応するMAC経路をRDとRTに基づいて関連付けることができません。なぜならMass Withdrawal経路のRDはMAC経路のRDと異なるからです。それゆえASBRと経路受信するPEにおいて必要となる機能は、Mass Withdrawal経路が生成されたかどうかとこの経路について経路解決の曖昧さを処理する必要があるかに依存します。つづく2つの小節ではNVEがハイパーバイザにあるのかToRスイッチにあるのかに基づいてASBRと経路受信するPEにおいて必要となるこの機能について記載します。

10.2.1. シングルホームNVEとASBR機能

7.1節で記述したようにNVEがハイパーバイザにあるとき、マルチホーミングはありません。そのため経路生成するNVEはEthernet A−D per ES経路やEthernet A-D per EVI経路を送信する必要がありません。しかし7節で述べたようにシングルホームのingress NVEが、あるESに接続してマルチホームしているegress NVEと連携して高速収束やエイリアシングとバックアップパスの恩恵を受けるには、シングルホームNVEはEthernet A-D per ES経路とEthernet A-D per EVI経路を受信して処理できるべきです。これらの経路の処理は次の節で記載します。

10.2.2. マルチホームNVEとASBR機能

NVEがToRスイッチにあってマルチホームの上長モードで動作しているとき、8節で記述したように経路生成するマルチホームのNVEは(Mass WIthdrawalに使われる)Ethrnet A-D per ES経路と(エイリアシングに使われる)Ethernet A-D per EVI経路を送信する必要があります。上述したようにASBRによるBGPネクストホップの書き換えは、異なるASBRのEthrenet A-D per ES経路がリモートNVEに受信されたときに曖昧さを生み出します。なぜなら受信したNVEはその経路を、同一の経路生成元のNVEによって広告されたそのESのMAC/IP経路に関連付けることができないからです。この曖昧によって異なるASに属するNVEが受信したESごとのMas WIthdrawalの機能が妨げられます。

例として、CEがPE1とPE2にマルチホームしていて、これらのPEがASBR1とASBR2を経由してリモートのPE3と接続しているようなシナリオを考えます。さらにPE1がCE1からM1を受信するが、PE2は受信しません。このとき、PE1はES1のEthernet A-D経路とEVI1のEthernet A-D経路とM1を広告しますが、PE2はES1のEthernet A-D経路とEVI1のEthernet A-D経路だけしか広告しません。ASBR1はこれら5つの経路すべてを受信してASBR2に(BGPネクストホップを自分自身に書き換えて)渡します。順に、ASBR2はそれらのBGPネクストホップを自分自身(ASBR2)にしてリモートPE3に渡します。さらにPE3によって受信された2つのEthernet A-D per ES経路は同じ情報を持つことになります。同じESIと同じBGPネクストホップです。これらの両方の経路はPE3のBGPプロセスによって保持される(なぜならRDが異なるので異なるBGP経路として扱われるから)にもかかわらず、これらのうち1つからの情報だけがL2ルーティングテーブル(L2 RIB)で使用されることになります。

                      PE1
                     /   \
                    CE     ASBR1---ASBR2---PE3
                     \   /
                      PE2

図3: Inter-AS Option B

このとき、PE2とCEの間の回線がダウンしたとき、PE2はそのEthernet A-D per ES経路に対するNetwork Layer Reachability Information (NLRI)のwithdrawを送信し、このwithdrawは伝搬され、PE3に受信されます。PE3は対応するBGP経路を削除しますが、関連する情報(すなわちESIとBGPネクストホップ)をL2ルーティングテーブル(L2 RIB)から削除しません。なぜなら同じ情報を持った他の(PE1で生成された)Ethernet A-D per ES経路が存在するからです。これがなぜMass Withdrawalの仕組みがDCIをinter-AS Option Bで動作させたときに機能しないのかです。しかし以前の述べたようにエイリアシングの機能は動作し、(エイリアシングに関連するwithdrawされるEVPN経路、つまりEthernet A-D per EVI経路に関連付けられた)「EVIごとのMass Withdrawal」も動作します。

上記の例ではPE3は2つのエイリアシング経路を同じBGPネクストホップ(ASBR2)で異なるRDとして受信します。エイリアシング経路のうち1つは航行されたMAC経路(M1)と同じRDを持っています。PE3は2つのエイリアシング経路を受信した際にRFC7432で仕様化された経路解決手順に従います。つまりM1を<ES, EVI1>に解決し、つづいて<ES, EVI1>をBGPパスのリストに解決します。このパスは、対応するVNI/MPLSラベルに沿った2つのパス(1つはPE1に関連付けられたもの、もう1つはPE2に関連付けられたもの)になります。両方のパスが同じBGPネクストホップ(ASBR2)で広告されていたとしても、受信したPE3は適切に処理できることを述べておくべきでしょう。そのためM1は2つのパスを経由して到達可能です。これによりM1に対してPE3からPE1とPE3からPE2の2つのend-to-end LSPが作られます。PEがM1宛のトラフィックを転送しようとしたとき、この2つのパスにロードバランスすることができます。同じBGPネクストホップを持ったエイリアシング経路の経路解決についてRFC7432では明示的に述べられていませんが、これが期待される動作であり、そのためここで詳細に述べました。

PE2とCEの間の回線がダウンし、PE2がそのEthernet A-D per EVI経路に対するNLRIのwithdrawを送信し、これらのwithdrawが伝搬されPE3によって受信されたとき、PE3はエイリアシング経路を削除し、パスのリストを更新します。つまりPE2に対応するパスを削除します。そのためこの<ES, EVI>に対応しこのパスリストを指すすべてのMAC経路は、PE1に関連付けられた単一のパスを持つように更新されたパスリストを持つことになります。この動作はEVI単位のレベルのMass Withdrawalだと考えることができます。EVI単位のレベルのMass Withdrawalの収束時間はES単位のレベルのMass Withdrawalより長くなりますが、MACごとのwithdrawよりは収束時間が大幅に短くなります。

与えられたESからあるPEが切り離されたとき、そのPEは以前に広告していたEthernet A-D per ES経路をwithdrawすることに加えて、以前に広告していたEthernet A-D per EVI経路についてもwithdrawしなければなりません(MUST)。EVPN inter-AS Option Bの1つ以上のASBRによってwithdrawするPEから分離されたリモートPEにとって、Ethernet A-D per ES経路のwithdrawは行動可能なものではありません。しかしリモートPEは以前に広告されたEthernet A-D per EVI経路を、withdrawを送信するPEによって広告されたその<ES, EVI, BD>の任意のMAC/IP Advertisement経路に相互に関連付けることができます。そのため、Etherent A−D per EVI経路のwithdrawを受信したときには、その<ES, EVI, BD>に関連付けられたすべてのMACアドレスのネクストホップからwithdrawを送信したPEを削除するべきです(SHOULD)。

前の例では、PE2とCEの間の回線がダウンしたとき、PE2はそのEthernet A-D per ES経路とper EVI経路をwithdrawするでしょう。PE3がそのEthernet A-D per EVI経路のwithdrawを受け取ったとき、PE2を対応する<ES, EVI, BD>に関連付けられたすべてのMACアドレスの有効なネクストホップからPE2を削除します。そのためこの<ES, EVI, BD>のすべてのMACのネクストホップは、このときPE1へのLSPを経由する単一のネクストホップのみになるでしょう。

要約すると、エイリアシング(とバックアップパス)はinter-AS Option BでもASBRやPEに追加の機能を必要としなくても動作することがわかります。しかしMass Withdrawalの機能はinter-AS Option Bに対してES単位からEVI単位に落ちてしまいます。つまり同じASからMass Withdrawalの経路を受信したPEはEthernet A-D per ES経路に対して行動を起こせるのに対して、異なるASからMass Withdrawalの経路を受信したPEはEthernet A-D per EVI経路に対して行動を起こします。

11. セキュリティについての考察

この文書ではIPベースのトンネル技術を使用してデータプレーンの転送をサポートします。そのためこれらのトンネル技術についてのセキュリティの考察が適用されます。この文書ではRFC7348のVXLANとRFC7637のNVGREのカプセル化のサポートを定義しています。これらのRFCのセキュリティの考察がデータプレーンの面でこの文章に適用されます。

RFC5512によれば、カプセル化ヘッダを形成するためや、トンネル方式を選ぶためや、特定のペイロードタイプに対してトンネルを選ぶためなどに使われる情報のいかなる修正も、誤ったルーティングや配送、それによる吐きを招く可能性があります。

より広く言うと、BGPを使用したIP到達性の情報の伝送に対するセキュリティの懸念事項はRFC4271とRFC4722において議論され、この文書で記述された拡張に対しても同様に適用可能です。

12. IANAについての考察

この文書では次のものを「BGPトンネルカプセル化属性トンネル方式」レジストリに登録します。

値	名前
8	VXLAN Encapsulation
9	NVGRE Encapsulation
10	MPLS Encapsulation
11	MPLS in GRE Encapsulation
12	VXLAN GPE Encapsulation

13. 参考文献

省略