draft-sajassi-bess-evpn-ac-aware-bundling-05翻訳

13272 ワード

memo tech テキストリンク

個人的なメモです

https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-ac-aware-bundling/　のdeepl翻訳＋整形

draft-sajassi-bess-evpn-ac-aware-bundling-05　AC-Aware Bundling Service Interface in EVPN

Abstract

EVPNはMPLS/IPネットワーク上で拡張性と柔軟性に優れたマルチホーミングVPNソリューションを提供し、テナントシステムやエンドデバイス（物理または仮想）間のサブネット内接続を可能にします。IRBを使用したEVPNマルチホーミングは一般的な導入シナリオの1つです。また1つのブロードキャストドメインで複数のVLAN IDを持つ複数のサブネットが必要な場合もあります。EVPN技術では異なる要件に対応する3種類のService Interfaceを定義していますが、単一のBroadcast Domain内で複数のサブネットをサポートする要件に対応するものはありません。今回のドラフトでは単一ブロードキャストドメイン内で複数のサブネットをサポートするための新しいService Interfaceを定義しています。このドラフトで提案するサービスインタフェースはマルチホーミングの場合にのみ適用されます。

Requirements Language

略

Status of This Memo

略

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem With Unicast MAC Route  . . . . . . . . . . . . .   6
     1.2.  Problem With Multicast Route Synchronization  . . . . . .   6
     1.3.  Potential Security Concern caused By Misconfiguration . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Solution Description  . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Control Plane Operation . . . . . . . . . . . . . . . . .   8
       4.1.1.  MAC/IP Address Advertisement  . . . . . . . . . . . .   8
         4.1.1.1.  Local Unicast MAC Learning  . . . . . . . . . . .   8
         4.1.1.2.  Remote Unicast MAC Learning . . . . . . . . . . .   8
       4.1.2.  Multicast Route Advertisement . . . . . . . . . . . .   8
         4.1.2.1.  Local Multicast State . . . . . . . . . . . . . .   9
         4.1.2.2.  Remote Multicast State  . . . . . . . . . . . . .   9
     4.2.  Data Plane Operation  . . . . . . . . . . . . . . . . . .   9
       4.2.1.  Unicast Forwarding  . . . . . . . . . . . . . . . . .   9
       4.2.2.  Multicast Forwarding  . . . . . . . . . . . . . . . .  10
   5.  Mis-configuration Across Multihoming Peers  . . . . . . . . .  10
   6.  BGP Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Attachment Circuit ID Extended Community  . . . . . . . .  10
     6.2.  Ethernet-tag Field vs AC ID Extended Community  . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

EVPNベースのAll-Activeマルチホーミングは、次世代データセンターおよびサービスプロバイダーのアクセス/アグリゲーションネットワークで冗長性を提供するための基本構成要素になりつつあります。EVPN IRBモードでは、単一のブロードキャストドメイン内で複数のサブネットをサポートできることが期待されるデプロイメントがあります。各サブネットはVLANによって区別されます。したがって、1つのIRBインタフェースで複数のサブネットに対応することができます。

このようなデプロイメントの背景には、以下のような動機があります。

マネージャビリティ：1つのブロードキャストドメインを使用して複数のサブネットをサポートするには、「N」個のブロードキャストドメインとIRBを管理するのに比べ、「N」個のサブネットに1つのブロードキャストドメインと1つのIRBしか必要ありません。

シンプリシティ: サブネットごとにVLAN、BD、IRBを個別に設定するのに比べ、VLAN RangeをBDとIRBで設定することにより、余分な設定を省くことができます。

[RFC7432]では3種類のサービスインタフェースを定義しています。いずれも1つのBroadcast Domain内で複数のサブネットを実現する柔軟性はありません。[RFC7432]で定義されているサービスインタフェースの種類は以下の通りです。

VLAN Based Service Interface : このService InterfaceではEVPNインスタンスは単一のブロードキャストドメイン（e.g.単一のVLAN）のみで構成されます。そのため、このInterfaceのVIDとMAC-VRFは1-to-1で紐づきます。
VLAN Bundle Service Interface : このService InterfaceではEVPNインスタンスは複数のブロードキャストドメインに対応しています（e.g. 複数のVLAN）。　ただし、MAC-VRF毎に1つのブリッジテーブルしか保持しないため、複数のVLANが同じブリッジテーブルを共有することになります。MPLSでカプセル化されたフレームは発信元のVIDでタグ付けされたままでなければなりません（MUST）。VLAN Tagの変換は許可されません。全てのEVPN経路のEthernet Tag IDは0に設定されなければなりません。
VLAN-Aware Bundle Service Interface: このService InterfaceではEVPNインスタンスは複数のブロードキャストドメイン（e.g. 複数のVLAN）で構成され、各VLANは独自のブリッジテーブルを持つため、EVPNインスタンスに対応する1つのMAC-VRFで複数のブリッジテーブル（VLANごとに1つ）が保持されるインタフェースです。

