RFC7432bis-00 BGP MPLS-Based Ethernet VPN

はじめに

この文書は RFC7432bis BGP MPLS-Based Ethernet VPN (draft-ietf-bess-rfc7432bis-00) 、つまりRFC7432の改訂版のドラフト0版の日本語訳であり、RFC7432との差分を理解するためのものです。

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

RFC7432との差分

RFC7432bis-00ではRFC7432のドキュメントの正確性のための修正に加えて、発行以降に行われてきた改良が反映されています。差分を以下にまとめます。

まだ00版で、誤字脱字や用語の不統一、曖昧さなどが残っています。翻訳時点で00版はexpireしていますが、01版はでていません。

RFC7432から削除された部分は打ち消し線、RFC7432bisで追加された部分は太字で記載しています。

免責

この翻訳を信用して不利益を被っても責任取れません的なやつ。

目次

Abstract

この文書はBGP MPLSベースのEthernet VPN (EVPN)の手順について記述しています。ここで記述されている手順はRFC7209の「Ethernet VPN (EVPN)の要件」を満たすものです。

1. はじめに

Virtual Private LAN Service (VPLS)はRFC4664, RFC4761, RFC4762で定義されている実績があり広く実用されている技術です。しかしこの既存の解決策は多くの制約を抱えています。マルチホーミング冗長化や、マルチキャストの最適化や、プロビジョニングの単純さや、フローベースのロードバランスやマルチパスなどです。こうした制約はデータセンター(DC)のデプロイメントを考えた時に重要になります。RFC7209はこれらの制約を解くための新しい解決策の動機について記述しており、さらにこの新しい解決策が満たすべき要件についてもまとめています。

この文書はRFC7209で詳細が述べられている要件を満たすために、Ethernet VPN(EVPN)と呼ばれるBGP MPLSベースの解決策のための手順について記述しています。詳細な要件とその動機についてはRFC7209を参照してください。この文書で述べられるように、EVPNは既存のIP/MPLSプロトコルに対する拡張を必要とします。これらの拡張に加えてEVPNは既存のMPLS技術からいくつかの基本要素を使用します。

2. 要件の仕様

(RFC2119のいつものやつ)

3. 用語

BDブロードキャストドメイン(Broadcast Domain): ブロードキャストドメイン(Broadcast Domain)。ブリッジネットワークにおいてブロードキャストドメインはVirtual LAN(VLAN)に対応する。VLANは典型的には単一のVLAN ID(VID)によって表現されますが、802.1QIEEE802.1Q_2014のShared VLAN Leaming(SVL)が使われている場合においては複数のVIDで表現されることもあります。

ブリッジテーブル(Bridge Table): MAC-VRF上でブロードキャストドメインインスタンス化したもの

CE: カスタマーエッジ(Customer Edge)デバイス。ホストやルータやスイッチを指す

EVI: EVPNに参加するプロバイダーエッジ(PE)デバイスにまたがるEVPNの1つのインスタンスEVIは1つのBD(VLAN-basedサービスまたはVLAN Bundleサービス)もしくは複数のBD(VLAN-aware Bundleサービス)から構成されます。

MAC-VRF: PEにおけるMAC(Media Access Control)アドレスのための仮想ルーティング・フォワーディング(VRF)テーブル

イーサネットセグメント(Ethernet Segment, ES): カスタマーサイト(デバイスやネットワーク)が1つまたは複数のPEにイーサネットのリンクの集合で接続しているとき、このリンクの集合をイーサネットセグメントと呼びます

イーサネットセグメント識別子(Ethernet Segment Identifier, ESI): イーサネットセグメントを識別するためのユニークで0でないIDをイーサネットセグメントIDと呼びます

イーサネットタグID(Ethernet Tag ID): イーサネットタグはVLANなどの特定のブロードキャストドメインを識別します。EVPNインスタンスは1つまたは複数のブロードキャストドメインによって構成されます ネットワーク内で標準化されたIDで、BDを表します。次のIDのうちのいずれかになります: VLAN ID(Q-in-Qタグを含む)、設定されたID、VNI(Virtual Extensible Local Area Network (VXLAN) Network Identifiers)、標準化されたVID、I-SID(Service Instance Identifiers)などです。DF選出の目的で使用されるとき、同じBDに対するイーサネットタグIDはそのESに接続されたマルチホームPEにまたがって一貫して設定されます。VLAN-aware BundleサービスのEVPN経路内で使用される0でない識別子でもあります。

LACP: Link Aggregation Control Protocol

MP2MP: Multipoint to Multipoint

MP2P: Multipoint to Point

P2MP: Point to Multipoint

P2P: Point to Point

PE: Provider Edgeデバイス

Single-Active冗長モード: あるVLANに対してあるイーサネットセグメンへ/からのトラフィックを、そのイーサネットセグメントにアタッチされたすべてのPEのうちただ1つのPEのみが転送することが出来る場合、そのイーサネットセグメントはSingle-Active冗長モードで運用されていると定義します

All-Active冗長モード: あるVLANに対してあるイーサネットセグメントへ/からのknownユニキャストを、そのイーサネットセグメントにアタッチされたすべてのPEが転送することが出来る場合、そのイーサネットセグメントはAll-Active冗長モードで運用されていると定義します BUM: ブロードキャスト(Broadcast)、Unknownユニキャスト、マルチキャスト(Multicast)

DF: Designated Forwarder

NDF: 非DF(Non-Designated Forwarder)

VID: VLAN識別子

DCB: (ラベルの)Domain-wide Common Block。I-D.ietf-bess-mvpn-evpn-aggregation-labelから。

AC: 接続回線(Attachment Circuit)

4. BPG MPLSベースのEVPNの概要

この節ではEVPNの概要について説明します。EVPNインスタンスは、MPLS基盤のエッジにおいてプロバイダーエッジデバイス(PE)に接続されたカスタマーエッジデバイス(CE)から構成されます。CEはホストでもルータでもスイッチでも構いません。PEはCE同士の間に仮想的なレイヤー2のブリッジ接続性を提供します。プロバイダネットワークの中に複数のEVPNインスタンスを持つことができます。

PE同士はMPLSのLabel Switched Path(LSP)基盤によって接続することができます。この場合fast rerouteやresiliencyなどのMPLS技術の利益を受けることが出来ます。PE同士はIP基盤によっても接続することができます。IP/GRE(Generic Routing Encapsulation)トンネルやその他のIPトンネルをPE間で利用することが出来ます。この文書で述べる詳細な手順はトンネル技術としてのMPLS LSPに特化したものになっています。しかしこれらの手順はPacket Switched Network(PSN)トンネル技術であるIPトンネルに対しても拡張可能なものになっています。

VPLSの従来のブリッジングとは異なり、EVPNにおけるPE間のMAC学習はデータプレーンでは起こりません。その代わりコントロールプレーンで行われます。コントロールプレーンで学習を行うことでMAC学習プロセスをより良く制御できるようになります。たとえば誰がどのMACを学習するのかを制限したり、ポリシーを適用したり出来るようになります。さらに、MAC到達性情報の広告のためのコントロールプレーンには、IP VPN(RFC4364)に似せて、マルチプロトコルBGP(MP BGP)を選びました。これにより柔軟性と仮想化や相互作用するエージェント(ホストやサーバや仮想マシン)のグループの隔離を保つと言った機能を実現することが出来ます。EVPNにおいて、PEは接続されたCEから学習したMACアドレスを、MPLSラベルとともに他のPEに対してMP-BGPを使用したコントロールプレーンで広告します。あるペアのPE間において複数のLSPを経由することでMPLSコアでロードバランスすることもできます。言い換えれば、CEは複数のアクティブな接続点に接続することが可能であるということです。また一定のネットワーク障害に対する収束時間も改善されています。

しかしPEとCEの間のMAC学習はCEにとって最適な手法で実現されます。データプレーン学習、IEEE 802.1x、LLDP、IEEE 802.1aq、ARP、マネージメントプレーン、そしてその他のプロトコルもあります。

PEがコントロールプレーンにとって既知のすべてのMAC宛先アドレスについてレイヤー2のフォワーディングテーブルを生成するか、キャッシュベースの手法を実装するかはPE内部の判断です。たとえばMAC転送テーブルは、特定のPEに向かうアクティブなフローのMAC宛先に対してだけ生成することもありえます。

EVPNのポリシー属性はIP-VPNのものによく似ていまEVPNインスタンスはMAC-VRF単位でユニークなRoute Distinguisher(RD)と、系全体でユニークなRoute Targets (RT)を1つ以上必要とします。イーサネットインターフェイスでPEのMAC-VRF BDにアタッチされたCEは、1つ以上のイーサネットタグ(VLAN ID等)が設定されているでしょう。もしイーサネットタグがVLAN IDである場合、デプロイメントシナリオによってはEVPNインスタンスにまたがってVLAN IDのユニークさを保証する事があるでしょう。つまり、あるEVPNインスタンスにおいてすべての接続点で同一のVLAN IDを使用し、他のEVPNインスタンスがそのVLAN IDを使用しないというケースです。この文書ではこのケースを「ユニークVLAN EVPN」と呼び、これに最適化するために単純化した手順について記述します。

5. イーサネットセグメント

RFC7209で示されるように、それぞれのイーサネットセグメントはユニークな識別子をEVPN内で持つ必要があります。この節ではそのような識別子をどのように割り当てて、EVPNシグナリングで使うためにどのようにエンコードするのかを定義します。この文書の後半の節では、この識別子を使うプロトコルの仕組みについて記述しています。

カスタマーサイトが1つ以上のPEにイーサネットリンクの集合で接続しているとき、このイーサネットリンクの集合が「イーサネットセグメント」を構成します。マルチホームのサイトでは、それぞれのイーサネットセグメント(ES)はゼロでないユニークな識別子であるイーサネットセグメント識別子(Ethernet Segment Identifier, ESI)によって識別されます。ESIは10オクテットの整数で最上位オクテットが最初に送られるようにエンコードされます。次の2つのESI値は予約されています。

  • ESI 0 はシングルホームのサイトに使用されます
  • 0xFFが10回続くESIはMAX-ESIと呼ばれ、予約されています。

一般的に、あるイーサネットセグメントはネットワーク全体(すべてのPEのすべてのEVPNインスタンス)でユニークな予約されていないESIをもつべき(SHOULD)です。もしイーサネットセグメントを構成するCEがネットワーク運用者によって管理されている場合、ESIのユニーク性は保証されています。しかしCEが管理されていない場合、ネットワーク運用者はネットワーク全体でユニークなESIをそのイーサネットセグメントに対して設定しなければなりません(MUST)。これはイーサネットセグメントの自動発見とDesignated Forwarder (DF)の選出を可能にするために必要なものです。

CEが管理されているいないによらずネットワーク内のESIは次のフォーマットです。

+---+---+---+---+---+---+---+---+---+---+
| T |          ESI Value                |
+---+---+---+---+---+---+---+---+---+---+

ここで

T (ESIタイプ)は1オクテット(最上位オクテット)のフィールドで、残りの9オクテット(ESI Value)のフォーマットを指定するものです。次の6つのESIタイプを使うことができます。

  • Type 0 (T=0x00) - このタイプは運用者によって管理・設定された任意の9オクテットのESI値を示します。

  • Type 1 (T=0x01) - IEEE 802.1AZ LACPがPEとCEの間で利用されているとき、このESIタイプはLACPから次のパラメータを組み合わせることで自動的に生成されたESI値であることを示します。

    • CEのLACPシステムMACアドレス (6オクテット)。CEのLACPシステムMACアドレスがESI Valueフィールドの上位6オクテットにエンコードされなくてはならない(MUST)
    • CEのLACPポートキー(2オクテット)。CEのLACPポートキーがシステムMACアドレスの次の上位2オクテットにエンコードされなくてはならない(MUST)
    • 残りのオクテットは0x00で埋められるでしょう

CEが接続されている限り、そこに接続されている複数のPEは同一のスイッチとしてCEに扱われます。これによりCEは異なるPEに接続されたリンクを同一のバンドルとして束ねることが出来るようになります。

この仕組みは上記で定義されたユニーク性の要件をESIが満たす場合に使うことができます。

  • Type 2 (T=0x02) - このタイプはCEとPEの間でブリッジLANを経由して直接接続されていないホストの場合に使用されます。このESI Valueは自動生成されるもので、レイヤー2のブリッジプロトコルによって次のように決定されます。もしMultiple Spanning Tree Protocol(MSTP)がブリッジLAGで利用されている場合、ESIの値はイーサネットセグメントのブリッジPDU(BPDU)を受け取って決められます。これを実現するにあたってPEはMSTPを動作させる必要はありません。しかしPEはInternal Spanning Tree (IST)のルートブリッジMACアドレスとルートブリッジ優先度を、BPDUを受け取ることによって学習しなければなりません。このESI Valueは次のように生成されます。

    • ルートブリッジMACアドレス(6オクテット)。ルートブリッジMACアドレスがESI Valueフィールドの上位6オクテットにエンコードされなくてはならない(MUST)

    • ルートブリッジ優先度(2オクテット)。ルートブリッジ優先度がルートブリッジMACアドレス次の上位2オクテットにエンコードされなくてはならない(MUST)

    • 残りのオクテットは0x00で埋められるでしょう

この仕組みは上記で定義されたユニーク性の要件をESIが満たす場合に使うことができます。

  • Type 3 (T=0x03) - このタイプはMACベースのESI Valueであることを示し、自動生成もしくは運用者による設定が可能です。ESI Valueは次のように生成されます。

    • システムMACアドレス(6オクテット)。PEのMACアドレスがESI Valueフィールドの上位6オクテットにエンコードされなくてはならない(MUST)

    • ローカルディスクリミネータ値(3オクテット)。ローカルディスクリミネータ値が下位3オクテットにエンコードされなくてはならない(MUST)

この仕組みは上記で定義されたユニーク性の要件をESIが満たす場合に使うことができます。

  • Type 4 (T=0x04) - このタイプはルータIDのESI Valueであることを示し、自動生成もしくは運用者による設定が可能です。ESI Valueは次のように生成されます。

    • ルータID(4オクテット)。システムのルータIDがESI Valueフィールドの上位4オクテットにエンコードされなくてはならない(MUST)

    • ローカルディスクリミネータ値(4オクテット)。ローカルディスクリミネータ値がIPアドレスに続いて次の4オクテットにエンコードされなくてはならない(MUST)

  • 下位のオクテットは0x00で埋められるでしょう

この仕組みは上記で定義されたユニーク性の要件をESIが満たす場合に使うことができます。

  • Type 5 (T=0x05) - このタイプは自律システム(AS)ベースのESI Valueであることを示し、自動生成もしくは運用者による設定が可能です。ESI Valueは次のように生成されます。

    • AS番号(4オクテット)。これはシステムが所有しているAS番号でありESI Valueフィールドの上位4オクテットにエンコードされなくてはならない(MUST)。もし2オクテットのAS番号が利用されているときは上位2オクテットは0x0000でしょう。

    • ローカルディスクリミネータ値(4オクテット)。ローカルディスクリミネータ値がAS番号に続いて次の4オクテットにエンコードされなくてはならない(MUST)

  • 下位のオクテットは0x00で埋められるでしょう

この仕組みは上記で定義されたユニーク性の要件をESIが満たす場合に使うことができます。

6. イーサネットタグID

イーサネットタグIDは32ビットのフィールドで、EVPNインスタンス内のブロードキャストドメイン(VLANなど)を識別するための12ビットまたは24ビットの識別子を含んでいます。12ビットの識別子はVLAN ID (VID)と呼ばれます。 ネットワーク内の標準化されたIDでBDを表します。0でない32ビットの識別子で、VLAN-aware BundleサービスのEVPN経路でも使用されます。EVPNインスタンスは1つ以上のブロードキャストドメイン(VLAN)BD(イーサネットタグ)で構成されています。EVPNサービスの提供者によってVLAN イーサネットタグIDはあるEVPNインスタンスに割り当てられます。VLAN イーサネットタグIDは複数のVIDで表現される場合もあります。このようなケースでは、EVPNインスタンスにおいてそのVLAN BDに属するPEは、ローカルに接続されたCEとの間でVLAN IDの変換を行う責任があります。すなわちPEはローカルのVIDを標準化されたイーサネットタグIDに変換する責任を持ちます。

EVPNインスタンスのためのVLANに属するすべてのPEの間で、そのVLANが単一のVIDで表現される場合、VID VLANの変換をPEで行う必要はありません。その上、デプロイシナリオによってはすべてのEVPNインスタンスにまたがってVIDのユニーク性が保証されている、つまり、あるEVPNインスタンスに対してすべての接続点において同じVIDが利用され、他のEVPNインスタンスがそのVIDを利用することがないことが保証されていることがあります。この場合それぞれのEVPNインスタンスに対するRTは対応するVIDから自動的に決定することが出来ます。これについては7.10.1節 7.11.1節で説明します。

以降の小節ではブロードキャストドメイン(VLAN)、イーサネットタグID(VID)、MAC-VRFの関係、そしてイーネットタグIDがRFC7209に記載されている異なるタイプのサービスインターフェイスに対して、たくさんの種類のEVPN BGP経路の中にどのように設定されるのかを考察します。