定義によると、VLAN Bundle Service Interfaceは、1つのブロードキャストドメイン内で複数のサブネットをサポートする柔軟性を備えているようです。しかし同じESから複数のサブネットをマルチホーミングでアクティブに使用することはできません。例えば、PE1がVLAN1（サブネットS1）上のH1のMACを学習する図1のケースを考えてみましょう。 PE1 は [RFC7432] に従って EVPN MAC/IP routeを生成し、Ethernet Tagは 0 に設定されます。 PE2 の IRB インターフェースからのインカミングパケットはタグなしパケットです。 PE2はPE1から広報されたEVPN MAC/IP routeから関連するAC情報を持っていません。PE2はH1に向けたトラフィックを転送することが出来ません。

このDraftは[RFC7432]で定義された既存のService Interfaceタイプを拡張するAC-aware Bundling Service Interfaceを提案します。AC-aware Bundlingサービスインタフェースは、単一のBroadcast Domainに複数のサブネットを持つためのメカニズムを提供します。この拡張は、マルチホームのEVPNピアにのみ適用されます。

Figure 1

マルチホーミングと非マルチホーミングのピアを持つEVPNトポロジー。

図1ではPE1とPE2がマルチホーミングのピアであるEVPNトポロジーの例を示しています。PE3は同じEVPNインスタンス（EVI-1）に参加しているリモートピアです。
4つのサブネットS1、S2、S3、S4が示されており、数値は関連するVLAN情報を示しています。

1.1. Problem With Unicast MAC Route

BD-1は複数のサブネットを持ち、各サブネットはVLAN1,2,3,4で区別されます。 PE1はサブネットS1に所属するACからMACアドレスMAC-1を学習します。
PE1はMAC routeを使って MAC-1 の存在をピアPEへ広報します。[RFC7432]にあるように、PE1からのMAC route広告はACとのMACアドレスの関連付けに関する情報を提供するコンテキストを持ちません。PE2はMAC-2を含むMAC routeを受信したとき、このMACがどのACに属しているかを判断することが出来ません。PE2はMAC-1を正しいACにバインドできないので、MAC-1宛のデータトラフィックを受信しても、複数のブリッジポートが同じESIを割り当てているため、宛先ACを知ることが出来ません。

1.2. Problem With Multicast Route Synchronization

[I-D.ietf-bess-evpn-igmp-mld-proxy] では、マルチホームピア間のマルチキャスト経路を同期させるためのメカニズムを定義しています。上記の場合、S1の後ろの受信者がIGMPメンバーシップ要求を送信すると、CEはそれをいずれかのPEにハッシュすることができます。マルチキャスト経路が生成されるとき、AC情報は含まれていません。ピアリングPEに到達すると、IGMPメンバーシップ要求がどのサブネットに属するかについての情報がありません。ユニキャストトラフィックの問題と同様に、IRBからのマルチキャストトラフィックは適切なACへ転送することが出来ません。

1.3. Potential Security Concern caused By Misconfiguration

ブロードキャストドメインごとにサブネットが1つである場合、セキュリティ上の問題が発生する可能性があります。例えばPE1にはBD1がVLAN-1で設定されており、マルチホームピアPE2にはBD1が VLAN-2で設定されているとします。PE1のIGMPメンバーシップ要求はPE2に同期され、PE2はマルチキャストルートを処理し、意図しない VLAN-2 にマルチキャストトラフィックを転送し始めることになります。また、ユニキャストトラフィックでも同様の問題が発生する可能性があります。

2. Terminology

AC: Attachment Circuit.

ARP: Address Resolution Protocol.

BD: Broadcast Domain.  As per [RFC7432], an EVI consists of a single or multiple BDs.  In case of VLAN-bundle and VLAN-based service models (see [RFC7432]), a BD is equivalent to an EVI.  In case of VLAN-aware bundle service model, an EVI contains multiple BDs.  Also, in this document, BD and subnet are equivalent terms.

BD Route Target: refers to the Broadcast Domain assigned Route Target [RFC4364].  In case of VLAN-aware bundle service model, all the BD instances in the MAC-VRF share the same Route Target.

BT: Bridge Table.  The instantiation of a BD in a MAC-VRF, as per [RFC7432].

Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per  [RFC7432].