次のイーサネットタグIDは予約されています

6.1. VLAN-Based サービスインターフェイス

このサービスインターフェイスでは、EVPNインスタンスは単一のブロードキャストドメイン(単一のVLAN)だけで構成されています。そのためVIDとMAC-VRFは一対一でマッピングされます。MAC-VRFは単一のVLANに対応するため、MAC-VRFはそのVLANに対応する単一のブリッジテーブルで構成されます。もしVLANが複数のVIDで表現される場合(PEとイーサネットセグメントごとに異なるVIDを使う場合)、PEは宛先のイーサネットセグメントごとにフレームのVID変換を行う必要があります。このようなシナリオでは、MPLS/IPネットワーク上で転送されるイーサネットフレームは元のVIDでtaggedにされているべきです(SHOULD)。VID変換はデータパス上でサポートされていなければならず(MUST)、disposition PEで実行されなくてはなりません(MUST)。すべてのEVPN経路におけるイーサネットタグIDは0に設定しなければなりません(MUST)。

6.2. VLAN Bundleサービスインターフェイス

このサービスインターフェイスでは、EVPNインスタンスは複数のブロードキャストドメイン(複数のVLAN)で構成されます。しかしブリッジテーブルはMAC-VRFごとに1つだけが維持されます。つまり複数のVLANが同じブリッジドメインテーブルを共有するということです。これは暗黙的に、このサービスを動作させるにMACアドレスはEVIのすべてのVLANにまたがってユニークでなくてはならない(MUST)ということです。言い換えればLANとMAC-VRFは多対一でマッピングされ、MAC-VRFは単一のブリッジテーブルで構成されるということです。さらに単一のVLANは単一のVIDで表現されなくてはなりません。つまりこのサービスインターフェイスタイプではVLAN変換は行えません。MPLSでカプセル化されたフレームは元のVIDでtaggedのままにされてなくてはなりません(MUST)。タグの変換は禁止されています。すべてのEVPN経路におけるイーサネットタグIDは0に設定しなければなりません(MUST)。

6.2.1. Port-Based サービスインターフェイス

このサービスインターフェイスはVLAN Bundleサービスインターフェイスの特別なケースの1つで、ポート上のすべてのVLANが、同一のサービスの一部であり、同じBundleにマップされます。手順は6.2に記載したものと同一です。

6.3. VLAN-Aware Bundleサービスインターフェイス

このサービスインターフェイスでは、EVPNインスタンスは複数のブロードキャストドメイン(複数のVLAN)で構成されており、それぞれのVLANが独自のブリッジテーブルを持っています。つまりEVPNインスタンスに対応する単一のMAC-VRFによって複数のブリッジテーブル(VLANごとに1つ)が維持されています。

ブロードキャスト、unknownユニキャスト、マルチキャスト(BUM)トラフィックは、与えられたブロードキャストドメインに属するCEにのみ送信されます。しかしEVI内部のブロードキャストドメインは、それぞれに固有のPトンネルをもつこともできますし(MAY)、Pトンネルを共有することもできます(MAY)。すなわちあるEVIのすべてのブロードキャストドメインが単一のPトンネルを共有することもできます(MAY)。

単一のVLANが単一のVIDで表現されていて、そのためVID変換が必要とされていない場合、MPLSでカプセル化されたパケットはそのVIDを伝達しなければなりません(MUST)。すべてのEVPN経路におけるイーサネットタグIDはそのVIDに設定されなくてはなりません(MUST)。

経路広告するPEは、EVIだけ(ONLY)を表現しているかもしくはイーサネットタグIDとEVIの両方を表現しているMAC/IP Advertisement経路に乗せてMPLSラベル1を広告することができます(MAY)。どちらを選択するかは経路広告するPE(disposition PEでもある)のローカルの問題であり、その他のPEには影響しません。

単一のVLANが複数の異なるCEで別々のVIDで表現されていて、VID変換が必要とされる場合、標準化されたイーサネットタグID(VID)がEVPN BGP経路で伝達されなくてはなりません(MUST)。それに加えて経路広告するPEは、イーサネットタグIDとEVIの両方を表現するMAC/IP Advertisement経路に乗せてMPLSラベル1を広告します。これによりMPLSでカプセル化されたパケットを受信した時に、対応するブリッジテーブルをMPLS EVPNラベルから識別することが可能になり、イーサネットタグIDの変換をdisposition PEのみ(ONLY)で行うことができるようになります。すなわち、MPLS/IPネットワーク上で転送されたイーサネットフレームは、元のVIDでtaggedのままにされていなければならず(MUST)、VID変換はdisposition PEで行わなれるということです。EVPN経路におけるイーサネットタグIDは標準化されたイーサネットタグIDが設定されていなければならず、このIDはEVPNプロバイダーによって割り当てられなければなりません(MUST)。

6.3.1. Port-Based VLAN-Aware サービスインターフェイス

このサービスインターフェイスはVLAN-Aware Bundleサービスインターフェイスの特別なケースの1つで、あるポートの全てのVLANが、同じサービスに所属していて、単一のBundleにマップされますが、VIDの変換が全く行われないというものです。手順は6.3節で記述したものの一部です。

6.4 EVPN PEモデル

この文書ではMAC-VRF、EVI、ブリッジドメイン(BD)、ブリッジテーブル(BT)との関係性においてEVPNの運用を議論するため、これらの用語の間の関連性を理解することは重要です。そのため、これらの関係性をPEモデルとして描きます。

         +--------------------------------------------------+
         |                                                  |
         |              +------------------+        EVPN PE |
         | Attachment   | +------------------+              |
         | Circuit(AC1) | |  +----------+    |       MPLS/NVO tnl
       ----------------------*Bridge    |    |              +-----
         |              | |  |Table(BT1)|    |             / \    \
         |              | |  |          |<------------------> |Eth|
         |              | |  |  VLAN x  |    |             \ /    /
         |              | |  +----------+    |              +-----
         |              | |     ...          |                |
         |              | |  +----------+    |         MPLS/NVO tnl
         |              | |  |Bridge    |    |               +-----
         |              | |  |Table(BT2)|    |              / \    \
         |              | |  |          |<-------------------> |Eth|
       ----------------------*  VLAN y  |    |              \ /    /
         |  AC2         | |  +----------+    |               +-----
         |              | |    MAC-VRF1      |               |
         |              +-+    RD1/RT1       |               |
         |                +------------------+               |
         |                                                   |
         |                                                   |
         +---------------------------------------------------+

図1: EVPN PEモデル

PEでEVPNサービスインスタンス(すなわちEVI)のために設定されたテナントは、そのPEにおいて単一のMAC Virtual Routing and Forwarding (MAC-VRF)によってインスタンス化されます。MAC-VRFは一つ以上のブリッジテーブル(BT)で構成されています。それぞれのBTはVLAN(ブロードキャストドメイン, BD)に対応しています。EVPN PEのサービスインターフェイスがVLAN-Basedモード(6.1節)で設定されている場合は、(EVIごとの)MAC-VRFごとに単一のBTが存在します。つまりEVIごとに一つのテナントVLANだけが存在できます。しかしEVPN PEのサービスインターフェイスがVLAN-Aware Bundleモード(6.3節)で設定されている場合は、(EVIごとの)MAC-VRFごとに複数のBTが存在します。つまりEVIごとに複数のテナントVLANが存在します。これらの用語の間の関係性は次のように要約できます:

  • EVIは一つ以上のBDで構成することができます。さらにMAC-VRFは一つ以上のBTで構成することができます。BDはイーサネットタグIDで識別され、イーサネットタグIDは典型的には単一のVLAN ID(VID)によって表されます。しかし、複数のVID(802.1QのShared VLAN Learning(SVL)モード)によって表すこともできます。

  • VLAN-BasedモードではVLANごとに1つのEVIが存在し、それはすなわち、VLANごとに1つのBD/BTが存在します。

  • VLAN Bundleサービスでは、802.1QのSVLモードのように考えることができます。つまり、EVIごとに1つのBDとMAC-VRFごとに1つのBTがあり、複数のVIDがこのBDを表します。

  • VLAN-aware Bundleサービスでは、1つのEVIに複数のBDが存在し、それぞれのBDがVLANで表されます。さらに複数のBTが単一のMAC-VRFに存在します。

単一のテナントサブネットは典型的には(そしてこの文書では)1つのVLANで表される(つまり単一のBTでサポートされる)ので、与えられたテナントに対して上記のPEモデルに示されたように、サブネットと同じ数だけのBTが存在することになります。

MAC-VRFは対応するRoute TargetとRoute Distinguisherによって識別されます。EVPN VLAN-Basedモードで動作している場合は、MAC-VRFのRoute TargetのついたEVPN経路を受信したPEは、対応するBTを識別することができます。しかしEVPN VLAN-Aware Bundleで動作している場合は、対応するBTを識別するためにMAC-VRFのRoute TargettVLAN IDの両方が必要となります。

7. BGP EVPN経路

この文書はEVPN NLRIと呼ばれる新しいBGPネットワーク到達性情報(NLRI)を定義します。

EVPN NLRIのフォーマットは以下のとおりです。

                 +-----------------------------------+
                 |    Route Type (1 octet)           |
                 +-----------------------------------+
                 |     Length (1 octet)              |
                 +-----------------------------------+
                 | Route Type specific (variable)    |
                 +-----------------------------------+

Route TypeフィールドはEVPN NLRIの残りの部分(Route Type specificフィールド)のエンコーディングを決めるためのものです。

LengthフィールドはEVPN NLRIのRoute Type specificのフィールドの長さをオクテットで指定するものです。

この文書では次のRoute Typeを定義します。

これらの経路タイプに対する詳細なエンコーディングと手順はこのあとの節で説明します。

EVPN NLRIはBGPマルチプロトコル拡張(RFC4760)を用いて、アドレスファミリー識別子(AFI) 25 (L2VPN) と後続アドレスファミリー識別子(SAFI) 70 (EVPN)としてBGP(RFC4271)で伝達されます。MP_REACH_NLRI/MP_UNREACH_NLRI属性のNRLIフィールドにEVPN NLRIが含まれます(上記で記したとおりにエンコードされます)。

2つのBGPスピーカがラベルの付いたEVPN NLRIを交換するために、BGP Capabilities Advertisementをを使い、両者がこのNLRIを適切に処理できるかどうかを確認する必要があります。これはRFC4760で定義されたとおりに実行され、capabilityコード1 (マルチプロトコルBGP)のAFI 25(L2VPN)、SAFI 70(EVPN)を使用します。

7.1. Ethernet Auto-discovery経路

Etherenet A-D経路タイプのEVPN NLRIは次のように構成されています:

                +---------------------------------------+
                |  Route Distinguisher (RD) (8 octets)  |
                +---------------------------------------+
                |Ethernet Segment Identifier (10 octets)|
                +---------------------------------------+
                |  Ethernet Tag ID (4 octets)           |
                +---------------------------------------+
                |  MPLS Label (3 octets)                |
                +---------------------------------------+

BGP経路キー処理のため、Ethernet Segment Identifier(イーサネットセグメント識別子)とEthernet Tag ID(イーサネットタグID)のみがNLRIのプレフィックス部として使用されます。MPLS Labelフィールドは経路の一部でではなく経路属性として扱われます。

MPLS Labelフィールドは3オクテットでエンコードされ、上位の20ビットにラベル値を含んでいます。

この経路の処理手順と使用方法は8.2節の「高速収束」と8.4節の「エイリアシングとバックアップパス」を参照してください。

7.2. MAC/IP Advertisement経路

MAC/IP Advertisement経路タイプのEVPN NLRIは次のように構成されています:

                +---------------------------------------+
                |  RD (8 octets)                        |
                +---------------------------------------+
                |Ethernet Segment Identifier (10 octets)|
                +---------------------------------------+
                |  Ethernet Tag ID (4 octets)           |
                +---------------------------------------+
                |  MAC Address Length (1 octet)         |
                +---------------------------------------+
                |  MAC Address (6 octets)               |
                +---------------------------------------+
                |  IP Address Length (1 octet)          |
                +---------------------------------------+
                |  IP Address (0, 4, or 16 octets)      |
                +---------------------------------------+
                |  MPLS Label1 (3 octets)               |
                +---------------------------------------+
                |  MPLS Label2 (0 or 3 octets)          |
                +---------------------------------------+

BGP経路キー処理のため、Ethernet Tag ID(イーサネットタグID)、MAC Address Length(MACアドレス長)、MAC Address(MACアドレス)、IP Address Length(IPアドレス長)、IP Address(IPアドレス)フィールドがNLRIのプレフィックス部として使用されます。Ethernet Segment Identifier(イーサネットセグメント識別子)、MPLS Label1(MPLSラベル1)、MPLS Label2(MPLSラベル2)フィールドは経路の一部ではなく経路属性として扱われます。IPアドレス長とMACアドレス長はビット単位です。

MPLS Label1フィールドとMPLS Label 2フィールドは3オクテットでエンコードされ、上位の20ビットにラベル値を含んでいます。

この経路の処理手順と使用方法は9節の「ユニキャストMACアドレスへの到達性の決定」と14節の「ユニキャストパケットのロードバランス」を参照してください。

7.3. Inclusive Multicast Ethernet Tag経路

Inclusive Multicast Ethernet Tag経路タイプのEVPN NLRIは次のように構成されています:

               +---------------------------------------+
               |  RD (8 octets)                        |
               +---------------------------------------+
               |  Ethernet Tag ID (4 octets)           |
               +---------------------------------------+
               |  IP Address Length (1 octet)          |
               +---------------------------------------+
               |  Originating Router's IP Address      |
               |          (4 or 16 octets)             |
               +---------------------------------------+

この経路の処理手順と使用方法は11節の「複数宛先トラフィックの処理」と12節の「Unknownユニキャストパケットの処理」と16節の「マルチキャストとブロードキャスト」を参照してください。IPアドレス長はビット単位です。BGP経路キー処理のため、Ethernet Tag ID(イーサネットタグID)、IP Address Length(IPアドレス長)、 Originating Router's IP Address(生成元ルータIPアドレス)フィールドだけがNLRIのプレフィックス部として使用されます。

7.4. Ethernet Segment経路

Ethernet Segment経路タイプのEVPN NLRIは次のように構成されています:

               +---------------------------------------+
               |  RD (8 octets)                        |
               +---------------------------------------+
               |Ethernet Segment Identifier (10 octets)|
               +---------------------------------------+
               |  IP Address Length (1 octet)          |
               +---------------------------------------+
               |  Originating Router's IP Address      |
               |          (4 or 16 octets)             |
               +---------------------------------------+

この経路の処理手順と使用方法は8.5節の「Designated Forwarder選出」を参照してください。IPアドレス長はビット単位です。BGP経路キー処理のため、Ethernet Segment ID(イーサネットセグメントID)、IP Address Length(IPアドレス長)、Originating Router's IP Address(生成元ルータIPアドレス)フィールドだけがNLRIのプレフィックス部として使用されます。

7.5. ESIラベル拡張コミュニティ

この拡張コミュニティはTypeフィールドが0x06でSub-Typeが0x01の新しいtransitive拡張コミュニティです。これはEthernet Auto-discovery経路とともに広告され、8.3節「スプリットホライズン」に記載されているようにマルチホームサイトのためのスプリットホライズンの手順を可能にするものです。ESI Labelフィールドは広告元のPEのESを表し、同じマルチホームのイーサネットセグメントに所属している他のPEがスプリットホライズンのフィルタリングのために使用するものです。

ESI Labelフィールドは3オクテットでエンコードされ、上位の20ビットにラベル値を含んでいます。

イーサネットセグメントのいずのVLANにおいてもスプリットホライズン・フィルタリングの手順が必要でない場合はESIラベルの値をゼロとすることができます(MAY)。これはRFC8214の場合やイーサネットセグメントがietf-bess-evpn-mh-split-horizonのローカルバイアスの手順を使用する場合です。

それぞれのESIラベル拡張コミュニティは8オクテットの値として次のようにエンコードされます:

    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=0x01 | Flags(1 octet)|  Reserved=0   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Reserved=0   |          ESI Label                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flagオクテットの下位ビットは "Single-Active" ビットとして定義されています。0の場合そのマルチホームサイトがAll-Active冗長モードで運用されていることを示します。1の場合はそのマルチホームサイトがSingle-Active冗長モードで運用されていることを示します。

7.6. ES-Import Route Target

こては新しいtransitive Route Target拡張コミュニティで、Ethernet Segment経路とともに伝達されます。このコミュニティが使用されるとき、同じマルチホームサイトに接続されたすべてのPEはEthernet Segment経路をインポートできるようになります。その値はESI Type 1, 2, 3に対しては自動的に設定されます。9オクテットのESI Valueのうち上位6オクテットの位置、つまりMACアドレスに対応する部分をESI-Import Route Targetにエンコードします。この拡張コミュニティのフォーマットは次のとおりです:

     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=0x02 |          ES-Import            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ES-Import Cont'd                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

この文章はRoute Target拡張コミュニティの定義を拡張して、上位オクテット(Typeフィールド)の値に0x06を設定できるようにします(他の値はRFC4360を参照)。下位オクテット(Sub-Typeフィールド)の値0x02はこの拡張コミュニティが「Route Target」タイプであることを示しています。この新しいTypeフィールドの0x06という値は、このRTの構造がMACアドレスなどの6オクテットの値であることを示しています。RT Constraint(RFC4684)を実装しているBGPスピーカはこのES-Import RTに対しても同様にRT Constraintの手順を適用しなければなりません(MUST)。

この属性の処理手順と使用方法については8.1節の「マルチホームされたイーサネットセグメントの自動発見」を参照してください。

7.7. MACモビリティ拡張コミュニティ

この拡張コミュニティは新しいtransitive拡張コミュニティでTypeフィールドの値が0x06、Sub-Typeフィールドの値が0x00です。このコミュニティはMAC/IP Advertisement経路とともに広告することができます。この拡張コミュニティを使用する手順は15節の「MACモビリティ」に記載されています。

MACモビリティ拡張コミュニティは8オクテットの値として次のようにエンコードされます。

     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=0x00 |Flags(1 octet)|  Reserved=0    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flagオクテットの下位ビットは Sticky/static フラグであり1に設定されることがあります。1の場合はMACアドレスがstaticであり、移動できないことを意味しています。シーケンス番号は、同じMACアドレスに対して複数回のアップデートが行われた時にPEが正しいMAC/IP Advertisement経路を維持することが出来るようにするために使われます。

7.8. デフォルトゲートウェイ拡張コミュニティ

デフォルトゲートウェイ拡張コミュニティは透過型(RFC4360の3.3節)の拡張コミュニティです。transitiveコミュニティであるため、最初のオクテットは0x03です。二番目のオクテット(Sub-Type)は0x0d (デフォルトゲートウェイ)で、IANAから割り当てられているとおりです。このコミュニティのValueフィールドは予約されています(送信者により0に設定され、受信者が無視します)。この属性の処理手順と使用方法は10.1節の「デフォルトゲートウェイ」を参照してください。

7.9 EVPNレイヤー2属性拡張コミュニティ

RFC8214ではこの拡張コミュニティ(「L2-Attr」)はEthernet A-D per EVI経路に含められ、マルチホーミングが有効である場合は必須であると定義されています。。

ブリッジングへのこの拡張コミュニティの使い方と適用性をここで明記します。

                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |   MBZ         |RSV|RSV|F|C|P|B|  (MBZ = MUST Be Zero)
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Control Flagsのビットは次の定義されたビットで拡張されます:

       名前      意味
       ---------------------------------------------------------------
       F        1に設定された場合、このPEにEVPNパケットを送信するときにはFlow 
                Labelが存在しなければなりません(MUST)

Control WordとFlow Labelに関するこの属性の手順や使用方法については18節「フレームの順序制御」を参照してください。

Primary-Backupビットに関するこの属性の手順や使用方法については8.5節「Designated Forwarder選出」を参照してください。

7.9.1. EVPNレイヤー2属性の分割

L2-Attr拡張コミュニティで運ばれる情報にはESI固有のものとBD/MAC-VRF固有のものがあります。MTUのような実行時に障害起因で変更されるようなものではない、設定時の項目の処理オーバーヘッドを最小化するために、RFC8214のこの拡張コミュニティは分割され、Ethernet A-D per EVI経路とInclusive Multicast経路で伝達される情報はその一部だけとなります。

Inclusive Multicast経路に使用されるEVPN Layer 2属性拡張コミュニティは:

  • BD/MAC-VRF属性のMTU、Control Word、Flow Labelが伝達され、

  • ESIごとの属性のP, Bがゼロでなくてはなりません(MUST)

       +-------------------------------------------+
       | Type (0x06) / Sub-type (0x04) (2 octets)  |
       +-------------------------------------------+
       | Control Flags (2 octets)                  |
       +-------------------------------------------+
       | L2 MTU (2 octets)                         |
       +-------------------------------------------+
       | Reserved (2 octets)                       |
       +-------------------------------------------+

                              1 1 1 1 1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | MBZ           |  MBZ  |F|C|MBZ|    (MBZ = MUST Be Zero)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ethernet A-D per EVI経路に使用されるEVPN Layer 2属性拡張コミュニティは:

  • ESIごとの属性のO, Bが伝達され、

  • BD/MAC-VRF属性のMTU、Control Word、Flow Labelはゼロでなければなりません(MUST)。

       +-------------------------------------------+
       | Type (0x06) / Sub-type (0x04) (2 octets)  |
       +-------------------------------------------+
       | Control Flags (2 octets)                  |
       +-------------------------------------------+
       | MBZ (2 octets)                            |
       +-------------------------------------------+
       | Reserved (2 octets)                       |
       +-------------------------------------------+

                              1 1 1 1 1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | MBZ           |    MBZ    |P|B|    (MBZ = MUST Be Zero)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

上記の両方の場合において、この拡張コミュニティによって伝達される値は個々のEVI(VLAN-aware Bundleの 場合は<EVI, VLAN>)の粒度であり、異なるEVIによっては異なる値になりえることに留意してください。

7.9.7.10. MAC-VRFごとのRoute Distinguisherの割当方法

Route Distinguisher (RD)はNLRIを広告しているMAC-VRFのRDが設定されなくてはなりません(MUST)。RDはPEの与えられたMAC-VRFに対して割り当てられなくてはなりません(MUST)。このRTはPEのすべてのMAC-VRFにまたがってユニークでなければなりません(MUST)。Type 1 RD(RF4364)を使用することが推奨されます(RECOMMENDED)。ValueフィールドはPEのIPアドレス(典型的にはループバックアドレス)とそれに続いてPE内部でユニークな番号によって構成されます。この番号はPEによって生成することができます。VLAN-basedsサービスまたはVLAN Bundlesアービスの場合、この番号は、16ビットの長さを超えない値である限り、そのBDに対するイーサネットタグIDからも生成することができます。ユニークVLAN EVPNのケースでは下位12ビットが12ビットのVLAN IDで、残りの上位4ビットを0に設定することができます。

7.10. 7.11. Route Targets

EVPN経路は1つ以上のRoute Target(RT)属性を伝達することができます(MAY)。RTはIP VPNのように設定することもできますし、自動的に計算することもできます。

もしPEがRT Constraintを使用する場合、PEはRFC4684に従ってRT Constraintを使ってそのようなすべてのRTを広告します。RT Constraintを使用することによって、それぞれのEVPN経路が、その経路で伝達される複数のRTの中から少なくとも1つのRTでインポートするように設定したPEだけに届けられることが可能になります。

7.10.1. 7.11.1 イーサネットタグIDからの自動設定

「ユニークVLAN EVPN」のシナリオではEVPNインスタンスに対してイーサネットタグIDの(VLAN ID)から自動的にRTを設定することが望ましいです。このような自動設定を行うための手順は以下のとおりです:

  • RTのGlobal AdministratorフィールドはPEに関連付けられたAS番号を設定しなければならない(MUST)

  • 12ビットVLAN IDはLocal Administratorフィールドの下位12ビットに設定し、残りのビットは0に設定しなければならない(MUST)

7.12. 経路の優先度付け

8.2節の「高速収束」で参照されている高速収束を達成するために、BGPスピーカは、相対的な優先度のスケールと予測される平均のスケールの対比に基づいて、経路の広告・処理・再配布を優先度付けするべきです(SHOULD)。

  1. Ethernet A-D per ES経路(Mass Withdrawal, Route Type 1)とEthernet Segment経路(Route Type 4)はスケールが小さく、収束に大きく影響します。そのため一番の優先度で処理されるべきです(SHOULD)。

  2. Ethernet A-D per EVI経路とInclusive Multicast Ethetnet Tag経路とietf-bess-evpn-prefix-advertisementで定義されているIP Prefix経路はブリッジまたはACごとに中程度のスケールで送信されるものであり、収束に影響することがあるため、二番目の優先度で処理されるべきです(SHOULD)。

MAC Advertisement経路(IP部分がゼロでも非ゼロでも)と、ietf-bess-evpn-igmp-mld-proxyで定義されているMulticast Join Sync経路とMulticast Leave Sync経路は「個別の経路」として考えられ、スケールが非常に大きく、高速収束に対しては優先度が低いものなので、最低の優先度で処理されるべきです(SHOULD)。

8. マルチホーミング機能

この節ではEVPNでマルチホーミングをサポートするために使用される機能、処理手順、そして関連するBGP経路につて考察します。ここではマルチホームされたデバイスとマルチホームされたネットワークの両方のシナリオについて扱います。

8.1. マルチホームされたイーサネットセグメントの自動発見

同じイーサネットセグメントに接続されたPEは、Ethernet Segment経路を交換することによって最小限の設定もしくは設定無しで、お互いを自動的に発見することができます。

8.1.1 Ethernet Segment経路の生成

Route Distinguisher (RD)はType 1 RD(RFC4364)でなければなりません(MUST)。ValueフィールドはPEのIPアドレス(典型的にはループバックアドレス)とそれに続いてPE内部でユニークな番号によって構成されます。

イーサネットセグメント識別子(ESI)は5節で記載したように10オクテットの値に設定しなければなりません(MUST)。

7.6節で定義したように、Ethernet Segment経路を広告するBGP広告はES-Import Route Targetも含めてなければなりません(MUST)。

Ethernet Segment経路が同じイーサネットセグメントにマルチホームしているPEでのみインポートされるように、Ethernet Segment経路のフィルタリングは行わなければなりません(MUST)。その結果として、特定のイーサネットセグメントに接続されたそれぞれのPEは、ESIから生成されたES-Import Route Targetを含む経路をインポートするようにインポートフィルタのルールを作成します。

8.2. 高速収束

EVPNにおいてMACアドレス到達性はMPLSネットワーク越しにBGPのコントロールプレーンによって学習されます。このとき高速な保護の仕組みが1つもない状況ではネットワークの収束時間は障害が発生したPEによってwithdrawされなければならないMAC/IP Advertisement経路数の関数になります。これでは巨大なスケール環境で収束の遅延を引き起こしてしまいます。

この問題を緩和するために、EVPNでは、あるイーサネットセグメントへの接続性に障害が発生した場合にフォワーディングテーブルを更新しなければならない対向のPEノードに対して、効率的かつ迅速にシグナルを送る仕組みを定義します。それぞれのPEがローカルに接続されたそれぞれのイーサネットセグメントについて、Ethernet A-D per ES経路(これらの経路をどのように構築するかは次の8.2.1節を参照)を1つ以上広告することで実現されます。PEは与えられたESについてEthernet A-D per ES経路を2つ以上広告する必要があるかもしれません。なぜならそのESにはEVIの多様性があり、それらすべてのEVIのためのRTは単一の経路では合致しないかもしれないからです。そのESについて一連のEthernet A-D per ES経路を広告することで、それぞれの経路がRTの完全な集合のサブセットを含むことが可能になります。それぞれのEthernet A-D per ES経路は異なるRoute Distinguisher (RD)によって他の経路と区別することができます。

PEに接続されたセグメントへの接続性に障害が発生した時に、PEはそのセグメントに対応するEthernet A-D per ES経路をwithdrawします。これによってwithdrawを受信したすべてのPEは当該のイーサネットセグメントに関連するすべてのMACアドレスネクストホップ隣接性を更新することになります。もし他のPEがそのセグメントのEthernet A-D経路を広告していない場合、withdrawを受信したPEは単にそのセグメントのMACアドレスをInvalidにすればよいです。そうでなければPEは適切にネクストホップ隣接性を更新します。

8.2.1. Etherenet A-D per ES経路の構築方法

この節ではEtherenet A-D per ES経路を構築するために使われる手順について記述します。この経路は上記で考察した高速収束や8.3節で考察するスプリットホライズンのフィルタリングに使われるESIラベルの広告に使われます。この経路のサポートは必須です(REQUIRED)。

Route Distinguisher (RD)はType 1 RD(RFC4364)でなければなりません(MUST)。ValueフィールドはPEのIPアドレス(典型的にはループバックアドレス)とそれに続いてPE内部でユニークな番号によって構成されます。

イーサネットセグメント識別子(ESI)は5節で記載したように10オクテットの値に設定しなければなりません(MUST)。ESIが0に設定されているとき(シングルホームのシナリオ)、Ethernet A-D経路は必要にはなりません。この規則に対する例外はRFC8317で述べられています。

イーサネットタグIDはMAX-ETに設定しなければなりません(MUST)。

NLRIのMPLSラベルは0に設定しなければなりません(MSUT)。

この経路にはESIラベル拡張コミュニティを含めなければなりません(MUST)。もしAll-Active冗長モードにしたい場合、ESIラベル拡張コミュニティのフラグにあるSingle-Activeビットは0に設定しなければならず(MUST)、この拡張コミュニティのMPLSラベルは有効なMPLSラベル値に設定しなければなりません(MUST)。この拡張コミュニティのMPLSラベルはESIラベルとして参照され、それぞれのESのために広告されるEthernet A-D per ES経路と同じ値でなくてはなりません。経路広告するPEが他のPEからのマルチキャスト、ブロードキャスト、unknownユニキャストを受信するためにIngress Replicationを使う場合、このラベルはdownstreamで割り当てたMPLSラベルをつかわなくてはなりません(MUST)。経路広告するPEがマルチキャスト、ブロードキャスト、unknownユニキャストを送信するためにP2MP MPLS LSPを使用する場合は、このラベルはDCBで割り振られたラベルが使用されていない限り、upstreamでアサインされたMPLSラベルを使用しなくてはなりません(MUST)。このラベルの使用方法は8.3節に記載します。

Single-Active冗長モードにしたい場合は、ESIラベル拡張コミュニティのフラグにあるSingle-Activeビットは1に設定しなければならず、ESIラベルは有効なMPLSラベルの値に設定されるべきです(SHOULD)。

8.2.1.1. Ethernet A-D経路のターゲット

それぞれのEthernet A-D per ES経路には1つ以上のRoute Target(RT)属性が含まれていなければなりません(MUST)。あるイーサネットセグメントについて、所属するすべてのEVPNインスタンスのすべてのRTを、Ethernet A-D per ES経路全体ですべて含められるようにしなければなりません(MUST)。

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

あるイーサネットセグメントES1で2つ以上のPEにマルチホームをしてAll-Active冗長モードで運用されているCEについて考えます。もしCEがブロードキャスト、unknownユニキャスト、マルチキャスト(BUM)パケットをDesignated Forwarderでない(non-DF) PE (PE1とする)に対して送ると、PE1はそのパケットをEVPNインスタンス内のすべてのPEまたは一部に対してパケットを転送することになるでしょう。そこに該当のイーサネットセグメントのDF PEも含まれるでしょう。この場合、CEがマルチホームしているDF PEはそのパケットを破棄し、CEに対して送り返さないようにしなければなりません(MUST)。このフィルタリングをこの文書では「スプリットホライズン・フィルタリング」と呼びます。

あるPEの集合がSingle−Active冗長モードで運用されているとき、このスプリットホライズン・フィルタリングを使うことが強く推奨されます。なぜならそのイーサネットセグメントに影響を与える障害やそこからの回復が起きた時に発生する一時的なループを防ぐことができるからです。例えばDF選出手順が完了する前に2つのPEの両方がDFとして動作する場合などです。

このスプリットホライズンの機能を実現するために、non-DF PEから生成されたそれぞれのBUMパケットはカプセル化される際に、生成元のイーサネットセグメント(そのフレームがEVPNネットワークに入ってくるセグメント)を識別するためのMPLSラベルを付与します。このラベルをESIラベルと呼びます。All−Active冗長モードで運用されているすべてのPEはEthernet A−D per ES経路で8.2.1節に従って配布されなければなりません(MUST)。このESIラベルはPEがSingle-Active冗長モードで運用されているときも、Ethernet A−D per ES経路で配布されるべきです(SHOULD)。これらの経路はそのイーサネットセグメントに接続しているPEでインポートされます。また、経路中のイーサネットセグメントに共通なEVPNインスタンスを少なくとも1つもっているPEでもインポートされます。8.1.1節に記載したとおり、この経路には有効なESIラベルを設定したESIラベル拡張コミュニティを付与しなければなりません(MUST)。dispositon PEは特定のイーサネットセグメントに対してBUMトラフィックを転送してもよいかどうかをこのESIラベルに基づいて判断します。

8.3.1. ESIラベルの割り当て

以下の小節ではESIラベルの割り当て手順について記述します。このラベルの割り当て手順は複数宛先パケットをEVPNネットワークで運ぶためのトンネルの方式によって異なります。

8.3.1.1. Ingress Replication

All−ActiveまたはSingle−Active冗長モードで動作していて、BUMトラフィックの受信にIngress Replicationを使用するそれぞれのPEは、接続されたESのためにdownstreamで割り当てられたESIラベルを一連のEthernet A−D per ES経路に含めて広告します。このラベルは経路広告するPEによってプラットフォームのラベル空間の中でプログラムされなくれはなりません(MUST)。そしてこのラベルの転送エントリーでは、このラベルが付いたパケットを受信した時に配布されたラベルのイーサネットセグメント上に転送してはいけません。