EVI: EVPN Instance spanning the NVE/PE devices that are participating on that EVPN, as per [RFC7432].

EVPN: Ethernet Virtual Private Networks, as per [RFC7432].

IRB: Integrated Routing and Bridging interface.  It connects an IP-VRF to a BD (or subnet).

MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an NVE/PE, as per [RFC7432].  A MAC-VRF is also an instantiation of an EVI in an NVE/PE.

ND: Neighbor Discovery Protocol.

RD: BGP Route Distinguisher.

RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined in [RFC7432].

RT-5: EVPN route type 5, i.e., IP Prefix route.  As defined in Section 3 of [RFC9136].

SN: Subnet.

TS: Tenant System.

VLAN: The usage of VLAN refers to 802.1Q or 802.1AD tag.

(S,G): Multicast membership request

This document also assumes familiarity with the terminology of [RFC7432],[RFC8365], [RFC7365].

3. Requirements

Service Interfaceは複数のVLANが設定されたattachement-circuitを意味します。これらのVLANはそれぞれ 1つのブロードキャストドメインの下で異なるACによって表現されます。
Single Broadcast DomainはService interfaceをサポートしなければなりません(MUST)。
Service Interfaceはマルチホームピアのみに適用されなければなりません
Service Interfaceには1つのESI値を割り当てなければなりません
新しいService Interfaceの制御手順は[RFC7432]で定義された実装と下位互換性を持たなければなりません
新しいService Interfaceは[I-D.ietf-bess-evpn-igmp-mld-proxy]で定義されているEVPNマルチキャスト経路もサポートしなければなりません。

4. Solution Description

4.1. Control Plane Operation

4.1.1. MAC/IP Address Advertisement

4.1.1.1. Local Unicast MAC Learning

[RFC7432]のセクション9.1でユニキャストMACアドレスをローカル学習するための異なるメカニズムが記述されています。AC aware bundleingがサポートされているPEではMACアドレスをACに関連付けられたVLANと共に学習します。MAC/IP route構造は[RFC7432]のセクション9.2.1で定義されたメカニズムに従います。EVPN RT-2にセクション6.1で紹介するAttachment Circuit ID Extended Communityを付加しなければなりません。

4.1.1.2. Remote Unicast MAC Learning

セクション6.1で紹介するAttachment Circuit ID Extended Communityの存在は非マルチホームPEでは無視しなければなりません。リモートPE（非マルチホームPE）は[RFC7432]で定義されているようにMAC routeを学習しなければなりません。マルチホームのピアPEはリモートMACアドレスを適切なACにアタッチ出来るようにするためAttachment Circuit ID Extended Community (Section 6.1) を処理しなければなりません。Figure 1でPE2がMAC-1のMAC routeを受信します。そのときRT-2の中からAttachment Circuit ID from Attachment Circuit ID Extended Communityを取得し、MACアドレスを特定のサブネットに関連付けしなければなりません。

4.1.2. Multicast Route Advertisement

4.1.2.1. Local Multicast State

ブロードキャストドメイン内のローカルマルチホームACは、IGMPメンバーシップ要求を受信すると、[I-D.ietf-bess-evpn-igmp-mld-proxy]で定義されたマルチキャスト経路を発信してマルチキャスト状態を同期しなければなりません。 Service Interfaceが AC を意識している場合はマルチキャスト経路と一緒にAttachment Circuit ID Extended Community (Section 6.1) を付加しなければなりません。例えば、図1においてH2が(S,G)に対するIGMPメンバーシップ要求を送信すると、CEはそれをいずれかのPEにハッシュ化します。例えば、PE1が IGMP メンバーシップ要求を受け取ったとります。PE1はPE2とマルチキャストの状態を同期させるために、マルチキャストルートを生成します。マルチキャスト経路には、Attachment Circuit ID Extended Community (Section 6.1)を含めなければなりません。PE1は、同じサブネットまたは異なるサブネットのIGMPメンバーシップ要求に対して、適切なAttachment Circuit ID Extended Community (Section 6.1)を付加したマルチキャスト経路の更新を発信しなければなりません。

4.1.2.2. Remote Multicast State

マルチホームのPEが、与えられたESのブロードキャストドメイン上でリモートマルチキャストルートを受信した場合、ルートは正しいサブネットにプログラムされなければなりません。サブネット情報は、Attachment Circuit ID Extended Communityから抽出されなければなりません。その値はローカルACのVLANにマップされます。

4.2. Data Plane Operation

4.2.1. Unicast Forwarding