All−Active冗長モードで動作しているIngress PEが、BUMパケット内にESIラベルを含めるためのルールは次のとおりです。

  • non-DF Ingress PEはBUMパケットをコピーして転送する際にはDF Egress PEが配布したESIラベルを含めなければなりません(MUST)。

  • Ingress PE (DFでもnon-DFでも)はBUMパケットをコピーして転送する際にはそれぞれのnon-DF Egress PEが配布したESIラベルを含めるべきです(SHOULD)。

Single−Active冗長モードで動作しているIngress PEが、BUMパケット内にESIラベルを含めるためのルールは次のとおりです。

  • Ingress DF PEはBUMパケットをコピーして転送する際にはEgress PEが配布したESIラベルを含めるべきです(SHOULD)。

All−Active冗長モードでもSingle−Active冗長モードでも、Ingress PEは、BUMパケットがEVIに流入する際に通過するESに接続されていないEgress PEに対して転送されるBUMパケットのコピーにはESIラベルを含めてはなりません(MUST NOT)。

例としてCEがES1でPE1とPE2にAll-Active冗長モードでマルチホームしている状況を考えます。PE1はPE2にP2PもしくはMP2PのLSPでパケットを転送するものとします。PE1がVLAN1のnon-DF、PE2がVLAN1のDFであるときに、PE1がCE1からES1のVLAN1でBUMパケットを受信したとします。このときPE2はEVPNインスタンスに対応するVLAN1のためのInclusive Multicast Ethernet Tag経路を広告します。このときPE2がES1に対して配布したESIラベルがMPLSラベルスタックに最初にPushされるのは、PE1がCE1から受信したBUMパケットを送信するときでなければなりません(MUST)。そしてVLAN1に対するnclusive Multicast Ethernet Tag経路に含まれてPE2によって配布されたMPLSラベルがMPLSラベルスタックにPushされなければなりません(MUST)。このパケットはさらに、PE2に転送するために必要なP2PまたはMP2P LSPラベルスタックによってカプセル化されます。PE2がこのパケットを受信したとき、topのMPLSラベルからは、P2PまたはMP2P LSPラベルがpopされた後にパケットが複製されるESIの集合を決定します。次のラベルがES1のためにPE2によってアサインされたESIラベルである場合、PE2はこのパケットをES1に転送してはいけません(MUST NOT)。もし次のラベルがPE2によってアサインされたラベルではないESIラベルであった場合、PE2はそのパケットを破棄しなくてはなりません(MUST)。このシナリオでは、もしPE2がCE1からVLAN1のBUMパケットを受信した場合。そのパケットをPE1から受信したESIラベルでカプセル化し、PE1に対して送信するべきで(SHOULD)あることを述べておくべきでしょう。これはES1に影響を与えるような障害(ポートやリンクの障害)の間起こる一時的なループを避けるためです。

8.3.1.2. P2MP MPLS LSP

All−Active冗長モードで運用されていて、P2MP LSPをBUMトラフィックの送信に使うnon−DF PEは、upstreamで割り当てられたESIラベルを共通の接続されたESIに対する一連のEthernet A−D per ES経路に含めて広告します。このラベルは経路を広告するPEによってupstreamで割り当てられるものです。経路広告するPEのためのラベル空間という文脈において、このラベルは経路で広告されているESIに接続されている他のPEによってプログラムされたものでなければなりません(MUST)。そしてこのラベルの転送エントリーでは、このラベルが付いたパケットを受信した時に配布されたラベルのイーサネットセグメント上に転送してはいけません。経路広告するPEのためのラベル空間という文脈において、このラベルは経路をインポートするが、経路で広告されているイーサネットセグメントに接続されていない他のPEによってもプログラムされなければなりません(MUST)。さらにこのラベルの転送エントリーは他のアクションに関連しないラベルのpopです。

Single-Active冗長モードで運用されていて、P2MP LSPをBUMトラフィックの送信に使うDF PEは、前の段落で記述したように、接続しているESのための一連のEthernnet A−D per ES経路にupstreamで割り当てられたESIラベルを含めて広告するべきです。

例としてCEがES1でPE1とPE2にAll-Active冗長モードでマルチホームしている状況を考えます。PE3がES1のEVPNインスタンスの1つに所属しているとします。さらにPEがnon-DFであり、P2MP MPLS LSPを使ってBUMパケットを送信するとします。PE1がCE1から受信したBUMパケットを送信するとき、そのパケットを受信したESIに対して割り当てられたESIラベルをMPLSラベルスタックに対してまずpushしなければなりません(MUST)。最終的なパケットは他のPEに転送するのに必要なP2MP MPLSラベルスタックによってさらにカプセル化されます。EVPNのためのMPLS基盤において使われるP2MP LSPにおいてはPenultimate hop poppingは無効化されていなくてはなりません(MUST)。PE2がこのパケットを受信したとき、トップのMPLSラベルを取り外し、トップのラベルによって決定されるコンテクストラベル空間を使ってパケットを転送します。次のラベルがPE1によってES1に割り当てられたESIラベルであるとき、PE2はそのパケットをES1に転送してはなりません(MUST)。PE3がこのパケットを受信したとき、トップのMPLSラベルを取り外し、トップのラベルによって決定されるコンテクストラベル空間を使ってパケットを転送します。次のラベルがPE1によってES1に割り当てられたESIラベルであり、PE3がES1に接続されていない場合、PE3はラベルをpopしてそのEVPNインスタンスにある全てのローカルのESIに対してパケットをフラッディングしなければなりません(MUST)。述べておかなければならないこととして、PE2がBUMフレームをP2MP LSP越しに送信するときに、PE2がそのVLANのDFであったとしてもESIラベルでフレームをカプセル化しておくべきです。これはES1に影響を与えるような障害(ポートやリンクの障害)の間起こる一時的なループを避けるためです。

8.3.1.3. MP2MP MPLS LSP

MP2MPトンネルのための手順は8.3.1.2に従いますが、この節で記述する例外があります。

MP2MPトンネルが使用されるとき、ESIラベルがDCBから割り振られなければならず(MUST)、同じラベルが同じイーサネットセグメントに接続されたすべてのPEで使用されなければなりません。

この方法により、ローカルのイーサネットセグメントを持つ任意のPEは、受信したBUMパケットを送信元のESを識別することができます。

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

CEがリンクアグリゲーショングループ(LAG)を使ってAll-Active冗長で複数のPEにマルチホームしている場合、CEから送信されるトラフィックに関連するMACアドレスを学習するPEがただ1つであるようなケースが起こりえます。この状況においては、マルチホームされたセグメントに複数のPEが接続されているにもかかわらず、リモートPEは1つのPEからしMAC/IP Advertisement経路を受信することができません。その結果、マルチホームされたイーサネットセグメントに接続されたPEに対して、リモートPEが効果的にトラフィックをロードバランスすることができなくなります。このケースに当てはまるものとして例えば、PEがデータプレーン学習を行っていて、CEのロードバランスのハッシュがトラフィックの送信元MACアドレスから行われてしまい、宛先が1つのPEになってしまうものがあります。

これが起きる他の状況として、PEがコントロールプレーン学習(例えばARP)に頼っているときに、ARPトラフィックがLAGの1本のリンクに偏ってしまうような場合が挙げられます。

この問題を解決するために、EVPNでは「エイリアシング」の概念を導入し、あるESのあるEVPNインスタンスにおいてMACアドレスを学習していない場合でも、そのEVI/ESへの到達性があることをPEが伝達することを可能にします。この目的にEthernet A-D per EVI経路が使用されます。リモートPEは、予約されていないESIを持ったMAC/IP Advertisement経路を受信したとき、そのMACアドレスのEVI/ESへの到達性を広告しているすべてのPEからその広告されたMACアドレスに到達可能であるとみなすべきです(SHOULD)。EVI/ESの到達性は、EVI/ES(そしてもし適用可能ならイーサネットタグ)に対するEthernet A-D per EVI経路とESIラベル拡張コミュニティのフラグのSingle-Activeビットが0に設定されたEthernet A-D per ES経路の組み合わせによって表現されます。

リモートPEは一連のEthernet A-D per ES経路を受け取りよりも前にEthernet A-D per EVI経路を受信するかもしれません。そのため、コーナーケースと競合状態を処理するために、一連のEthernet A-D per ES経路の受信が終わるまでの間、リモートPEはEthernet A-D per EVI経路をトラフィックの転送のために使用してはいけません(MUST NOT)。

バックアップパスは密接に関係する機能ですが、Single-Active冗長モードで使われるものです。この場合、あるEVI/ESに到達性があるということを、同様のEthernet A-D per EVI経路とEthernet A-D per ES経路の組み合わせを上記のように使って、PEは広告します。しかしESIラベル拡張コミュニティのフラグのSingle-Activeビットは1に設定されています。予約されていないESIのMAC/IP Advertisement経路を受信したリモートPEは、広告されたMACアドレスが、このEthernet A-D経路の組み合わせを広告しているいずれのPEからでも到達可能であるとみなすべきですし(SHOULD)、そのMACアドレスのバックアップパスをインストールするべきです(SHOULD)。

バックアップパスの動作についての記述は14.1.1節を参照してください。

8.4.1. Ethernet A-D per EVPN Instance 経路の構築

この節ではEthernet A−D per EVPN instance (EVI)経路を構築するために使われる手順について記述します。この経路は(上記で説明したように)エイリアシングに使われます。この経路のサポートは任意です(OPTIONAL)。

Route Distinguisher(RD)は7.97.10節に従って設定されなければなりません(MUST)。

Ethernet Segment Identifierは5節の「イーサネットセグメント」で記述した通りの10オクテットでなければなりません(MUST)。

Ethernnet Tag IDはイーサネットセグメント上のイーサネットタグの識別子です。この値は12ビットのVLAN IDとすることができます。この場合下位12ビットがVLAN IDになり、上位の20ビットは0に設定されます。もしくはEVPNによって利用されるその他のイーサネットタグであるかもしれません。この場合そのイーサネットセグメントのデフォルトのイーサネットタグに設定することもできますし、0とすることもできます(MAY)。

上記によってEthernet A-D経路は次のうちの1つの粒度によって広告されることを意味します。

  • MAC-VRF毎の <ESI, イーサネットタグID>タプル毎に1つのEthernet A-D経路。これはPEがVID変換のあるMPLSベースのdispositionに該当します。もしくはPEがVID変換のあるMACベースのdispositionを使用するときにも該当するかもしれません。

  • MAC-VRF毎のEthernet A-D per ESI経路(イーサネットタグIDは0に設定される)。これはPEがMACベースのdispositionを使用しているときや、VID変換を変換のないMPLSベースのdispositionを使用している時に該当します。

MPLSラベルの使用方法は14節の「ユニキャストパケットのロードバランス」に記述されています。

経路のMP_REACH_NLRIアトリビュートのNext Hopフィールドは経路を広告するPEのIPv4またはIPv6アドレスに設定されなければなりません(MUST)。

Ethernet A-D経路には7.107.11節に従って1つ以上のRoute Target(RT)属性を付与しなくてはなりません(MUST)。

8.5. Designated Forwarder選出

あるイーサネットセグメントのEVPNインスタンスに所属する2つ以上のPEに直接マルチホームしているホストやルータなどのCEを考えます。1つ以上のイーサネットタグがそのイーサネットセグメントに設定されるでしょう。このシナリオにおいて、ただ1つのPEだけがDesignated Forwarder(DF)となり次の特定の動作について責任を持ちます。

この挙動は、マルチキャスト、ブロードキャスト、unknownユニキャストに対する<ES, VLAN>と<ES, VLAN Bundle>のいずれかの粒度でDFの選出を行えることを可能にしており、この仕様においてデフォルトの挙動だということに留意してください。

これと同様のシナリオにおいて、バックアップDesignated Forwarder(BDF)である2番目のPEはDFの障害時においてDFのこれらの動作をすることを想定することに責任があります。

CEはPEに対して単一のリンクを使用して特定のフローに属するパケットを常に送信することに留意してください。たとえば、CEがホストである場合、以前に述べたようにホストがPEに接続する複数のリンクをLink Aggregation Group(LAG)として扱います。CEはローカルのハッシュ関数を使ってトラフィックフローをLAGのリンクにマップします。

もしブリッジネットワークがEVPNのネットワークにスイッチを経由して2つ以上のPEにマルチホームしているとき、All-Active冗長モードをサポートするためには、ブリッジネットワークがLAGを使用して2つ以上のPEに対して接続している必要があります。

もしブリッジネットワークがLAGを使用せずにPEに接続している場合、ブリッジネットワークとPEの間のリンクのうち1つだけが<ES, VLAN>または<ES, VLAN Bundle>に対してアクティブなリンクでなくてはなりません。この場合、それぞれのPEから広告されるEthernet A-D per ES経路はESIラベル拡張コミュニティのフラグのSingle-Activeビットは1に設定されていなくてはなりません。

VLANベースサービスに対する<ES, VLAN>粒度、VLAN-(aware) Bundleサービスに対する<ES, VLAN Bundle>の粒度でのDF選出のデフォルトの手順は「サービスカービング」と呼ばれます。このサービスカービングによって、あるセグメントに宛てられる複数の宛先のトラフィックのロードバランスを実現するために、イーサネットセグメントごとに複数(VLANまたはVLAN Bundleごとに1つ)のDFを算出することが可能になります。このロードバランス手順では、そのESのVLANまたはVLAN Bundleの部分集合に対してそれぞれのPEがDFになるような方法によって、ESごとにVLAN空間をPEの間で平等に分割します。サービスカービングの手順はRFC8584の2.1節で定義されたDF選出の有限オートマトンに従うと次のとおりです。

  1. PEが属しているイーサネットセグメントのESIを発見したとき、関連するES-Import拡張コミュニティ属性を付与したEthernet Segment経路を広告します。

  2. PEはタイマー(デフォルト値は3秒)をスタートさせ、その間に同じイーサネットセグメントに接続された他のPEノードからのEthernet Segment経路を受け付けます。このタイマー値は同じイーサネットセグメントに接続されたすべてのPEの間で同じであるべきです。

  3. Timerがexpireしたとき、それぞれのPEはそのセグメントに接続された(自分自身を含む)すべてのPEノードのIPアドレスの順序リストを数値の昇順で作成します。リストのそれぞれのIPアドレスEthernet Segment経路のOriginating Router's IP addressフィールドから展開されます。それぞれのPEは順序リストの中での位置を表す序数を得ることになります。この序数は数値的に最も小さいIPアドレスをもったPEを0として始まります。この序数はどのPEノードがイーサネットセグメントのあるEVPNインスタンスについてDFとなるかを決めるために使われます。そのルールは次のとおりです。

VLAN-BasedサービスについてはPEノードN個の冗長グループを考えます。ここで序数iのPEはV mod N = iとなる<ES, VLAN Bundle>のDFとなります。VLAN-(aware) Bundleサービスの場合はそのESのBundleの中で数値的に最も小さいVLANの値がmod関数で使われなくてはなりません(MUST)。

Ethernet Segment経路のOriginating Router's IP addressフィールドを使ってPEのIPアドレスを得ることは、もしそのような要求があればですが、CEが異なるASをまたいでマルチホームすることが可能になる順序リストを作成するために必要になることを述べておくべきでしょう。

4. それぞれのEVPNインスタンスについて、そのイーサネットセグメントに接続されたすべてのPEノードのIPアドレスの2つ目のリストが作成されます。上記でDFとして決定されたPEはこの順序候補リストから削除され、M個のPEノードからなるバックアップの冗長グループになります。

上記のステップ3と同じ条件に従って順序リスト内での2つ目の序数がそれぞれの残されたPEノードに与えられます。

この2つ目の序数は、そのイーサネットセグメント上で、どのPEのーどが与えられたEVPNインスタンスに対するBDFであるかを、上記と同じmodのルール(V mod M) = i で決定するために使われます。

4 5. ある<ES, VLAN>またはある<ES, VLAN Bundle>に対するDFとして選出されたPEは、対応するESのVLANやVLAN Bundleに向けての複数宛先トラフィックのアンブロックするでしょう。DF PEはセグメントに対する外向きの複数宛先トラフィックをアンブロックすることに留意してください。すべてのnon-DF PEはその<ES, VLAN>または<ES, VLAN Bundle>に対する外向きの複数宛先トラフィックをドロップし続けます。

リンクやポートの障害時には、影響を受けるPEはそのEthernet Segment経路をwithdrawします。これによりサービスカービングの手順が冗長グループのすべてのPEにおいて再度実行されます。PEノードの障害時や、PEの参加・脱退の際には、PEはサービスカービングを再実行します。Single-Activeマルチホームの場合は、再カービングの結果に基づいてサービスがあるPEから別のPEに移動するとき、そのサービスに対するDFとして選出されていたが終了するPEは、関連するイーサンネットセグメントに対してMACアドレスのフラッシュ通知を送信するべきでしょう(SHOULD)。これは例えばIEEE 802.1ak の Multiple VLAN Registration Protocol (MVRP)の 'new' 宣言によって実現できるでしょう。

すべての将来のDF選出アルゴリズムは、1つのPEをDFに選出し、1つのPEをBDFを選出し、他のPEをDFでないと選択するようなアルゴリズムを定義することが推奨されます(RECOMMENDED)。

8.6. プライマリPEとバックアップDFに選出されたPEの伝達

与えられたEVIに対するプライマリDFとバックアップDFに選出されたPEが決定されると、そのイーサネットセグメントにマルチホームしているPEは、そのEVIに対するEthernet A-D per EVI経路をそれぞれ広告し、それぞれの経路でL2-Attrib拡張コミュニティをPビットとBビットを、そのEVIにおいてのDFの役割を反映して設定します。

L2-Attrib拡張コミュニティは、All-Activeモードに対して含まれる場合は、Pビットは冗長グループに属するすべてのPEに対して設定されなければならないことに留意するべきでしょう。

8.6. 8.7. シングルホームのPEとの相互運用性

シングルホームのCE機器だけをサポートするPEをシングルホームPEとしましょう。シングルホームPEに対しては、上記のマルチホーミングの手順は省略されます。しかしながらシングルホームPEがマルチホームPEとの相互運用を完全に行えるようにするためには、シングルホームPEにおいても上記のいくつかのマルチホームの手順をサポートする必要があります。

  • 高速収束(8.2節の高速収束)を目的としたEthernet A-D経路の処理に関連する手順。シングルホームPEにおいても高速収束の利益を得るためです。

  • エイリアシング(8.4節のエイリアシングとバックアップパス)を目的としたEthernet A-D経路の処理に関連する手順。シングルホームPEにおいてもロードバランスの利益を得るためです。

  • バックアップパス(8.4節のエイリアシングとバックアップパス)を目的としたEthernet A-D経路の処理に関連する手順。シングルホームPEにおいても対応する収束速度の向上の利益を得るためです。

9. ユニキャストMACアドレスへの到達性の決定

PEは受け取ったパケットを宛先MACアドレスに基づいて転送します。これはつまりPEは与えられた宛先ユニキャストMACアドレスについてどのように到達するのかを学習することができなければならないということです。

MACアドレス学習は2つの要素があります。「ローカル学習」と「リモート学習」です。

9.1. ローカル学習

PEは接続されているCEからのMACアドレスを学習することが出来なければなりません。これがローカル学習です。

あるEVPNインスタンスのPEは、IEEEイーサネット標準の学習手順を用いてローカルのデータプレーン学習をサポートしなければなりません(MUST)。CEのネットワークから次のようなパケットを受信したとき、PEはそのデータプレーンのMACアドレスを学習できなければなりません。

あるいはPEはコントロールプレーンや、PEとCE間のマネージメントプレーンでCEのMACアドレスを学習することができます(MAY)。

あるPEのローカルに接続されたセグメント(たとえばESI X)で到達可能なMACアドレスが移動して、別のPEの別のセグメント(ESI Y)で到達可能になるような場合があります。これをMACモビリティと呼びます。これをサポートする手順は15節「MACモビリティ」に記載します。

9.2. リモート学習

PEは、他のPEに接続されているCEやその背後にあるCE(リモートCEやリモートCEの背後にあるホスト)のMACアドレス宛のトラフィックをどのように送信するかを決定することが出来なければなりません(MUST)。このようなMACアドレスを「リモート」MACアドレスと呼びます。

この文書ではPEがコントロールプレーンでリモートMACアドレスを学習することを求めます。これを達成するために、それぞれのPEはローカルに接続されたCEから学習したMACアドレスをコントロールプレーンで広告します。この広告はEVPNインスタンス内の他のすべてのPEに対して行われ、MP-BGPの特にMAC/IP Advertisement経路を使って行われます。

9.2.1. MAC/IP Address Advertisementの構築

EVPN NLRIのMAC/IP Advertisement経路タイプを使うことでMACアドレスを広告できるようにBGPは拡張されています。

RDは7.97.10節に基づいて設定されなければなりません(MUST)

Ethernet Segemnt Identifierフィールドは5節「イーサネットセグメント」で記述した10オクテットのESIに設定されます。

Ethernet Tag IDフィールドは0にするか、有効なイーサネットタグIDで表現することもできます。このフィールドはMAC-VRFに複数のブリッジテーブルがある場合(PEがそのEVIでVLAN-aware Bundleサービスをサポートする場合)に0でない値になります。

あるブロードキャストドメインについてNLRIのEthernet Tag IDに0でない値が設定される場合、このEthernet Tag IDはCEのイーサネットタグの値(CE VLAN ID)であるか、EVPNプロバイダのイーサネットタグの値(プロバイダVLAN ID)である場合かのいずれかです。後者はあるブロードキャストドメインのCEイーサネットタグ(CE VLAN ID)が異なるCEにおいて別の値を取るような場合でしょう。

MAC Address Lengthフィールドはビット単位であり、48に設定されます。48ビット以外のMACアドレスはこの文書の範囲外です。MACアドレスエンコーディング802.1Qと802.1D-REVIEEE.802.1Q_2014とIEEE.802.1D_2004で定義されている6オクテットMACアドレスである必要があります(MUST)。

IP Addressフィールドはオプションです。デフォルトではIP Address Lengthは0に設定され、IP Addressフィールドは経路から省略されます。有効なIPアドレスが広告される必要があるとき、この経路の中にエンコードされます。IPアドレスが存在する場合、IP Address Lengthフィールドはビット単位で32ビットまたは128ビットに設定されます。その他の値はこの文書の範囲外です。IPアドレスエンコーディングIPv4では4オクテット、IPv6では16オクテットでなければなりません(MUST)。EVPN NLRIのLengthフィールド(7節でオクテット単位と記述しました)はIPアドレスエンコードされているか、そしてIPアドレスIPv4IPv6かを判断できるに足るものでなくてはなりません。

MPLS Label1フィールドは3オクテットでエンコードされ、上位20ビットにラベル値が含まれています。MPLS Label1はdownstreamでアサインされなければならず、経路広告するPEによって関連付けられたMACアドレスとともに広告されます。PEはこのラベルを、MPLSでカプセル化されたパケットを受信して、宛先MACアドレスに基づいてPEに転送を行う時に使用します。転送の手順は13節と14節で定義されます。

あるMAC-VRFに所属するすべてのMACアドレスに対して同じ単一のEVPNラベルをPEが広告することがあります。このラベルのアサイン方式をper MAC-VRFラベルアサインと呼びます。その他にPEはMAC−VRFとイーサネットタグの組み合わせごとにユニークなEVPNラベルを広告することもできます。このラベルアサイン方式をper <MAC-VRF, Ethernet tag>ラベルアサインと呼びます。第三の選択肢として、PEはESIとイーサネットタグの組み合わせごとにユニークなラベル広告することができます。このラベルアサイン方式をper <ESI, Ethernet tag>ラベルアサインと呼びます。第四の選択肢として、PEはMACアドレスごとにユニークなラベルを広告することもできます。このラベルアサイン方式をper MACラベルアサインと呼びます。これらのラベルアサイン方式はそれぞれトレードオフがあります。特定のラベルアサイン方式の選択はその経路を生成するPEに閉じるものです。

per MAC-VRFラベルアサインは必要となるEVPNラベルの数を最小限に抑えることが出来ますが、egress PEはフォワーディングを行うためにMPLSのルックアップに加えてMACのルックアップを行う必要があります。per <ESI, Ethernet tag>とper MACラベルアサインではegress PEはMACのルックアップを行わずにMPLSラベルだけをルックアップすることで他のPEから受信したパケットを接続したCEに転送することが出来ます。これによりCEに対して適切なVLAN ID変換をegress PEで行うことが可能になります。

MPLS Label2フィールドはオプションのフィールドです。もし存在する場合は3オクテットでエンコードされ、上位20ビットにラベルの値を含めます。

経路のMP_REACH_NLRI属性のNext Hopフィールドは経路広告を行うPEのIPv4またはIPv6アドレスを設定しなければなりません(MUST)。

MAC/IP Advertisement経路のBGP経路広告は1つ以上のRoute Target(RT)属性を含めなければなりません(MUST)。RTはIP VPNのように設定できますし、7.10.17.11.1節で記載したようにUnique VLANのケースではイーサネットタグIDから自動的に設定することもできます。

コントロールプレーンで学習されたリモートMACに対する転送状態をPEが管理することはこの文章では求めていないことを記しておきます。転送状態の管理はPEに閉じる実装の問題だからです。

9.2.2. 経路解決

受信したMAC/IP Advertisement経路のEthernet Segment Identifierフィールドが予約されたESIの値である0またはMAX−ESIであるとき、受信したPEがその経路に関連するMACアドレスについての転送状態をインストールするかどうかはMAC/IP Advertisement経路のみに基づかなければなりません(MUST)。

受信したMAC/IP Advertisement経路のEthernet Segment Identifierフィールドが予約されていないESIであるとき、受信したPEはその経路に関連するMACアドレスについての転送状態をインストールするかどうかは、MAC/IP Advertisement経路と関連する一連のEthernet A-D per ES経路の両方が受信された時に決定します。Ethernet A-D per ES経路に依存してMAC経路をインストールすることにより、大量のwithdrawが行われている期間にMAC経路が誤ってインストールされてしまうことが起きないようにしています。

例でこれを説明すると、2つのPE(PE1とPE2)がマルチホームのイーサネットセグメントES1に接続されている状態を考えてください。All-Active冗長モードだと仮定します。あるMACアドレスM1がPE1で学習されているがPE2で学習されているときに次のような状態が起こりえます。

T1 PE1からのMAC/IP Advertisement経路とPE1とPE2のEthernet A−D per ES経路と一連のEthernet A-D per EVI経路を受信したとき、PE3はPE1とPE2の両方に対してM1宛のトラフィックを転送することができます。

T2 T1のあとPE1がEthernet A-D per ES経路をwithdrawすると、PE3はM1宛のトラフィックをPE2にだけ転送します。

T2' T1のあとPE2がEthernet A-D per ES経路をwithdrawすると、PE3はM1宛のトラフィックをPE1にだけ転送します。

T2'' T1のあとPE1がMAC/IP Advertisement経路をwithdrawすると、PE3はM1宛のトラフィックをunknown unicastとして扱います。

T3 PE2もM1のMACを広告し、PE1がM1のMACをwithdrawします。PE3はM1宛のトラフィックを引き続きPE1とPE2の両方に転送します。言い換えるとM1がPE1によってwithdrawされたにもかかわらずPE3はM1宛のトラフィックをPE1とPE2の両方に転送します。これはCEからのフローが原因で、M1のトラフィックがハッシュによりPE1に送られていたものが終了し、M1がPE1でエージアウトします。しかしM1はPE1とPE2の両方で到達可能です。

10. ARP and ND

MAC/IP Advertisement経路のIP AddressフィールドはオプションとしてMACアドレスに関連するIPアドレスの1つを運んでいることがあります。これによって、MPLSネットワーク内やリモートPEに対するARPや近隣探索(ND)のフラッディングを最小化することができます。このオプションはEVPNネットワークに接続されたエンドステーションやホストにおけるARP(またはND)メッセージの処理を最小化することもできます。PEはCEとPEの間のコントロールプレーンまたはマネージメントプレーンに置いてあるMACアドレスに関連するIPアドレスを学習するでしょう。もしくは、CE向けやCEからのある種のメッセージをスヌープすることでこのバインディングを学習するでしょう。ローカルに接続されたCEのMACアドレスに関連するIPアドレスをPEが学習したとき、PEはMAC/IP Advertisement経路に含めることでこのアドレスを他のPEに広告することができます。そのIPアドレスは4オクテットでエンコードされたIPv4アドレスか16オクテットでエンコードされたIPv6アドレスにすることができます。ARPとNDの目的のために、IP Address LengthフィールドはIPv4アドレスでは32、IPv6アドレスでは128に設定されていなくてはなりません(MUST)。

もしあるMACアドレスに対して複数のIPアドレスが紐付けられていた場合、それぞれのアドレスに1つずつで複数のMAC/IP Advertisement経路が生成されなくてはなりません(MUST)。たとえばデュアルスタックのシナリオにおいて同じMACアドレスに対してIPv4アドレスとIPv6アドレスの両方が存在するケースが挙げられます。そのIPアドレスMACアドレスの関連付けが無くなったときは、そのIPアドレスMAC/IP Advertisement経路はwithdrawされなくてはなりません(MUST)。

MAC/IP経路を生成するようなARPスヌーピングと独立して、データプレーンにおいてアクセスネットワークやノードからのMAC学習が行われたようなシナリオでは、MAC/IP経路に加えて、しかし独立して、MAC-only経路を広告することが出来ることに留意してください。このようなシナリオではARPエントリーがタイムアウトした時にMAC/IP経路のwithdrawが発生しますが、MAC情報は失われません。ホストのMACアドレスがコントロールプレーンまたはマネージメントプレーンで行われるようなシナリオにおいて、送信元のPEはMACオンリー経路だけを生成して広告するでしょう。受信するPEがMACオンリー経路とMAC/IP経路の両方を受信している時に、MAC/IP経路のwithdrawメッセージを受信したときは、MAC-VRFテーブルから対応するエントリをARPテーブルから削除しなくてはなりませんが(MUST)、MACオンリー経路のwithdrawを受信しない限りはMACエントリーは削除してはいけません(MUST NOT)。

PEがあるIPアドレスに対するARPリクエストをCEから受信したときに、PEがそのIPアドレスバインディングされたMACアドレスを知っている場合は、PEはARPリクエストに応答することによってARPプロキシを実行するべきです(SHOULD)。

同様の方法で、PEがCEからIPアドレスに対するNeighbor Solicitationを受信したとき、PEがそのIPにバインディングされた情報を持っている場合は、そのPEはNDプロキシを実行して、応答するべきです(SHOULD)。

10.1. Default Gateway

異なるブロードキャストドメイン(すなわち異なるVLAN)で表現されているサブネットの間の転送をPEが行う必要があるとき、サブネット間転送はレイヤー3で行われます。このような機能を実行するPEをEVPNインスタンスに対するデフォルトゲートウェイと呼びます。このケースではデフォルトゲートウェイアドレスとして設定されたIPアドレスに対するARPリクエストをPEが受信したとき、PEはARPリプライを生成します。

あるEVPNインスタンスについてデフォルトゲートウェイとして動作するそれぞれのPEは、EVPNコントロールプレーンにおいてデフォルトゲートウェイMACアドレスMAC/IP Advertisement経路を使用することで広告することができます(MAY)。そして、その経路がデフォルトゲートウェイと関連するものであると示します。これは7.8節「デフォルトゲートウェイ拡張コミュニティ」で定義されたデフォルトゲートウェイ拡張コミュニティを経路に付与することによって実現されます。デフォルトゲートウェイ拡張コミュニティを付与されたMAC経路を広告するときはESIフィールドが0に設定されます。

MAC/IP Advertisement経路のIP Adressフィールドはそのサブネット(たとえばEVPNインスタンス)のデフォルトゲートウェイIPアドレスに設定されます。ある1つのサブネット(たとえばVLANまたはEVPNインスタンス)について、デフォルトゲートウェイIPアドレスは、参加しているすべてのPEの間で同じです。このIPアドレスを含むことで、経路を受信するPEが自身に設定されたデフォルトゲートウェイIPアドレスが、そのサブネット(またはEVPNインスタンス)の受信したMAC/IP Advertisement経路に含まれているIPアドレスと合致するかチェックすることができるようになります。もし不一致がある場合はPEは運用者に通知し、エラーメッセージをログに記録するべきです(SHOULD)。

あるEVPNインスタンスのすべてのPEがそのEVPNインスタンスデフォルトゲートウェイとして動作することは(このドキュメント外の方法で)prioriとして知られていますが、MPLSラベルはdownstreamで割り当てられた有効なラベルである必要があります(MUST)。

さらに、あるEVPNインスタンスのすべてのPEがそのEVPNインスタンスデフォルトゲートウェイとして動作していたとしても、それらのうち少数であるが全てではないPEが、そのEVPNインスタンスに関連するサブネットで生成されたすべてのサブネット間トラフィックに対してサブネット間のルーティングを提供できるだけの十分な(ルーティングの)情報を持っている場合、そのようなPEはEVPNコントロールプレーンにおいてデフォルトゲートウェイMACアドレスMAC/IP Advertisement経路を用いて広告し、そのような経路がデフォルトゲートウェイとして示されるのであれば、その経路はdownstreamで割り当てられた有効なラベルを運ばなくてはなりません(MUST)。

もしあるEVPNインスタンスのすべてのPEがそのEVPNインスタンスに対するデフォルトゲートウェイとして動作する場合で、同じデフォルトゲートウェイMACアドレスがすべてのゲートウェイ機器で使用される場合、そのような広告は必要ありません。しかしそれぞれのゲートウェイが別々のMACアドレスを使用する場合は、それぞれのデフォルトゲートウェイは他のゲートウェイMACアドレスについて意識する必要があるので、そのような広告は必要となります。1つのデフォルトゲートウェイが複数のMACアドレスで表現されるので、これをMACアドレスエイリアシングと呼びます。