CEからのパケット受信は[RFC7432]セクション13.1で定義されている手順と同じでなければなりません。

CEからのUnknown Unicastは[RFC7432]セクション13.2.1.で定義されている手順と同じでなければなりません。

リモートPEで受信したKnown Unicastは[RFC7432]セクション13.2.2.の手順に従わなければなりません。Figure 1でもしPE3が送信先MACがMAC-1のKnown Unicastパケットを受信した場合、[RFC7432]セクション13.2.2.の手順に従わなければなりません。

もしknown unicastパケットに対して送信先MACのlookupが行われたとき、送信先MACのlookup処理にはVLANとローカルAC情報を提供しなければなりません。例えばPE2が送信先MACがMAC-1宛てのunicastパケットを受信したとき（そのパケットはIRBまたはEVPNトンネルを持つリモートPEからくるかもしれません）、PE2上における送信先MACのlookupは関連するVLAN値と共に送信ポートを決定しなければなりません。

4.2.2. Multicast Forwarding

CEとリモートPEからのマルチキャストトラフィックは[RFC7432]で定義されている手順に従わなければなりません。

IRBインタフェースかEVPNトンネルからマルチキャストトラフィックを受信した場合、IGMPスヌーピングの状態に基づき経路探索が行われ、適切なPEにトラフィックが転送されます。

5. Mis-configuration Across Multihoming Peers

マルチホーミングピア間でVLANまたはVLAN範囲の設定が間違っている場合、同じMACアドレスがブロードキャストドメインごとに異なるVLANで学習されることになります。この場合、オペレータが設定を変更するようにエラーメッセージを投げなければなりません。さらに、エラーとなった MAC routeは無視されなければなりません。

6. BGP Encoding

このドキュメントでは新しいEVPN用BGP Extended Communityを定義します。

6.1. Attachment Circuit ID Extended Community

Attachment Circuit IDという新しいEVPN BGP Extended Communityが導入されました。
この新しいExtended CommunityはTypeフィールドが0x06(EVPN)でSub-Typeが[TBD]なんでやねん、なトランジティブExtended Communityです。これはAC-Aware Bundling Service Interfaceでは[RFC7432]のEVPN MAC/IP Advertisement Route (Route Type 2)と共に広報されます。これはまた[I-D.ietf-bess-evpn-igmp-mld-proxy]のEVPN Multicast Route (Route Type 7 and 8)と共に広報されるでしょう。一般的に言うと、この新しいExtended Communityは特定のVLAN値の識別が必要な全ての経路に付加すべきです。

Attachment Circuit ID Extended Communityは次のように8オクテットの値としてエンコードされます。

Attachment Circuit ID Extended Community

Attachment circuit IDは正規化されたVIDの役割を果たします。これは[I-D.ietf-bess-evpn-vpws-fxc]で定義されています。

6.2. Ethernet-tag Field vs AC ID Extended Community

今回の提案はEthernet-tagフィールドがそのまま残っているため[RFC7432]のVLAN-aware bundling modeと完全に下位互換性があります。しかしこれには欠点もあります。例えばマルチキャストでは同じ(S,G)が異なるサブネットで使用される可能性があります。その場合同じルートは複数のAC ID Extended Community（Attachment Circuit ID / VLANにつき1つの）を伝播しなければなりません。VLANの数が膨大になることがあります。そんな大量のExtended Communityを伝播するためには、RDの異なる複数の経路が必要になる場合があります。このアプローチは全体的なソリューションと実装を複雑にしています。この状況を改善するためにattachment Circuit IDを0xFFFF_FFFFに設定することができます。この値はattachment Circuit IDが関連する経路のEthernet Tagフィールドの一部であることを経路のピアPEへ伝えるためのものです。EVPN経路のキーは一意であるため複数の経路前位のAC ID Extended Communityは不要となりました。これには欠点があります。PEがゼロのEthernet-Tag IDを期待している時に下位互換性の問題が発生します。

7.Security Considerations

このドキュメントにおいては[RFC7432]と同じセキュリティ考察が有効です。

8. IANA Considerations

VPN Attachment Circuit Extended Communityのため新しいトランジティブなExtended communityでTypeが0x06でSub-TypeがTBDがIANAによって割り当てられました。

Author And Source

この問題について(draft-sajassi-bess-evpn-ac-aware-bundling-05翻訳), 我々は、より多くの情報をここで見つけました https://zenn.dev/yuheiotsuka/articles/fb82ee22c5ef5a

著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。

Collection and Share based on the CC protocol

【メモ】webpack設定ファイルの書き方

宣言的UIのススメ~自作して理解する宣言的UI~