この経路を受信してこのドキュメントで指定された手続きに基づいてインポートするそれぞれのPEは、受信したARPリクエストに対して応答する時にこの節の手順に従います。

あるEVPNインスタンスデフォルトゲートウェイとして動作し、この経路を受信してこのドキュメントで指定された手続きに基づいてインポートするそれぞれのPEは、経路で運ばれたMACアドレス宛のパケットに対してIP転送できるようにMAC転送状態を作成する必要があります(MUST)。

10.1.1. デフォルトゲートウェイのベストパス選択

PEにおいてIRBインターフェイスに(サブネットのために)割り当てられたデフォルトゲートウェイMACアドレスは、そのサブネットにおいて一意でなければなりません(MUST)。言い換えると同じMACアドレスを意図的にであっても誤りであってもホストに使用することはできません。そのため、このような重複が発生したときに、検知して解決するような方法が必要になります。このような重複を適切に検知するために次のBGPベストパス選択が適用されなければなりません(MUST)。

  • 2つの経路を比較するとき、Gateway GMAC ECのある経路は、GMAC ECの無い経路よりも優先されます。GMAC ECのない経路を広告したPEがGMAC ECのある経路を受信したとき、その経路をwithdrawして警報を上げるべきです(SHALL)。

  • GMAC ECのある2つの経路を比較するとき、通常のBGPベストパス処理が適用されます。

  • Gateway GMAC ECのあるローカルの経路とリモートの経路を比較するとき、ローカルの経路が常に優先されます。

  • MAC Mobility ECは、送信側においてGMAC ECのある経路には付与されるべきではなく(SHALL not)、受信側では無視されるべきです(SHALL)。

11. 複数宛先トラフィックの処理

あるPEがCEから受信したブロードキャストやマルチキャストをEVPNインスタンス内で与えられたイーサンネットタグでカプセル化し、EVPNインスタンス内でそのイーサネットタグ(VLAN)にまたがる他のすべてのPEに対して送信するための手順が必要となります。特定のシナリオにおいては12節「Unknownユニキャストパケットの処理」に記述されているように、あるPEはunknownユニキャストを他のPEにフラッディングする必要もあるかもしれません。

ある特定のEVPNインスタンスではunknownユニキャスト、ブロードキャスト、マルチキャストトラフィックを他のPEに送信するためにIngress ReplicationやP2MP LSPやMP2MP LSPのいずれかを使用することができます。

これを実現するためにそれぞれのPEは「Inclusive Multicast Ethernet Tag経路」を広告しなければなりません(MUST)。次の小節ではInclusive Multicast Ethernet Tag経路を構築する手順を記載します。またその次の小節では使用方法をより詳細に記述します。

11.1. Inclusive Multicast Ethernet Tag経路の構築

RDは7.97.10節に従う必要があります(MUST)。

Ethernet Tag IDはイーサネットタグの識別子です。0または有効なイーサネットタグの値を設定します。

Originating Router's IP AddressフィールドはPEのすべてのEVIに対して共通であるPEのIPアドレス(PEのループバックアドレスであることが多いでしょう)を設定しなければなりません(MUST)。

経路のMP_REACH_NLRI属性のNext Hopフィールドは、経路広告を行うPEのIPv4アドレスまたはIPv6アドレスに設定しなくてはなりません(MUST)。

Inclusive Multicast Ethernet Tag経路のBGP広告は1つ以上のRoute Target(RT)属性を付与されなければなりません(MUST)。RTのアサインは7.107.11節に記載されているものに従わなくてはなりません(MUST)。

11.2. Pトンネルの識別

ブロードキャスト、unknownユニキャスト、マルチキャストトラフィックを送信するために使われるPトンネルを識別するためには、RFC6514で定義されているにProvider Multicast Service Interface (PMSI) Tunnel属性をInclusive Multicast Ethernet Tag経路に付与しなくてはなりません(MUST)。

PEのEVPNインスタンスのためのPトンネルに使われる技術に依存して、Inclusive Multicast Ethernet Tag経路のPMSI Tunnel属性は次のように構築されます。

  • もし経路広告を生成するPEがEVPNのためのPトンネルとしてPマルチキャストツリーを使う場合、PMSI Tunnel属性はツリーの識別子(PEはツリーを構築する前に識別子を生成することが出来るであろうことに留意してください)を含む必要があります(MUST)。

  • PトンネルにPマルチキャストツリーを使うPEはPE上にある2つ以上のEVPNインスタンス(EVI)ブリッジドメイン(BD)を同じツリーに集約することができます(MAY)。このケースでは、ツリーの識別子を含めるのに加えて、PMSI Tunnel属性は上流でアサインされたMPLSラベルを含めなければなりません(MUST)。これは(RTイーサネットタグIDで決定できるように)経路UPDATEに関連するEVIBDに一意になるように束ねたラベルである必要があります。割り当てられたMPLSラベルは、19節Domain-wide Common Block(DCB)ラベルの使用」の手順ができようされない限り、上流で割り振られたものです。もしPEがすでに2つ以上のEVIBDについてInclusive Multicast Ethernet Tag経路を広告している時に、それらを集約したい場合、PEはそれらの経路を再広告しなくてはなりません(MUST)。再広告された経路はPMSI Tunnel属性とそのラベル以外は元の経路と同じである必要があります(MUST)。

  • もし経路広告を生成するPEがEVPNのためのPトンネルとしてIngress Replicationを使う場合、Tunnel TypeをIngress Replicationに設定し、Tunnel IdentiferをPEのルーティング可能なアドレスに設定したPMSI Tunnel属性を経路に含めなければなりません(MUST)。PMSI Tunnel属性はdownstreamで割り当てられたMPLSラベルを含める必要があります(MUST)。このラベルはMP2Pトンネル越しに受信したブロードキャスト、マルチキャスト、unknownユニキャストのEVPNトラフィックを分離するために使用されます。

  • PMSI Tunnel属性のLeaf Information Requiredフラフはゼロに設定しなければならず(MUST)、受信時には無視しなくてはなりません(MUST)。

12. Unknownユニキャストパケットの処理

この文書の手順はPEが他のPEにunknownユニキャストトラフィックをフラッディングすることを要求しません。もしPEがCEのMACアドレスをコントロールプレーンのプロトコルで学習している場合、PEはMACアドレスをBGPで配布することができますし、すべてのユニキャストMACアドレスはそれらの宛先のトラフィックよりも先に学習されるでしょう。

しかしもし受信したパケットの宛先MACアドレスがPEで学習されていない場合、PEはパケットをフラッディングさせなくてはならないかもしれません。フラッディングするときPEは「スプリットホライズン転送」を次のように考慮しなくてはなりません(MUST)。次の手順の背後にある原理はRFC4761とRFC4762のVPLSソリューションのスプリットホライズン転送のルールを借用しています。

フラッディング可能なPE(PExと呼ぶ)が宛先不明のMACアドレスを受信したとき、そのフレームをフラッディングします。そのフレームが接続されているCEから到着したものである場合は、PExはそのフレームの複製を(そのEVIが属する)自身がDFであるそれぞれのイーサネットセグメントに対して送信しなければなりません。ただしフレームを受信したイーサネットセグメントに対しては送信してはいけません。さらにそのEVPNインスタンスに属するすべての他のPEに対してもフレームをフラッディングしなければなりません。一方でもしフレームが他のPE(PEyと呼ぶ)から到着したものである場合は、PExは(そのEVIが属する)自身がDFであるそれぞれのイーサンネットセグメントに対してそのフレームの複製を送信しなければなりません。PExはそのフレームを他のPEに送信してはなりません(MUST NOT)。PEyが既に送信しているからです。スプリットホライズンの転送ルールをunknown MACアドレスに対して適用します。

unknownな宛先MACアドレスにパケットをフラッディングするかどうかは、CEとPEの間の学習がどのように行われるかに基づいて、管理者が選択できるべきです。

特定のEVPNインスタンスのPEは、unknownユニキャストトラフィックを他のPEの送信するためにRSVP−TE P2P LSPまたはLDP MP2P LSPを使ったIngress Replicationを使うことができます。もしくは他のPEにそのようなトラフィックを送信するためにRSVP-TE P2MPまたはLDP P2MPを使うこともできます。

12.1. Ingress Replication

もしIngress Replicationが使用されたとき、そのEVPNインスタンスに対するInclusive Multicast Ethernet Tagで運ばれるPトンネル属性は、その他のPEがそのEVPNインスタンスに対するunknownユニキャスト、マルチキャストまたはブロードキャストトラフィックを、この特定のPEに送信するために使うことが出来るようなdownstreamのラベルを指定します。

この特定のMPLSラベルが付与されたパケットを受信したPEは、そのパケットをブロードキャスト、マルチキャストまたはunknownユニキャストパケットとして扱わなければなりません(MUST)。さらに、もしそのMACアドレスがユニキャストMACアドレスである場合、そのPEはそのパケットをunknownユニキャストとして扱わなければなりません(MUST)。

12.2. P2MP MPLS LSP

P2MP LSP(MP2MP LSPについてもそうですが)を使用した手順はRFC7117に記述されているVPLSの手順ととても似ています。特定のEVPNインスタンスのunknownユニキャスト、ブロードキャストまたはマルチキャストトラフィックを送信するためにPEによって使用されるPトンネル属性は、11節「複数宛先トラフィックの処理」に記述されるように、Inclusive Multicast Ethernet Tag経路で広告されます。

Pトンネル属性はP2MP LSPまたはMP2MP LSPの識別子を指定します。これはEFC7117に記述されているInclusiveツリーと同等なものです。異なるEVPNインスタンスに存在するかもしれない複数のイーサネットタグが、RFC7117やI-D.ietf-bess-mvpn-evpn-aggregation-labelのDCBラベルのようにupstreamのラベルを使用して同じP2MP LSPまたはMP2MP LSPを使用することがあることに留意してください。これはRFC7117のAggregate Inclusiveツリーと同等なものです。P2MP LSPまたはMP2MP LSPがunknownユニキャストをフラッディングするために使用される場合、パケットの順序制御が可能です。

PMSI Tunnel属性で指定されたP2MP LSPまたはMP2MP LSPでパケットを受信したPEは、そのパケットをブロードキャスト、マルチキャストまたはunknownユニキャストパケットとして扱わなくてはなりません(MUST)。さらに、もしそのMACアドレスがユニキャストMACアドレスである場合、そのPEはそのパケットをunknownユニキャストとして扱わなければなりません(MUST)。

13. ユニキャストパケットの転送

この節では、直接接続されたCEや他のPEから受信したユニキャストパケットをPEが転送するときの手順について記述します。

13.1. CEから受信したパケットの転送

PEがあるイーサネットタグIDでCEからパケットを受信したとき、PEはまずはじめに送信元MACアドレスをルックアップしなければなりません。MACセキュリティを有効化している特定の環境においては、送信元MACアドレスはホストの身元を検証し、ホストからのトラフィックをネットワークへ転送するかどうかを決めることに使用できます(MAY)。送信元MACのルックアップはMACアドレス学習に使うこともできます(MAY)。

もしPEがそのパケットを転送すると決定した場合、パケットの宛先MACアドレスをルックアップしなければなりません。もしPEがこの宛先MACアドレスMACアドレス広告を1つ以上の他のPEから受信していた場合や、ローカルで接続されたCEから学習している場合、MACアドレスはknown MACアドレスだとみなされます。そうでなければunknown MACアドレスだとみなされます。

known MACアドレスについては、PEはそのパケットを複数のリモートPEのうちの1つに転送するか、ローカルに接続されたCEに転送します。リモートPEに転送するときには、パケットはリモートPEによってそのMACアドレスに対して広告されたEVPN MPLSラベルと、そのリモートPEに到達するためのMPLS LSPラベルスタックでカプセル化されます。

もしMACアドレスがunknownで、PEの管理ポリシーがunknownユニキャストのフラッディングを必要とする場合、

  • PEはパケットを他のPEにフラッディングしなければなりません(MUST)。PEはまず8.3節で記述したようにESI MPLSラベルでパケットをカプセル化しなければなりません(MUST)。もしIngress Replicationを使用する場合、パケットをそれぞれのリモートPEに対して複製しなければなりません(MUST)。このときVPNラベルは次のようにして決定されるMPLSラベルにします: これは、リモートPEから広告される<MAC-VRF>または<MAC-VRF, イーサネットタグ>の組み合わせに対するInclusive Multicast Ethernet Tag経路のPMSI Tunnel属性に含まれるMPLSラベルです。

  • その経路中のイーサネットタグは、ingress PEがパケットを受信したインターフェイスに関連付けられたイーサネットタグと同じであるかもしれません。もしP2MP LSPを使用する場合、パケットはそのPEが、EVPNインスタンスイーサネットタグIDに対してrootになっているP2MP LSPに送信されなければなりません(MUST)。もし同じP2MP LSPをすべてのイーサネットタグに対して使用するのであれば、そのEVPNインスタンス中のすべてのPE はP2MP LSPのリーフでなくてはなりません(MUST)、もし異なるP2MP LSPをEVPNインスタンス中のあるイーサネットタグに対して使用するのであれば、そこイーサネットタグのPEだけがP2MP LSPのリーフになれなければなりません(MUST)。パケットはP2MP LSPラベルスタックでカプセル化されなければなりません。

もしMACアドレスがunknownで、PEの管理ポリシーがunknownユニキャストのフラッディングを許可しない場合、

  • PEはそのパケットを破棄しなければなりません(MUST)。

13.2. リモートPEから受信したパケットの転送

この節ではリモートPEからknownユニキャストパケットとunknownユニキャストパケットを転送するための手順について記述します。

13.2.1. unknownユニキャストの転送

PEがMPLSパケットをリモートPEから受信し、MPLSラベルスタックを処理したあと、トップのMPLSラベルラベルがEVPNインスタンスに関連付けられたP2MP LSPラベルであるか、もしくは、――Ingress Replicationの場合―― Pトンネル属性で広告されたdownstreamのラベルである場合は、8.3節に記述したスプリットホライズンの手順を実行し、そのあと:

  • そのイーサネットタグについてのESIの特定の集合におけるBUMトラフィックについて、そのPEがDesignated Forwarderである場合のデフォルトの動作は、これらのESIにパケットをフラッディングすることです。言い換えれば、PEのデフォルトの動作は、BUMトラフィックについて宛先MACアドレスをルックアップする必要がないということです。オプションとして、PEは宛先MACのルックアップをおこなって、イーサネットタグに属するCEインターフェイスのサブセットに対してだけパケットをフラッディングすることもできます。たとえばPEは、あるイーサネットセグメントにおいてDFであったとしても、管理ポリシーに基づいて、BUMパケットをそのイーサネットセグメントにフラッディングしないように決めることもできます。

  • そのイーサネットタグについてのESIのいずれについてもPEがDesignated Forwarderでない場合、デフォルトの動作はパケットを破棄することです。

13.2.2. knownユニキャストの転送

もしトップのMPLSラベルがユニキャストMAC広告で広告されたEVPNラベルである場合、PEはそのラベルに関連付けられたCEのネクストホップ転送情報に基づいてパケットを転送するか、宛先MACアドレスをルックアップしてCEにパケットを転送するかのいずれかを行います。

14. ユニキャストパケットのロードバランス

この節ではマルチホームCEに対してknownユニキャストを送信するときのロードバランスの手順について規定します。

14.1. PEからリモートCEへのトラフィックのロードバランス

あるMAC-VRFの与えられた<ESI, イーサネットタグ>に対するMAC/IP Advertisement経路をリモートPEがインポートするときは必ず、そのイーサネットセグメントにおけるロードバランスの特性を決定するために、インポートされたそのESIに対するすべてのEthernet A-D経路を検査しなければなりません(MUST)。

14.1.1. Single-Active冗長モード

与えられたESに対して、あるリモートPEが少なくとも1つのPEから、ESIラベル拡張コミュニティの中のSingle-Activveフラグが設定された一連のEthernet A-D per ES経路をインポートしたとき、そのリモートPEはそのESがSingle-Active冗長モードで動作していると推定しなければなりません(MUST)。そのMACアドレスは、対応するMAC/IP Advertisement経路を広告しているPEを経由してのみ到達可能であるでしょう。このPEはプライマリPEと呼びます。同じESに対して一連のEthernet A-D per ES経路を広告している他のPEは、プライマリPEが障害にあたった場合においてそのESに対するバックアップパスを提供します。これらをバックアップPEと呼びます。与えられた<ES, VLAN>(または<ES, VLAN Bundle>)に対するプライマリPEはその<ES, VLAN>(または<ES, VLAN Bundle)に対するDFであることに留意してください。

これは与えられた[EVI, BD]に対して、与えられたMACアドレスが関連するMAC/IP Advertisement経路を広告しているPEを経由してのみ到達可能であるだけだということを意味します。このPEはこの[EVI, BD]に対するEthernet A-D per EVI経路をPビットを設定したL2-Attrib拡張コミュニティを付加して広告しています。つまり、プライマリDFに選出されたPEは、KnownユニキャストフレームをCEに送信することと、ユニキャストフレームとBUMフレームを受信することに責任があるということです。同様にバックアップDFに選出されたPEはこの[EVI, BD]に対するEthernet A-D per EVI経路をBビットを設定したL2-Attrib拡張コミュニティを広告して広告しています。

もしプライマリPEが障害にあたった場合、一連のMAC/IP Advertisement経路をwithdrawするよりも前に、影響を受けるESについての一連のEthernet A-D per ES経路をwithdrawすることができます(MAY)。

もしプライマリDFに選出されたPEがCEへの接続性を失った場合、PEは一連のMAC/IP Advertisement経路をwithdrawするよりも前に、影響を受けるESについての一連のEthernet A-D per ES経路をwithdrawするべきです(SHOULD)。バックアップDFに選出されたPEは(これによりプライマリに選出されたPEとなり)、その[EVI, BD]に対するEthernet A-D per EVI経路をL2-Attrib拡張コミュニティのPビットを設定して広告する必要があります。さらに新しくバックアップDFに選出されたその[EVI, BD]に対するPEはEthernet A-D per EVI経路をL2-Attrib拡張コミュニティのBビットを設定して広告する必要があります。

もし与えられたESに対してバックアップPEが1つしかない場合、リモートPEはプライマリPEがEthernet A-D per ES経路のwithdrawをしたことをトリガーとして、関連するMACアドレスの転送エントリーをバックアップPEに向けることができます(MAY)。バックアップPEがMACアドレスを接続されたESで学習し始めると、MAC/IP Advertisement経路の広告を始めます。その一方で障害の発生したPEではそれらの経路をwithdrawしています。この仕組みによってフェイルオーバーが発生した間のトラフィックのフラッディングを最小化することができます。

リモートPEは、プライマリDFに選出されたPEが一連のEthernet A-D per ES経路をwithdrawしたことを契機として、関連するMACアドレスがバックアップDFに選出されたPEを指すように転送エントリーを更新します。バックアップDFに選出されたPEが接続されたイーサネットセグメントでMACアドレスの学習を始めるため、そのPEはMAC/IP Advertisement経路を送信し始めるでしょう。その一方で障害の発生したPEではそれらの経路をwithdrawしています。この仕組みによってフェイルオーバーが発生した間のトラフィックのフラッディングを最小化することができます。

もし与えられたESIに対してバックアップPEが2つ以上ある場合、リモートPEはプライマリPEがEthernnet A-D per ES経路をwithdrawしたことをトリガーとして、(unknownユニキャストパケットのフラッディングが管理上許可されている場合に限り)関連するMACアドレスに対してフラッディングを開始しなければなりません(MUST)。これはバックアップPEを1つに選出することができないからです。

14.1.2. All-Active冗長モード

ある与えられたESに対して、リモートPEが1つ以上のPEからEthernet A-D per ES経路の集合をインポートし、そのいずれの経路のESIラベル拡張コミュニティにもSingle-Activeフラグが設定されていないとき、リモートPEはそのESIがAll-Active冗長モードで動作していると推定しなければなりません(MUST)。予約されていないESIのMAC/IP Advertisement経路を受信したリモートPEは、広告されたMACアドレスが、そのEVI/ES(適用可能ならイーサネットタグも)に対するEthernet A-D per EVI経路とそのESに対するEthernet A-D per ES経路の組み合わせによってそのMACアドレスのEVI/ESへの到達性広告したすべてのPEから到達可能であると考えるべきです(SHOULD)。リモートPEは受信したMAC/IP Advertisement経路とEthernet A-D per EVI経路とper ES経路を、広告されたMACアドレスネクストホップを構築するために使用しなければなりません。

それぞれのネクストホップはegress PEがパケットを転送するために使われるMPLSラベルスタックで構成されます。このラベルスタックは次のようにして決定されます:

  • もしMAC経路の結果としてネクストホップが構築されるとき、このラベルスタックは使用されなければなりません。しかし、MAC経路がそのPEに対して存在しない場合、ネクストホップとMPLSラベルスタックは、Ethernet A-D経路によって構築されます。MAC広告の中にあったものと同じESIとイーサネットタグを持っているEthernet A-D経路を受信してインポートしたリモートPEから、ある与えられたPEに到達するための特定のネクストホップのためのラベルスタックを決定するために下記の記述が適用されることに留意してください。下記の記述で言及されるEthernet A-D経路は、この与えられたPEからインポートされたものを指しています。

  • もしそのEのためのEthernet A-D per ES経路の集合「と」Ethernet A-D per EVI経路が存在したとき、後者の経路のラベルだけが使用されるべきです。

次の例が上記の説明です。

あるCE(CE1)が2つのPE(PE1とPE2)にLAGインターフェイス(ES1)でデュアルホームしていて、MAC1の送信元mACアドレスを持ったパケットを(EVI1にマップされる)VLAN1に対して送信したとします。リモートPE(PE3)はそのMAC1をPE1とPE2を経由して到達可能であると学習します。PE1とPE2の両方は、CE1からMAC1のパケットを受信すると、MAC1をBGPで広告することができます。もしそうでない場合で、MAC1がPE1からのみだけ広告されていたとすしても、PE3は依然としてMAC1がPE1とPE2の両方から到達可能であるとみなします。なぜならPE1とPE2の両方がES1についてのEthernnet A−D per ES経路の集合に加えて<EVI1, ES1>についてのEthernet A-D per EVI経路をを広告しているからです。

PE1にパケットを送信するときのMPLSラベルスタックは、PE1に到達するMPLS LSPスタックがトップにあり、CE1のMACに対してPE1から広告されたEVPNラベルが続きます。

PE2にパケットを送信するときのMPLSラベルスタックは、PE2に到達するMPLS LSPスタックがトップにあり、もしPE2がBGPでMAC1を広告していないのであれば、PE2から<ES1, VLAN1>について広告されたEthernet A-D経路のMPLSラベルが続きます。

これらのラベルスタックをMPLSネクストホップと呼びます。

リモートPE(PE3)はこれでCEから受信したCE1宛のトラフィックをPE1とPE2の間でロードバランスすることが可能になりました。PE3はIPトラフィックのロードバランスのためにN-タプルのフロー情報を使ってトラフィックをハッシュ化してMPLSネクストホップのうちの1つに割り当てることができます。言い換えると、PE3は送信元MACアドレスを使ってロードバランスをすることが可能であるということです。

PE3がある特定のパケットをPE1またはPE2に送信することを一度決めたとき、通常のMPLSの手順を使用して特定のリモートPEに対して到達する複数の利用可能なパスから1つを選択することが可能であることを留意してください。たとえばESVP-TE LSPベースのトンネル技術が利用されていて、PE3がある特定のパケットをPE1に送信することを決めたとすると、PE3はPE1を宛先とする複数のRSVP-TE LSPの中から選択することができます。

PE1またはPE1がCE1宛のパケットをPE3から受信したとき、もしパケットがknownユニキャストであればCE1に転送されます。もしBUMパケットである場合は、PE1またはPE2のうちいずれか1つだけがそのパケットをCEに転送しなければなりません。PE1またはPE2のどちらがこのパケットをCEに転送するかは、どちらがDFであるかに基づいて決定されます。

14.2. PEとローカルCEの間でのトラフィックのロードバランス

CEはLAGのような技術を使用することで複数のインターフェイスをそれぞれ異なるPEやロードバランスを目的として同一のPEに接続するような構成をとることができます。PEとCEは次の仕組みのうち1つを使用することでこれらのインターフェイストラフィックをロードバランスすることができます。

14.2.1. データプレーン学習

PEがローカルCEから学習するローカルMACアドレスのためにデータプレーン学習を行うとします。このときもしPEとCEがマルチパスをサポートする技術を使用している場合は、PEは特定のMACアドレスを学習してそれを1つ以上のインターフェイスに関連付けることができます。これによりPEはそのMACアドレス宛のトラフィックを複数のインターフェイスにロードバランスすることが可能になります。

CEが生成するトラフィックをCE自身が複数のインターフェイスにロードバランスできるかどうかはCEの実装に依存します。

14.2.2. コントロールプレーン学習

CEをすべてのインターフェイスで制御プロトコルを使用して同じMACアドレスを広告するようなホストにすることができます。このときPEはホストのMACアドレスを学習し、それをすべてのインターフェイスに関連付けることができるようになります。これによりPEはそのホスト宛のトラフィックをすべてのインターフェイスでロードバランスすることができるようになります。ホストも生成するトラフィックをこれらのインターフェイスでロードバランスすることができ、そのトラフィックを受け取ったPEはEVPNの転送手順を使用してトラフィックを転送します。

15. MACモビリティ

与えられたホストやエンドステーションがあるイーサネットセグメントから別のイーサネットセグメントへ移動することが可能です。これは「MACモビリティ」や「MAC移動」と呼ばれ、与えられたMACアドレスが同じイーサネットセグメントの複数のPEから到達可能であるマルチホーミングとは異なったものです。MAC移動においては2つのMAC/IP Advertisement経路があります。1つ目は新しいイーサネットセグメントについてのもので、もう1つは元のイーサネットセグメントンとのものです。MACアドレスはこれらそれぞれのセグメントを経由して到達可能であるとされます。

EVPNインスタンス内のすべてのPEがMACアドレスの現在の場所を正しく決定することができるようにするために、元のイーサネットセグメントを経由して到達可能であるという全ての経路広告は、その経路を広告していたPEによってwithdrawされなくてはなりません(MUST)。

データプレーンを使ってローカル学習が行われていた場合、これらのPEはMACアドレスが他のイーサネットセグメントに移動したことを検知することができません。そのためMACモビリティ拡張コミュニティ属性が付与されたMAC/IP Advertisement経路を他のPEから受信することがトリガーとなって、経路広告をwithdrawすることになります。もしローカル学習がコントロールプレーンやマネージメントプレーンで行われている場合、これらの相互作用によってPEは経路広告をwithdrawします。

与えられたMACアドレスが2つのイーサネットセグメントの間で複数回移動するような状況の場合、withdrawと再広告が複数回発生します。EVPNインスタンスのすべてのPEが間にあるBGPインフラストラクチャを通してこれらのすべてを正しく受信できることを確実にするために、MACモビリティ拡張コミュニティ属性にシーケンス番号を導入することが必須となります。

モビリティのイベントを正しく処理するために、EVPNの実装はシーケンス番号の巻き戻りが起こるシナリオに対応しなければなりません(MUST)。

あるMACアドレスについてのそれぞれのMACモビリティのイベントは、次のルールを使用して設定されたシーケンス番号を含んでいます。

  • あるMACアドレスを初めて広告するPEはMACモビリティ拡張コミュニティ属性を付けずに経路を広告します。

  • PEが過去にMAC/IP Advertisement経路で受け取ったことがあるMACアドレスをローカルの別のイーサネットセグメントで検出した場合、PEは、その受信したMAC/IP Advertisement経路のMACモビリティ拡張コミュニティ属性のシーケンス番号よりも1大きいシーケンス番号をMACモビリティ拡張コミュニティ属性に設定してMAC/IP Advertisement経路を広告します。もしMACアドレスに対して最初のモビリティイベントである場合は、受信したMAC/IP Advertisement経路にはMACモビリティ拡張コミュニティ属性が付与されていないため、この処理を行うため、この経路のシーケンス番号は0であるとみなします。

  • PEが過去に、ESIが0でないMAC/IP Advertisement経路で受け取ったことがあるMACアドレスをローカルの同じESIで検知した場合、その経路を以下のように広告します

    1. 受信した経路にMACモビリティ拡張コミュニティ属性が付与されていなかった場合は付与しない
    2. 受信した経路にMACモビリティ拡張コミュニティ属性が付与されていた場合、シーケンス番号が最も大きいものと同じ値をシーケンス番号としてMACモビリティ拡張コミュニティ属性を付与する
  • PEが過去に、ESIが0であるMAC/IP Advertisement経路(シングルホームのシナリオ)で受け取ったことがあるMACアドレスをローカルの同じESIで検知した場合、シーケンス番号を適切に設定してその経路を広告します。シングルホームのシナリオの場合、ESIを比較する必要がありません。ESIの比較はマルチホーミングのシナリオで同じマルチホームのサイトに接続されたPEの間でMACアドレスの移動を誤って検知することを防ぐために行われます。

あるMACアドレスについて、PEが以前に広告した経路と比べて、異なるイーサネットセグメント識別子と大きなシーケンス番号をもったMAC/IP Advertisement経路をそのPEが受信したとき、以前に広告していたMAC/IP Advertisement経路をwithdrawします。もし2つ以上のPEが同じMACアドレスに対して同じシーケンス番号で異なるESIの経路広告を行っていた場合、それらの経路を受信したPEは最も小さいIPアドレスを持ったPEの経路をベスト経路として選択します。もしPEがMAC経路の生成者であり、同じMACアドレスに対して同じシーケンス番号を持った経路を受信した場合、PEは自身のIPアドレスとリモートPEのIPアドレスを比較して一番小さいIPアドレスのものを選択します。もし自分の経路がベストでなければ経路をwithdrawします。

15.1. MAC重複問題

同じ重複したMACアドレスが複数のホストに設定されるなどで、同じMACアドレスが別々のPEの同じVLANで学習される状況が起こりえます。このような状況ではこれらのホストから送信されるトラフィックによってPEの間でMAC移動が継続的に発生します。このような状況を認識して(MACモビリティ拡張コミュニティ属性の)シーケンス番号が無限に増加することを防ぐことが重要です。このような状況を改善するために、ローカル学習でMACモビリティイベントを検知したPEはM秒(デフォルト180秒)のタイマーを起動し、もしN回(デフォルト5回)のMAC移動をタイマーがexpireする前に検知した場合、重複MACの状況が発生していると結論づけます。PEはオペレータにアラートを上げ、正しい対応がオペレータに取られるまでの間そのMACアドレスに対する一切のBGP MAC/IP Advertisement経路の送信や処理を停止しなければなりません(MUST)。オペレータの制御に柔軟性を持たせるためMとNの値は設定可能にしなければなりません(MUST)。EVPNインスタンス内の他のPEは重複したMACアドレス宛のトラフィックをそのMACアドレスを広告しているいPEのいずれか一つに対して転送するであろうことに留意してください。

15.2. Sticky MACアドレス

MAC移動を意図していない場合のためにいくつかのMACアドレスを静的に設定したくなるようなシナリオがあるでしょう。このようなシナリオでは、これらのMACアドレスMACモビリティ拡張コミュニティにおいてstatic flagを1に設定し、シーケンス番号を0にした状態でMACアドレスが広告されます。もしPEがそのような経路広告を受信したあとに、ローカル学習によって同じMACアドレスを学習した場合、PEはオペレータにアラートをあげなくてはなりません(MUST)。

15.3. ループ防止

15.1節のEVPN MAC重複手順では重複したMACのEVPN MAC/IPの経路広告が2つ(またはそれ以上)のPEの間で永遠に交換されることを防ぎます。これがコントロールプレーンの観点で役立つのに対して、同じBDに接続された2つ以上のPEの間にバックドアリンク(ループ)が存在するようなケースにおいては、CEから送信されたBUMフレームが、バックドアリンクとPEの間でBD内で永遠にループしてしまいます。これは影響を受けるBDに接続されたCEに予期しない問題を起こす可能性があります。

15.1節のEVPN MAC重複の仕組みは、重複したMACアドレスに適用されるループ防止の動作で拡張することができます。この追加の仕組は、不慮または故意でバックドアリンクが作成されたときのループを解消するもので、BDに接続されたすべてのPEにおいて有効化されるべきです(SHOULD)。

MAC Mについての重複を検知したときに15.1節の手順を実行した後、PEは次のように動作します:

a) Mの広告を停止して重複イベントを記録します。

b) リトライタイマーをR秒で初期化します。

c) ループ防止が有効化されているので、Mを「ブラックホール」するループ防止の動作をPEは実行します。

PEがMをブリッジテーブルでブラックホールMACだと設定したとき、Mはバックドアの接続回線(AC)に関連付けられなくなり、ブラックホール宛に関連付けられます。

この点において、Mがブラックホール状態にあるとき:

a) もし送信元MACアドレスがMである新しいフレームを受信したとき、PEはM1(※訳注:M1でなくMの誤りだと思う)をブラックホールされるものであると識別子、フレームを破棄してループを終了させます。

b) 任意の動作として、送信元MACアドレスがMであるフレームを単に破棄するだけでなく、PEはフレームが最後に観測されたACをダウンさせることができます(MAY)。

c) 任意の動作として、宛先MACアドレスがMのフレームをPEが受信したときも同様に破棄するべきです(SHOULD)。

MのリトライタイマーRの期限が切れたとき、PEはブリッジテーブルからMをflushし、プロセスを再起動します。一般的には次の事象が発生したときにブラックホールMAC Mをflushすることができます:

  • (記載したように)重複MAC MのリトライタイマーRの期限が切れたとき。Mが重複MACであると検知されたときにRは初期化されます。この値は設定可能であり、EVPN MA重複のMタイマーのウィンドウの3倍の値であるべきです(SHOULD)。

  • 事業者がブラックホールMAC Mを手動でflushします。これはMが重複していると判断される状況が解決してからだけ行われるべきです。

  • リモートPEがMのMAC/IP経路をwithdrawし、他にMのMAC/IP経路が存在しないとき。

  • リモートPEがMのMAC/IP経路を(MAC Mobility拡張コミュニティの)Stickyビットを設定して更新したとき。

16. マルチキャストとブロードキャスト

特定のEVPNインスタンスに属するPEはマルチキャストトラフィックを他のPEに送信するためにIngress ReplicationまたはP2MP LSPまたはMP2MP LSPを使用することができます。

16.1. Ingress Replication

PEはBUMトラフィックをフラッでっィングするために11節の「複数宛先トラフィックの処理」で記述したようにIngress Replicationを使用することができます。与えられたブロードキャストパケットはすべてのリモートPEに送信されなくてはなりません。しかし、あるマルチキャストフローのための与えられたマルチキャストパケットは、PEのサブセットに対してのみ送信することができます。特に、与えられたマルチキャストフローは、そのマルチキャストフローに関心のなるレシーバーを収容するようなPEに対してだけ送信することができます。どのPEが与えられたマルチキャストフローのレシーバーを収容しているかはRFC7117の明示的なトラッキングI-D.ietf-bess-evpn-igmp-mld-proxyの手順を使用して決定できます。

16.2. P2MP LSPとMP2MP LSP

PEはBUMパケットを送信するためにInclusiveツリーを使用することができます。この用語はRFC7117から拝借したものです。

各種のトランスポート技術がサービスプロバイダ(SP)ネットワークで使用されています。Inclusive Pマルチキャストツリーのために、これらのトランスポート技術は、RSVP-TEやマルチポイントLDP(mLDP)やBIERで作成されたポイントツーマルチポイントのLSPを含んでいます。

16.2.1. Inclusiveツリー

SPネットワークにおいてある与えられたPE上のEVPNインスタンス内の指定された集合からのすべてのマルチキャストトラフィックを運ぶために、Inclusive(包括)マルチキャストツリーによって、Inclusive Pマルチキャストツリーと呼ばれる単一のマルチキャスト分配木を使うことができます。単一のEVPNインスタンスに属するサイトによって生成されたトラフィックを運ぶため、または、複数のEVPNインスタンスに属するサイトによって生成されたトラフィックを運ぶために、ある特定のPマルチキャストツリーを構築することができます。2つ以上のEVPNインスタンストラフィックを同じ1つのツリーで運ぶ能力は「集約(Aggregation)」という用語で表現され、このツリーをAggregate Inclusive P-multicastツリー、短縮してAggregate Inclusiveツリーと呼びます。Aggregate Inclusiveツリーは、そのツリーを使用するいずれかのEVPNインスタンスのメンバーであるそれぞれのPEを含める必要があります。これはつまりBUMトラフィックを受信することに関心があるようなレシーバーが存在しないようなPEでもそのBUMトラフィックを受信することがあることを意味します。

InclusiveツリーまたはAggregate Inclusiveツリーはこの文書ではP2MPツリーまたはMP2MPツリーとして定義されます。P2MPツリーはそのツリーのルートであるPEに接続しているEVPN CEのためのトラフィックを運ぶためだけに使われます。

Inclusiveツリーを制御するための手順はRFC7117に記述された手順と同じですが、VPLS A-D経路がInclusive Multicast Ethernet Tag経路に置き換えられます。InclusiveツリーのためのRFC7117のP-Tunnel属性は、11節「複数宛先トラフィックの処理」に記載したようにInclusive Multicast Ethernet Tag経路と共に広告されます。Aggregate Inclusiveツリーに対しては、PEはupstreamラベルまたはI-D.ietf-bess-mvpn-evpn-aggregation-labelのDCBで割り振られたラベルを使用して複数のEVPNインスタンスを同一のP2PM LSPに「集約」することができることに留意してください。集約のための手順はRFC7117に記述された手順と同じですが、VPLS A-D経路がEVPNのInclusive Multicast Ethernet Tag経路に置き換えられます。

17. 収束

この節では異なる種類のネットワーク障害からの障害復旧について記述します。

17.1. PE間のトランジットリンクとノードの障害

PEが接続する基盤におけるトランジットリンクやノードの障害が発生したときは、既存のMPLS fast-rerouteを使用することで、50msオーダーでの障害復旧を実現することができます。

17.2. PE障害

PE1とPE2にデュアルホームしているホストCE1について考えます。もしPE1で障害が発生したとき、リモートPEであるPE3は、BGPセッションの障害に基づいて障害を検知することができます。もしBGPセッションの障害を検知するためにBidirectional Forwarding Detection (BFD)を使用している場合、1秒以下での障害検知が可能です。PE3はCE1へのすべてのトラフィックをPE2だけに送信し始めるために転送状態を更新することが可能です。

17.3. PEとCEの間のネットワーク障害

マルチホームしているCEと、接続しているPEのうちの1つの間の接続性に障害が発生した場合は、そのESのために以前広告していたPEは一連のEthernet A-D per ES経路をwithdrawしなければなりません(MUST)。これによってリモートPEは、CEにトラフィックを転送するために使うことができるMPLSネクストホップの一式から、この特定のPEへのMPLSネクストホップを削除することができます。PEでMACエントリーがエージアウトしたとき、PEはBGPからそのMACアドレスをwithdrawしなければなりません(MUST)。

あるイーサネットセグメントからイーサネットタグが廃止されたとき、PEは廃止によって影響を受ける<ESI, イーサネットタグ>のために広告されていた一連のEthernet A-D per EVI経路をwithdrawしなければなりません(MUST)。加えて、PEは廃止によって影響を受けるMAC/IP Advertisement経路をwithdrawしなければなりません(MUST)。

MAC/IP Advertisement経路のwithdrawを最適化するための実装にEthernet A-D per ES経路を使用するべきです。PEが特定のEthernet A-D経路のwithdrawをその経路を広告しているPEから受信したとき、そのEthernet A-D経路内のESIと同じESIで学習したすべてのMAC/IP Advertisement経路がwithdrawされたとみなすべきです(SHOULD)。これはPEとCEの間の障害が発生したときのネットワーク収束時間を最適化します。

18. フレームの順序制御

MACアドレスの中で、(最後のMPLSラベルに続く)宛先MACアドレスの最上位オクテットの最初のnibble(8ビット目から5ビット目)の値が0x4か0x6であったとき、deep packet inspectionに基づいてECMPを行っている中間のPノードにおいて、そのイーサネットフレームはIPv4またはIPv6パケットであると誤って解釈されていまします。これにより同一のフローに属するパケットが異なるECMPパスにロードバランスされてしまい、これらのパケットは異なる遅延の影響を受けることになります。そのため同じフローに属するパケットが順序どおりに宛先に到着しない(out-of-order)可能性があります。このout-of-orderの配送は、障害が起こっていない場合の一定の状態でも起こりえて、ネットワーク運用に大きな影響を与えます。

このような18節で記載したようなフレームの順序の誤りを避けるためにネットワーク全体に及ぶ次の規則を適用します:

  • ネットワークがECMPのためにdeep packet inspectionを使用している場合、MP2P LSP越しにEVPNでカプセル化されたユニキャストパケットを送信するときは、PFC4385の"Preferred PW MPLS Control Word"を使用して、値を0に(たとえば4オクテットのフィールドをゼロ値に)するべきです(SHOULD)しなければなりません(MUST)

  • ネットワークがRFC6790のエントロピーラベルを使用している場合、MP2P LSP越しにEVPNでカプセル化されたパケットを送信するときは、control wordを使用するべきではありません(SHOULD NOT)。

  • P2MPまたはP2PRSVP-TE LSP越しにEVPNでカプセル化されたパケットを送信するときは、control wordを使用するべきではありません(SHOULD NOT)。

  • P2MP LSP(mLDPシグナリングを使用したものなど)越しにEVPNでカプセル化されたパケットを送信するときは、control wordを使用するべきです(SHOULD)。

  • ネットワークがRFC6790のエントロピーラベルを使用している場合、MP2P LSP越しにEVPNでカプセル化されたパケットを送信するときは、control wordを使用するべきではありません(SHOULD NOT)。

18.1. フローラベル

フローラベルは分割可能なフローにエントロピーを与えるために使用され、ネットワーク内にECMPロードバランスを作り出します。フローラベルは、トランジットノードがdeep packet inspectionを実行してECMPハッシュを実行する場合にネットワーク内のロードバランスをより良くするためにEVPNネットワーク内で使うことができます(MAY)。次のルールが適用されます:

  • Fビットが1に設定されているとき、そのPEはKnownユニキャストに対してフローラベルの送信と受信の両方を行うことができることを知らせています。PEがフローラベルをサポートしているとき、FビットをリモートPEから受信した際ににはKnownユニキャストパケットはフローラベルを使用してそのPEに送信しなければならず(MUST)、BUMパケットはフローラベルを使用して送信してはなりません(MUST NOT)。

  • ingress PEはフローラベルをEVPNでカプセル化されるKnownユニキャストパケットのスタックの底にpushし、Fビットを1に設定したegress PEに向けて送信します。

  • フローラベルはEVPNでカプセル化されるBUMパケットにしようしてはいけません(MUST NOT)

  • PEが2つのラベルを持つユニキャストパケットを受信したとき、[VPNラベル+ESIラベル]と[VPNラベル+フローラベル]の区別をつけることができます。オーバーラップしていたとしてもESIラベルとフローラベルの間に曖昧さがあるべきではありません。これはなぜかと言うとKnownユニキャストのために下流で割り当てられたVPNラベルは、BUMトラフィックのラベルや(もしあれば)BUMのVPNラベルの後にくるESIラベルとは異なるからです。そのためVPNラベルから、パケットを受信したPEは次のラベルがESIラベルなのかフローラベルなのかを知ることができます。つまりVPNラベルがKnownユニキャストのものであるとき、次のラベルはフローラベルでなくてはならず(MUST)、VPNラベルがBUMトラフィックのものであれば、次のラベルは、フローラベルはBUMパケットとともに送信されないため、ESIラベルでなくてはなりません(MUST)。

  • EVPNでカプセル化されたパケットをP2MP LSP(RSVP-TEでもmLDPでも)越しに送信するときには、フローラベルは使用されるべきではありません(SHOULD NOT)。これはユニキャストに適用されているL2-Attr拡張コミュニティで伝達されるFビットに依存しません。

もしネットワーク内でRFC6790に従ってエントロピーラベルが使用される場合、MP2P LSP越しにEVPNカプセル化を送信する際はcontrol wordを使用してはなりません(MUST NOT)。

19. Domain-wide Common Block (DCB)ラベルの使用

[DCB]のDCBの使用が次の場合で推奨されます:

  1. Aggregate Pマルチキャストツリー: Pマルチキャストツリーでは与えられたingress PEにおいて2つ以上のBDのトラフィックを集約することができます。集約が必要な場合、I-D.ietf-bess-mvpn-evpn-aggregation-labelのDCBラベルをInclusive Multicast Ethernet Tag経路のPMSI Tunnel属性のMPLSラベルフィールドに使用することができます(MAY)。上流で割り振られたラベルの代わりにDCBラベルを使用することで、Pマルチキャストトンネル集約が多数のブリッジドメインを持つネットワークで使用されるときに、egress PEが処理する必要のあるラベルの数を大幅に減らすことができます。

  2. BIERトンネル: I-D.ietf-bier-evpnに記載されているように、EVPNネットワークにおいてBIERトンネルとともにラベルを使用することは、集約トンネルに似ています。なぜならingress PEは上流で割り振られたラベルを使ってBDを識別するからです。I-D.ietf-bier-evpnに記載されているように、DCBラベルはPMSお Tunnelz億製の中において上流ラベルの代わりに割り振られることができ、egress PEでひるようになるラベルの数を減らすことができるようになります。

  3. ESIラベル: EVPN A-D per ES経路と共に広告されるESIラベルを一般的にはDCBラベルとして割り振ることができます(MAY)。また、P2MP/BIERトンネルの組み合わせで使用されるときにはDCBラベルとして割り振ることが推奨されます(RECOMMENDED)。

MP2MPトンネルが使用される場合、ESIラベルはDCBから割り振られなければならず(MUST)、同じイーサネットセグメントに接続されたすべてのPEにぴて同じラベルがしようされなくてはなりません。この方法で、ローカルにイーサネットセグメントを持つegress PEは受信したBUMパケットの送信元ESを識別することができます。

19. 20. セキュリティの懸念事項

Attachment Circuit(AC)越しのデータプレーンでのMAC学習とunknown unicastおよびARPメッセージをMPLS/IPコア越しにフラッディングすることについて、RFC4761とRFC4762で議論されたセキュリティの懸念事項をこの文書にも適用することができます。MPLS/IPコア越しのコントロールプレーンでのMAC学習について、RFC4364で議論されたセキュリティの懸念事項をこの文書にも適用することができます。

RFC4761で言及されているように。データプライバシーを実現してVPNでのDoS攻撃から防ぐために2つの側面があります。コントロールプレーンをセキュアにすることと転送パスを保護することです。コントロールプレーンの信用がなくなることは、PEがあるEVPNに属する顧客データを別のEVPNに送信することになったり、EVPN顧客のデータをブラックホールしたり、盗聴者に送信したりする結果になりえます。これらのいずれもデータプライバシーの観点から受け入れられるものではありません。加えて、コントロールプレーンの信用がなくなることは、認証されていないEVPNデータを使用される機会を提供することにもなります(例えば大量のトラフィックを送信することに依るDoS攻撃を増幅するためにマルチキャストツリーのトラフィック複製を不正に利用することなど)。

この文書に書かれた仕組みではBGPをコントロールプレーンに使用します。そのためRFC5925で議論されたようなテクニックはBGPメッセージを認証するために役立ち、update(EVPNトラフィックを誤ったEVPNインスタンスに転送する事ができる)やwithdraw(DoS攻撃に使用することができる)をスプーフすることを困難にします。RFC4364のマルチASバックボーンオプション(b)と(c)において、これは自律システム境界ルータ(ASBR)やPEやルートリフレクタの間のAS間BGPセッションを保護することを意味します。

BGPに対するセキュリティの懸念事項のさらなる議論は、RFC4271のBGP仕様そのものやRFC4272のセキュリティ分析の中で見つけることができます。TCP MD5シグネチャオプションをBGPセッションの保護のために使用する元々の議論はRFC5925にあります。一方でRFC6952にはBGPキーと認証問題についての分析が含まれています。

RFC5925はMPLSラベルをプライベートに保つことには役に立たないことを留意してください。ラベルを知ることによってEVPNトラフィックを盗聴することができます。このような頭頂には追加でSPネットワーク内でデータパスにアクセスできることが必要となります。VPNサービスの利用者はVPN越しに交換されるデータを保護するために(暗号化のような)適切な予防を行うことが期待されます。

データプレーンを保護するための要件の1つはMPLSラベルが正当なインターフェイスだけから受け入れられることです。PEにとって、正当なインターフェイスはPE自身のAS内の他のルータからのリンクで構成されます。ASBRにとって、正当なインターフェイスはASBR自身のAS内の他のルータからのリンクと、与えられたEVPNのインスタンスを持つAS内の他のASBRからのリンクで構成されます。マルチASのEVPNインスタンスに置いて特別に重要なことは正当なインターフェイスだけからEVPNパケットを受け入れることです。

MACアドレスを詐称するような悪意のあるトラフィックがネットワークに入ってくることを制限することも重要です。15.1節で記述した仕組みは、どのように重複したMACアドレスを検出して、継続する偽のMACモビリティを防ぐことが出来るかを示しています。15.2節で記述した仕組みは、どのようにMACアドレスを与えられたイーサネットセグメントに固定することが出来るかを示しており、それらのMACアドレスがその他のイーサネットセグメントの先に出現しても、それらのMACアドレス宛のトラフィックが他のイーサネットセグメントのEVPNネットワークに入ることを防ぐことができます。

20. 21. IANAの懸念事項

この文書でマルチプロトコル拡張を使用してBGPで運ばれる「EVPN」と呼ばれる新しいNLRIを定義しました。このNLRIは既存のAFIである25 (L2VPN)を使用します。IANAはBGP EVPNのSAFIの値として70を割り当てました。

IANAはRFC7153の次のEVPN拡張コミュニティのサブタイプを割り振り、この文書はそれらの参照に過ぎません。

      0x00     MAC Mobility                 [RFC7432]
      0x01     ESI Label                    [RFC7432]
      0x02     ES-Import Route Target       [RFC7432]

この文書はE「VPN Route Types」というレジストリを作成します。新しい登録はRFC5226で定義された「RFC Required」の手順に沿って行われるでしょう。レジストリは255の最大値をもっています。初期の登録は次のとおりです。

      0     Reserved                           [RFC7432]
      1     Ethernet Auto-discovery            [RFC7432]
      2     MAC/IP Advertisement               [RFC7432]
      3     Inclusive Multicast Ethernet Tag   [RFC7432]
      4     Ethernet Segment                   [RFC7432]

この文書では「EVPN Layer 2 Attributes Control Flags」レジストリのビット3の割り振りをFという名前で要求します:

      F     Flow Label MUST be present