Internet Engineering Task Force (IETF) N. Malhotra, Ed.
Request for Comments: 9721 A. Sajassi
Category: Standards Track A. Pattekar
ISSN: 2070-1721 Cisco Systems
J. Rabadan
Nokia
A. Lingala
AT&T
J. Drake
Independent
April 2025
This document specifies extensions to the Ethernet VPN Integrated Routing and Bridging (EVPN-IRB) procedures specified in RFCs 7432 and 9135 to enhance the mobility mechanisms for networks based on EVPN-IRB. The proposed extensions improve the handling of host mobility and duplicate address detection in EVPN-IRB networks to cover a broader set of scenarios where a host's unicast IP address to Media Access Control (MAC) address bindings may change across moves. These enhancements address limitations in the existing EVPN-IRB mobility procedures by providing more efficient and scalable solutions. The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility.
このドキュメントは、EVPN-IRBに基づくネットワークのモビリティメカニズムを強化するために、RFCS 7432および9135で指定されたイーサネットVPN統合ルーティングおよびブリッジング（EVPN-IRB）手順への拡張機能を指定します。提案された拡張機能は、EVPN-IRBネットワークでのホストモビリティの取り扱いを改善し、EVPN-IRBネットワークのアドレス検出を重複させて、ホストのユニキャストIPアドレスがメディアアクセス制御（MAC）アドレスバインディングが移動全体に変更される可能性のある広範なシナリオをカバーします。これらの拡張機能は、より効率的でスケーラブルなソリューションを提供することにより、既存のEVPN-IRBモビリティ手順の制限に対処します。拡張機能は、既存のEVPN-IRB実装との逆方向に互換性があり、頻繁なIPアドレスモビリティを含むシナリオでネットワークパフォーマンスを最適化することを目的としています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9721.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9721で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Document Structure
2. Requirements Language and Terminology
2.1. Abbreviations
2.2. Definitions
3. Background and Problem Statement
3.1. Optional MAC-Only RT-2
3.2. Mobility Use Cases
3.2.1. Host MAC+IP Address Move
3.2.2. Host IP Address Move to New MAC Address
3.2.2.1. Host Reload
3.2.2.2. MAC Address Sharing
3.2.2.3. Problem
3.2.3. Host MAC Address Move to New IP Address
3.2.3.1. Problem
3.3. EVPN All Active Multi-Homed ES
4. Design Considerations
5. Solution Components
5.1. Sequence Number Inheritance
5.2. MAC Address Sharing
5.3. Sequence Number Synchronization
6. Methods for Sequence Number Assignment
6.1. Local MAC-IP Learning
6.2. Local MAC Learning
6.3. Remote MAC or MAC-IP Route Update
6.4. Peer-Sync-Local MAC Route Update
6.5. Peer-Sync-Local MAC-IP Route Update
6.6. Interoperability
6.7. MAC Address Sharing Race Condition
6.8. Mobility Convergence
6.8.1. Generalized Probing Logic
7. Routed Overlay
8. Duplicate Host Detection
8.1. Scenario A
8.2. Scenario B
8.2.1. Duplicate IP Detection Procedure for Scenario B
8.3. Scenario C
8.4. Duplicate Host Recovery
8.4.1. Route Unfreezing Configuration
8.4.2. Route Clearing Configuration
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
EVPN-IRB facilitates the advertisement of both MAC and IP routes via a single MAC+IP Route Type 2 (RT-2) advertisement. The MAC address is integrated into the local MAC Virtual Routing and Forwarding (MAC-VRF) bridge table, enabling Layer 2 (L2) bridged traffic across the network overlay. The IP address is incorporated into the local Address Resolution Protocol (ARP) / Neighbor Discovery Protocol (NDP) table in an asymmetric IRB design or into the IP Virtual Routing and Forwarding (IP-VRF) routing table in a symmetric IRB design. This facilitates routed traffic across the network overlay. For additional context on EVPN-IRB forwarding modes, refer to [RFC9135].
EVPN-IRBは、単一のMAC+IPルートタイプ2（RT-2）広告を介して、MACルートとIPルートの両方の広告を促進します。MACアドレスは、ローカルMAC仮想ルーティングと転送（MAC-VRF）ブリッジテーブルに統合されており、ネットワークオーバーレイ全体にレイヤー2（L2）がトラフィックをブリッジしています。IPアドレスは、非対称IRB設計のローカルアドレス解像度プロトコル（ARP） / Neighbor Discoveryプロトコル（NDP）テーブルに組み込まれている、または対称IRBデザインのIP仮想ルーティングおよび転送（IP-VRF）ルーティングテーブルに組み込まれます。これにより、ネットワークオーバーレイ全体のルーティングトラフィックが容易になります。EVPN-IRB転送モードの追加コンテキストについては、[RFC9135]を参照してください。
To support the EVPN mobility procedure, a single sequence number mobility attribute is advertised with the combined MAC+IP route. This approach, which resolves both MAC and IP reachability with a single sequence number, inherently assumes a fixed 1:1 mapping between an IP address and MAC address. While this fixed 1:1 mapping is a common use case and is addressed via the existing mobility procedure defined in [RFC7432], there are additional IRB scenarios that do not adhere to this assumption. Such scenarios are prevalent in virtualized host environments where hosts connected to an EVPN network are Virtual Machines (VMs) or containerized workloads. The following IRB mobility scenarios are considered:
EVPNモビリティ手順をサポートするために、単一のシーケンス番号モビリティ属性が、組み合わせたMAC+IPルートで宣伝されます。このアプローチは、単一のシーケンス番号でMACとIPの両方の到達可能性を解決するもので、本質的にIPアドレスとMACアドレスの間の固定1：1マッピングを想定しています。この固定された1：1マッピングは一般的なユースケースであり、[RFC7432]で定義されている既存のモビリティ手順を介して対処されていますが、この仮定に従わない追加のIRBシナリオがあります。このようなシナリオは、EVPNネットワークに接続されているホストが仮想マシン（VM）またはコンテナ化されたワークロードである仮想化ホスト環境で普及しています。次のIRBモビリティシナリオが考慮されます。
* A host move results in the host's IP address and MAC address moving together.
* ホストの移動により、ホストのIPアドレスとMACアドレスが一緒に移動します。
* A host move results in the host's IP address moving to a new MAC address association.
* ホストの移動により、ホストのIPアドレスが新しいMacアドレスアソシエーションに移動します。
* A host move results in the host's MAC address moving to a new IP address association.
* ホストの移動により、ホストのMACアドレスが新しいIPアドレスアソシエーションに移動します。
While the existing mobility procedure can manage the MAC+IP address move in the first scenario, the subsequent scenarios lead to new MAC-IP address associations. Therefore, a single sequence number assigned independently for each {MAC address, IP address} is insufficient to determine the most recent reachability for both MAC address and IP address, unless the sequence number assignment algorithm allows for changing MAC-IP address bindings across moves.
既存のモビリティ手順では、最初のシナリオでMAC+IPアドレスの移動を管理できますが、その後のシナリオは新しいMAC-IPアドレスの関連付けにつながります。したがって、各{Macアドレス、IPアドレス}に個別に割り当てられた単一のシーケンス番号は、MACアドレスとIPアドレスの両方の最新の到達可能性を決定するには不十分です。
This document updates the sequence number assignment procedures defined in [RFC7432] to 1) adequately address mobility support across EVPN-IRB overlay use cases that permit MAC-IP address bindings to change across host moves and 2) support mobility for both MAC and IP route components carried in an EVPN RT-2 for these use cases.
このドキュメントは、[RFC7432]で定義されているシーケンス番号割り当て手順を更新して、1）MAC-IPアドレスのバインディングがホストの動き全体で変化することを許可するEVPN-IRBオーバーレイユースケース全体のモビリティサポートに適切に対処します。
Additionally, for hosts on an Ethernet Segment Identifier (ESI) that is multi-homed to multiple Provider Edge (PE) devices, additional procedures are specified to ensure synchronized sequence number assignments across the multi-homing devices.
さらに、複数のプロバイダーエッジ（PE）デバイスにマルチホームされたイーサネットセグメント識別子（ESI）のホストの場合、マルチホミングデバイス全体で同期されたシーケンス番号割り当てを確保するために追加の手順が指定されています。
This document addresses mobility for the following cases, independent of the overlay encapsulation (e.g., MPLS, Segment Routing over IPv6 (SRv6), and Network Virtualization Overlay (NVO) tunnel):
このドキュメントでは、オーバーレイのカプセル化（MPLS、IPv6（SRV6）を介したセグメントルーティング、ネットワーク仮想化オーバーレイ（NVO）トンネル）とは無関係に、次のケースのモビリティに対応しています。
* Symmetric EVPN-IRB overlay
* 対称EVPN-IRBオーバーレイ
* Asymmetric EVPN-IRB overlay
* 非対称EVPN-IRBオーバーレイ
* Routed EVPN overlay
* ルーティングされたEVPNオーバーレイ
The following sections of the document are informative:
ドキュメントの次のセクションは有益です。
* Section 3 provides the necessary background and problem statement being addressed in this document.
* セクション3では、このドキュメントで扱われている必要な背景と問題の声明を示します。
* Section 4 lists the resulting design considerations for the document.
* セクション4には、ドキュメントの結果の設計上の考慮事項を示します。
* Section 5 lists the main solution components that are foundational for the specifications that follow in subsequent sections.
* セクション5には、後続のセクションで続く仕様の基礎となる主なソリューションコンポーネントを示します。
The following sections of the document are normative:
ドキュメントの次のセクションは規範的です。
* Section 6 describes the mobility and sequence number assignment procedures in an EVPN-IRB overlay that are required to address the scenarios described in Section 4.
* セクション6では、セクション4で説明したシナリオに対処するために必要なEVPN-IRBオーバーレイのモビリティおよびシーケンス番号割り当て手順について説明します。
* Section 7 describes the mobility procedures for a routed overlay network as opposed to an IRB overlay.
* セクション7では、IRBオーバーレイとは対照的に、ルーティングされたオーバーレイネットワークのモビリティ手順について説明します。
* Section 8 describes corresponding duplicate detection procedures for EVPN-IRB and routed overlays.
* セクション8では、EVPN-IRBおよびルーティングオーバーレイの対応する重複検出手順について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
ARP:
ARP:
Address Resolution Protocol [RFC0826]. ARP references in this document are equally applicable to both ARP and NDP.
アドレス解像度プロトコル[RFC0826]。このドキュメントのARP参照は、ARPとNDPの両方に等しく適用できます。
CE:
CE:
Customer Edge.
顧客のエッジ。
ES:
ES:
Ethernet Segment. A physical ethernet or LAG port that connects an access device to an EVPN PE, as defined in [RFC7432].
イーサネットセグメント。[RFC7432]で定義されているように、アクセスデバイスをEVPN PEに接続する物理イーサネットまたはLAGポート。
EVPN PE:
EVPN PE：
Ethernet VPN Provider Edge. A PE switch router in an EVPN-IRB network that runs overlay BGP-EVPN control planes and connects to overlay CE host devices. An EVPN PE may also be the first-hop L3 gateway for CE host devices. This document refers to EVPN PE as a logical function in an EVPN-IRB network. This EVPN PE function may be physically hosted on a ToR switching device or at layer(s) above the ToR in the Clos fabric. An EVPN PE is typically also an IP or MPLS tunnel endpoint for overlay VPN flows.
イーサネットVPNプロバイダーエッジ。オーバーレイBGP-EVPNコントロールプレーンを実行し、CEホストデバイスのオーバーレイに接続するEVPN-IRBネットワーク内のPEスイッチルーター。EVPN PEは、CEホストデバイスの最初のホップL3ゲートウェイでもあります。このドキュメントでは、EVPN PEをEVPN-IRBネットワークの論理関数と呼んでいます。このEVPN PE関数は、TORスイッチングデバイスまたはクローファブリックのTORの上のレイヤーで物理的にホストされる場合があります。EVPN PEは、通常、オーバーレイVPNフローのIPまたはMPLSトンネルエンドポイントでもあります。
EVPN-IRB:
EVPN-IRB：
Ethernet VPN Integrated Routing and Bridging. A BGP-EVPN distributed control plane that is based on the integrated routing and bridging fabric overlay discussed in [RFC9135].
イーサネットVPN統合ルーティングとブリッジング。[RFC9135]で説明されている統合されたルーティングとブリッジングファブリックオーバーレイに基づいたBGP-EVPN分散コントロールプレーン。
L2:
L2：
Layer 2.
レイヤー2。
L3:
L3：
Layer 3.
レイヤー3。
LAG:
LAG:
Link Aggregation Group.
リンク集約グループ。
MC-LAG:
MC-LAG：
Multi-Chassis Link Aggregation Group.
マルチシャシスリンク集約グループ。
MPLS:
MPLS：
Multiprotocol Label Switching (as specified in [RFC3031]).
マルチプロトコルラベルスイッチング（[RFC3031]で指定）。
NDP:
NDP:
Neighbor Discovery Protocol (for IPv6 [RFC4861]).
Neighbor Discoveryプロトコル（IPv6 [RFC4861]の場合）。
NVO:
NVO:
Network Virtualization Overlay.
ネットワーク仮想化オーバーレイ。
NVO3:
NVO3：
Network Virtualization over Layer 3 (as specified in [RFC8926]).
レイヤー3上のネットワーク仮想化（[RFC8926]で指定）。
PE:
PE:
Provider Edge.
プロバイダーエッジ。
RT-2:
RT-2：
Route Type 2. EVPN RT-2 carrying both MAC address and IP address reachability as specified in [RFC7432].
ルートタイプ2。EVPNRT-2 [RFC7432]で指定されているように、MACアドレスとIPアドレスの到達可能性の両方を運ぶ。
RT-5:
RT-5：
Route Type 5. EVPN RT-5 carrying IP prefix reachability as specified in [RFC9136].
ルートタイプ5。EVPNRT-5 [RFC9136]で指定されているように、IPプレフィックスの到達可能性を担当します。
SRv6:
SRV6：
Segment Routing over IPv6 (as specified in [RFC8986]).
IPv6を介したセグメントルーティング（[RFC8986]で指定）。
ToR:
ToR:
Top-of-Rack.
トップオブラック。
VM:
VM:
Virtual Machine (or containerized workloads).
仮想マシン（またはコンテナ化されたワークロード）。
VXLAN:
vxlan：
Virtual eXtensible Local Area Network (as specified in [RFC7348]).
仮想拡張可能なローカルエリアネットワーク（[RFC7348]で指定）。
Asymmetric EVPN-IRB:
非対称EVPN-IRB：
A design approach used in EVPN-based networks [RFC9135] to handle L2 and L3 forwarding. In this approach, only the ingress PE router performs routing for inter-subnet traffic, while the egress PE router performs bridging.
L2およびL3の転送を処理するために、EVPNベースのネットワーク[RFC9135]で使用される設計アプローチ。このアプローチでは、イングレスPEルーターのみがスブネット間トラフィックのルーティングを実行し、出力PEルーターはブリッジングを実行します。
EVPN all-active multi-homing:
EVPNオールアクティブマルチホミング：
A redundancy and load-sharing mechanism used in EVPN networks. This method allows multiple PE devices to simultaneously provide L2 and L3 connectivity to a single CE device or network segment.
EVPNネットワークで使用される冗長性および負荷共有メカニズム。この方法により、複数のPEデバイスが同時にL2とL3の接続を単一のCEデバイスまたはネットワークセグメントに提供できます。
Host:
ホスト：
In this document, generically refers to any user or CE endpoint attached to an EVPN-IRB network, which may be a VM, containerized workload, physical endpoint, or CE device.
このドキュメントでは、VM、コンテナ化されたワークロード、物理エンドポイント、またはCEデバイスなど、EVPN-IRBネットワークに接続されたユーザーまたはCEエンドポイントを一般的に指します。
MAC-IP address:
Mac-IPアドレス：
The IPv4 and/or IPv6 address and MAC address binding for an overlay host.
オーバーレイホストのIPv4および/またはIPv6アドレスおよびMACアドレスバインディング。
Overlay:
かぶせる：
L2 and L3 VPNs that are enabled via NVO3, VXLAN, SRv6, or MPLS service-layer encapsulation.
NVO3、VXLAN、SRV6、またはMPLSサービス層カプセル化を介して有効になっているL2およびL3 VPN。
Peer-Sync-Local MAC-IP route:
Peer-Sync-Local Mac-IPルート：
The learned BGP EVPN MAC-IP route for a host that is directly attached to a local multi-homed ES.
ローカルマルチホームESに直接接続されているホスト用の学習BGP EVPN MAC-IPルート。
Peer-Sync-Local MAC-IP sequence number:
Peer-Sync-Local Mac-IPシーケンス番号：
The sequence number received with a Peer-Sync-Local MAC-IP route.
ピアシンクローカルMAC-IPルートで受信されたシーケンス番号。
Peer-Sync-Local MAC route:
Peer-Sync-Local Macルート：
The learned BGP EVPN MAC route for a host that is directly attached to a local multi-homed ES.
ローカルマルチホームESに直接接続されているホスト用の学習BGP EVPN MACルート。
Peer-Sync-Local MAC sequence number:
Peer-Sync-Local Macシーケンス番号：
The sequence number received with a Peer-Sync-Local MAC route.
ピアシンクローカルMACルートで受信されたシーケンス番号。
Symmetric EVPN-IRB:
対称EVPN-IRB：
A specific design approach used in EVPN-based networks [RFC9135] to handle both L2 and L3 forwarding within the same network infrastructure. The key characteristic of symmetric EVPN-IRB is that both ingress and egress PE routers perform routing for inter-subnet traffic.
同じネットワークインフラストラクチャ内でL2とL3の両方の転送を処理するために、EVPNベースのネットワーク[RFC9135]で使用される特定の設計アプローチ。対称EVPN-IRBの重要な特徴は、侵入と出力の両方のPEルーターの両方が、スブネット間トラフィックのルーティングを実行することです。
Underlay:
アンダーレイ：
An IP, MPLS, or SRv6 fabric core network that provides routed reachability between EVPN PEs.
EVPN PES間のルーティングされた到達可能性を提供するIP、MPLS、またはSRV6 FABRICコアネットワーク。
In an EVPN-IRB scenario where a single MAC+IP RT-2 advertisement carries both IP and MAC routes, a MAC-only RT-2 advertisement becomes redundant for host MAC addresses already advertised via MAC+IP RT-2. Consequently, the advertisement of a local MAC-only RT-2 is optional at an EVPN PE. This consideration is important for mobility scenarios discussed in subsequent sections. It is noteworthy that a local MAC route and its assigned sequence number are still maintained locally on a PE, and only the advertisement of this route to other PEs is optional.
単一のMAC+IP RT-2広告がIPルートとMACルートの両方を搭載するEVPN-IRBシナリオでは、MacのみのRT-2広告がMac+IP RT-2を介して既に宣伝されているホストMACアドレスに冗長になります。その結果、ローカルMACのみのRT-2の広告は、EVPN PEでオプションです。この考慮事項は、後続のセクションで説明されているモビリティシナリオにとって重要です。ローカルMACルートとその割り当てられたシーケンス番号がPEで局所的に維持されていることは注目に値し、他のPESへのこのルートの広告のみがオプションです。
MAC-only RT-2 advertisements may still be issued for non-IP host MAC addresses that are not included in MAC+IP RT-2 advertisements.
MacのみのRT-2広告は、Mac+IP RT-2広告に含まれていない非IPホストMACアドレスに対して引き続き発行される場合があります。
This section outlines the IRB mobility use cases addressed in this document. Detailed procedures to handle these scenarios are provided in Sections 6 and 7. The following IRB mobility scenarios are considered:
このセクションでは、このドキュメントで扱われているIRBモビリティユースケースの概要を説明します。これらのシナリオを処理するための詳細な手順は、セクション6および7に記載されています。次のIRBモビリティシナリオを考慮してください。
* A host move results in both the host's IP and MAC addresses moving together.
* ホストの移動により、ホストのIPアドレスとMACアドレスの両方が一緒に移動します。
* A host move results in the host's IP address moving to a new MAC address association.
* ホストの移動により、ホストのIPアドレスが新しいMacアドレスアソシエーションに移動します。
* A host move results in the host's MAC address moving to a new IP address association.
* ホストの移動により、ホストのMACアドレスが新しいIPアドレスアソシエーションに移動します。
This is the baseline scenario where a host move results in both the host's MAC and IP addresses moving together without altering the MAC-IP address binding. The existing MAC route mobility procedures defined in [RFC7432] can be leveraged to support this MAC+IP address mobility scenario.
これは、ホストが移動するベースラインシナリオであり、ホストのMACアドレスとIPアドレスの両方がMAC-IPアドレスのバインディングを変更せずに一緒に移動します。[RFC7432]で定義されている既存のMACルートモビリティ手順は、このMac+IPアドレスモビリティシナリオをサポートするために活用できます。
This scenario involves a host move where the host's IP address is reassigned to a new MAC address.
このシナリオには、ホストのIPアドレスが新しいMacアドレスに再割り当てされるホストの動きが含まれます。
A host reload or orchestrated move may cause a host to be re-spawned at the same or new PE location, resulting in a new MAC address assignment while retaining the existing IP address. This results in the host's IP address moving to a new MAC address binding, as shown below:
ホストのリロードまたは組織化された移動により、ホストが同じまたは新しいPEの場所で再産業され、既存のIPアドレスを保持しながら新しいMACアドレスの割り当てが生じる場合があります。これにより、以下に示すように、ホストのIPアドレスが新しいMacアドレスバインディングに移動します。
IP-a, MAC-a ---> IP-a, MAC-b
This scenario considers cases where multiple hosts, each with a unique IP address, share a common MAC address. A host move results in a new MAC address binding for the host IP address. For example, hosts running on a single physical server might share the same MAC address. Alternatively, an L2 access network behind a firewall may have all host IP addresses learned with a common firewall MAC address. In these "shared MAC" scenarios, multiple local MAC-IP ARP/ NDP entries may be learned with the same MAC address. A host IP address move to a new physical server could result in a new MAC address association for the host IP.
このシナリオでは、それぞれが一意のIPアドレスを持つ複数のホストが共通のMACアドレスを共有する場合を検討します。ホストの移動により、ホストIPアドレスの新しいMACアドレスバインディングが生じます。たとえば、単一の物理サーバーで実行されているホストは、同じMacアドレスを共有する場合があります。あるいは、ファイアウォールの背後にあるL2アクセスネットワークには、一般的なファイアウォールMACアドレスですべてのホストIPアドレスが学習される場合があります。これらの「共有MAC」シナリオでは、同じMACアドレスで複数のローカルMAC-IP ARP/ NDPエントリが学習できます。ホストIPアドレスが新しい物理サーバーに移動すると、ホストIPの新しいMacアドレスアソシエーションが生じる可能性があります。
In the aforementioned scenarios, a combined MAC+IP EVPN RT-2 advertised with a single sequence number attribute assumes a fixed IP-to-MAC address mapping. A host IP address move to a new MAC address breaks this assumption and results in a new MAC+IP route. If this new route is independently assigned a new sequence number, the sequence number can no longer determine the most recent host IP reachability in a symmetric EVPN-IRB design or the most recent IP-to-MAC address binding in an asymmetric EVPN-IRB design.
前述のシナリオでは、単一のシーケンス番号属性を使用して宣伝されたMAC+IP EVPN RT-2の組み合わせが、固定IPからMACアドレスマッピングを想定しています。ホストIPアドレスが新しいMACアドレスに移動すると、この仮定が破損し、新しいMac+IPルートが発生します。この新しいルートに新しいシーケンス番号が独立して割り当てられている場合、シーケンス番号は、対称EVPN-IRB設計での最新のホストIPリーチ性または非対称EVPN-IRB設計での最新のIP対MACアドレスバインディングを決定できなくなります。
+------------------------+
| Underlay Network Fabric|
+------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ /
+\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+
| | |
Server-M1 Server-M2 Server-M3
| | |
VM-IP1, VM-IP2 VM-IP3, VM-IP4 VM-IP5, VM-IP6
Figure 1
Figure 1 illustrates a topology with host VMs sharing the physical server MAC address. In steady state, the IP1-M1 route is learned at PE1 and PE2 and advertised to remote PEs with a sequence number N. If VM-IP1 moves to Server-M2, ARP or NDP-based local learning at PE3 and PE4 would result in a new IP1-M2 route. If this new route is assigned a sequence number of 0, the mobility procedure for VM-IP1 will not trigger across the overlay network.
図1は、Host VMが物理サーバーMACアドレスを共有するトポロジーを示しています。定常状態では、IP1-M1ルートはPE1とPE2で学習され、シーケンス番号NでリモートPEに宣伝されます。VM-IP1がServer-M2、ARP、またはNDPベースのローカル学習にPE3およびPE4で移動すると、新しいIP1-M2ルートが発生します。この新しいルートに0のシーケンス番号が割り当てられている場合、VM-IP1のモビリティ手順はオーバーレイネットワーク全体でトリガーされません。
A sequence number assignment procedure must be defined to unambiguously determine the most recent IP address reachability, IP-to-MAC address binding, and MAC address reachability for such MAC address sharing scenarios.
シーケンス番号の割り当て手順を定義して、最新のIPアドレスの到達可能性、IP対MACアドレスバインディング、およびMACアドレスの到達可能性を明確に決定する必要があります。
This is a scenario where a host move or re-provisioning behind the same or new PE location may result in the host getting a new IP address assigned while keeping the same MAC address.
これは、ホストが同じまたは新しいPEの位置の後ろに移動したり、再プロビジョニングするシナリオであり、ホストが同じMACアドレスを維持している間に新しいIPアドレスを割り当てている場合があります。
The complication in this scenario arises because MAC address reachability can be carried via a combined MAC+IP route, whereas a MAC-only route may not be advertised. Associating a single sequence number with the MAC+IP route implicitly assumes a fixed MAC-to-IP mapping. A MAC address move that results in a new IP address association breaks this assumption and creates a new MAC+IP route. If this new route independently receives a new sequence number, the sequence number can no longer reliably indicate the most recent host MAC address reachability.
このシナリオの複雑さは、Macアドレスの到達可能性を組み合わせたMac+IPルートを介して実行できるため、MACのみのルートを宣伝できないために発生します。単一のシーケンス番号をMAC+IPルートに関連付けると、固定MAC-IPマッピングが暗黙的に想定されます。新しいIPアドレスアソシエーションにつながるMACアドレスの移動により、この仮定が破壊され、新しいMac+IPルートが作成されます。この新しいルートが独立して新しいシーケンス番号を受信した場合、シーケンス番号は、最新のホストMACアドレスの到達可能性を確実に示すことができなくなります。
+------------------------+
| Underlay Network Fabric|
+------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ /
+\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+
| | |
Server1 Server2 Server3
| | |
IP1-M1, IP2-M2 IP3-M3, IP4-M4 IP5-M5, IP6-M6
Figure 2
For instance, consider that host IP1-M1 is learned locally at PE1 and PE2 and advertised to remote hosts with sequence number N. If this host with MAC address M1 is re-provisioned at Server2 and assigned a different IP address (e.g., IP7), then the new IP7-M1 route learned at PE3 and PE4 would be advertised with sequence number 0. Consequently, L3 reachability to IP7 would be established across the overlay, but the MAC mobility procedure for M1 would not trigger due to the new MAC-IP route advertisement. Advertising an optional MAC-only route with its sequence number would trigger MAC mobility per [RFC7432]. However, without this additional advertisement, a single sequence number associated with a combined MAC+IP route may be insufficient to update MAC address reachability across the overlay.
たとえば、ホストIP1-M1はPE1とPE2でローカルで学習され、シーケンス番号Nのリモートホストに宣伝されていることを考慮してください。MACアドレスM1を持つこのホストがServer2で再構成され、別のIPアドレス（IP7など）を割り当てた場合、PE3およびPE4で学習した新しいIP7-M1ルートは、IP7の到達可能性を確立します。M1の手順は、新しいMac-IPルート広告のためにトリガーされません。シーケンス番号を備えたオプションのMac専用ルートを広告すると、[RFC7432]ごとにMacモビリティがトリガーされます。ただし、この追加広告がなければ、オーバーレイ全体でMACアドレスの到達可能性を更新するには、MAC+IPの組み合わせルートに関連付けられた単一のシーケンス番号が不十分な場合があります。
A MAC-IP route sequence number assignment procedure is required to unambiguously determine the most recent MAC address reachability in the previous scenarios without advertising a MAC-only route.
MAC-IPルートシーケンス番号割り当て手順は、Macのみのルートを宣伝せずに、以前のシナリオで最新のMacアドレスの到達可能性を明確に決定するために必要です。
Furthermore, upon learning new reachability for IP7-M1 via PE3 and PE4, PE1 and PE2 must probe and delete any local IPs associated with the MAC address M1, such as IP1-M1.
さらに、PE3およびPE4を介してIP7-M1の新しいリーチ可能性を学習すると、PE1とPE2は、IP1-M1などのMACアドレスM1に関連付けられたローカルIPをプローブして削除する必要があります。
It could be argued that the MAC mobility sequence number defined in [RFC7432] applies only to the MAC route part of a MAC-IP route, thus covering this scenario. This interpretation could serve as a clarification to [RFC7432] and supports the need for a common sequence number assignment procedure across all MAC-IP mobility scenarios detailed in this document.
[RFC7432]で定義されているMACモビリティシーケンス番号は、MAC-IPルートのMACルート部分にのみ適用され、このシナリオをカバーすると主張できます。この解釈は、[RFC7432]の明確化として機能し、このドキュメントに詳述されているすべてのMAC-IPモビリティシナリオで共通のシーケンス番号割り当て手順の必要性をサポートしています。
+------------------------+
| Underlay Network Fabric|
+------------------------+
+-----+ +-----+ +-----+ +-----+
| PE1 | | PE2 | | PE3 | | PE4 |
+-----+ +-----+ +-----+ +-----+
\\ // \\ //
\\ ESI-1 // \\ ESI-2 //
\\ // \\ //
+\\---//+ +\\---//+
| \\ // | | \\ // |
+---+---+ +---+---+
| |
CEs CEs
Figure 3
Consider an EVPN-IRB overlay network illustrated in Figure 3, where hosts are multi-homed to two or more PE devices via an all-active multi-homed ES. MAC and ARP/NDP entries learned on a local ES may also be synchronized across the multi-homing PE devices sharing this ES. This synchronization enables local switching of intra- and inter-subnet ECMP traffic flows from remote hosts. Thus, local MAC and ARP/NDP entries on a given ES may be learned through local learning and/or synchronization from another PE device sharing the same ES.
図3に示されているEVPN-IRBオーバーレイネットワークを考えてみましょう。ホストは、オールアクティブなマルチホームESを介して2つ以上のPEデバイスにマルチホームされています。ローカルESで学習したMACおよびARP/NDPエントリは、このESを共有するマルチホミングPEデバイス間で同期することもできます。この同期により、リモートホストからのSubnet Inter-SubnetおよびSubnet間のECMPトラフィックフローのローカルスイッチングが可能になります。したがって、特定のES上のローカルMACおよびARP/NDPエントリは、同じESを共有する別のPEデバイスからのローカル学習および/または同期を通じて学習できます。
For a host that is multi-homed to multiple PE devices via an all-active ES interface, the local learning of the host MAC and MAC-IP routes at each PE device is an independent asynchronous event, dependent on traffic flow or an ARP/NDP response from the host hashing to a directly connected PE on the MC-LAG interface. Consequently, the sequence number mobility attribute value assigned to a locally learned MAC or MAC-IP route at each device may not always be the same, depending on transient states on the device at the time of local learning.
オールアクティブなESインターフェイスを介して複数のPEデバイスにマルチホームされているホストの場合、各PEデバイスでのホストMACおよびMAC-IPルートのローカル学習は、MC-LAGインターフェースの直接接続されたPEへのホストハッシュからのトラフィックフローまたはARP/NDP応答に依存する独立した非同期イベントです。したがって、各デバイスでローカルで学習したMacまたはMac-IPルートに割り当てられたシーケンス番号モビリティ属性値は、ローカル学習時のデバイスの過渡状態に応じて、常に同じではない場合があります。
For example, consider a host that is deleted from ESI-2 and moved to ESI-1. It is possible for the host to be learned on PE1 following the deletion of the remote route from PE3 and PE4 while being learned on PE2 prior to the deletion of the remote route from PE3 and PE4. In this case, PE1 would process local host route learning as a new route and assign a sequence number of 0, while PE2 would process local host route learning as a remote-to-local move and assign a sequence number of N+1, where N is the existing sequence number assigned at PE3 and PE4.
たとえば、ESI-2から削除され、ESI-1に移動したホストを検討してください。PE3とPE4からのリモートルートの削除に続いて、PE3とPE4からのリモートルートの削除の前にPE2で学習されている間、ホストはPE1で学習することができます。この場合、PE1はローカルホストルート学習を新しいルートとして処理し、0のシーケンス番号を割り当て、PE2はローカルホストルート学習をリモートからローカルへの移動として処理し、n+1のシーケンス番号を割り当てます。
Inconsistent sequence numbers advertised from multi-homing devices:
マルチホミングデバイスから宣伝されている一貫性のないシーケンス番号：
* Create ambiguity regarding how remote PEs should handle paths with the same ESI but different sequence numbers. A remote PE might not program ECMP paths if it receives routes with different sequence numbers from a set of multi-homing PEs sharing the same ESI.
* リモートPEが同じESIであるが異なるシーケンス番号を持つパスをどのように処理するかについての曖昧さを作成します。リモートPEは、同じESIを共有する一連のマルチホーミングPEから異なるシーケンス番号のルートを受信した場合、ECMPパスをプログラムしない場合があります。
* Break consistent route versioning across the network overlay that is needed for EVPN mobility procedures to work.
* EVPNモビリティ手順が機能するために必要なネットワークオーバーレイを横切る一貫したルートバージョンを破ります。
For instance, in this inconsistent state, PE2 would drop a remote route received for the same host with sequence number N (since its local sequence number is N+1), while PE1 would install it as the best route (since its local sequence number is 0).
たとえば、この一貫性のない状態では、PE2は、シーケンス番号nの同じホストに対して受信したリモートルートをドロップします（ローカルシーケンス番号はn+1であるため）。
To support mobility for multi-homed hosts using the sequence number mobility attribute, local MAC and MAC-IP routes learned on a multi-homed ES must be advertised with the same sequence number by all PE devices to which the ES is multi-homed. There is a need for a mechanism to ensure the consistency of sequence numbers assigned across these PEs.
シーケンス番号モビリティ属性を使用してマルチホームのホストのモビリティをサポートするには、マルチホームのESで学習したローカルMACおよびMAC-IPルートを、ESがマルチホームのすべてのPEデバイスによって同じシーケンス番号で宣伝する必要があります。これらのPEに割り当てられたシーケンス番号の一貫性を確保するメカニズムが必要です。
To summarize, the sequence number assignment scheme and implementation must consider the following:
要約するには、シーケンス番号の割り当てスキームと実装では、以下を考慮する必要があります。
* Synchronization across multi-homing PE devices:
* マルチホミングPEデバイス全体の同期：
MAC+IP routes may be learned on an ES that is multi-homed to multiple PE devices, requiring synchronized sequence numbers across these devices.
MAC+IPルートは、複数のPEデバイスにマルチホームされたESで学習でき、これらのデバイス全体で同期されたシーケンス番号が必要です。
* Optional MAC-only RT-2:
* オプションのMacのみのRT-2：
In an IRB scenario, MAC-only RT-2 is optional and may not be advertised alongside MAC+IP RT-2.
IRBシナリオでは、MacのみのRT-2がオプションであり、Mac+IP RT-2と並んで宣伝することはできません。
* Multiple IPs associated with a single MAC:
* 単一のMACに関連付けられた複数のIP：
A single MAC address may be linked to multiple IP addresses, indicating multiple host IPs sharing a common MAC address.
単一のMACアドレスが複数のIPアドレスにリンクされている場合があり、共通のMACアドレスを共有する複数のホストIPを示しています。
* Host IP movement:
* ホストIPの動き：
A host IP address move may result in a new MAC address association, necessitating a new IP address to MAC address association and a new MAC+IP route.
ホストIPアドレスの移動により、新しいMACアドレスアソシエーションが生じる場合があり、MACアドレスアソシエーションと新しいMac+IPルートへの新しいIPアドレスが必要になります。
* Host MAC address movement:
* ホストMACアドレスの動き：
A host MAC address move may result in a new IP address association, requiring a new MAC address to IP address association and a new MAC+IP route.
ホストMACアドレスの移動により、新しいIPアドレスアソシエーションが発生する場合があり、IPアドレスアソシエーションと新しいMAC+IPルートへの新しいMacアドレスが必要になります。
* Local MAC-IP route learning via ARP/NDP:
* ARP/NDP経由のローカルMAC-IPルート学習：
Local MAC-IP route learning via ARP/NDP always accompanies a local MAC route learning event resulting from the ARP/NDP packet. However, MAC and MAC-IP route learning can occur in any order.
ARP/NDPを介したローカルMAC-IPルート学習は、常にARP/NDPパケットに起因するローカルMACルート学習イベントに付随しています。ただし、MacおよびMac-IPルートの学習は、任意の順序で発生する可能性があります。
* Separate sequence numbers for MAC and IP routes:
* MacおよびIPルートの個別のシーケンス番号：
Use cases that do not maintain a constant 1:1 MAC-IP address mapping across moves could potentially be addressed by using separate sequence numbers for MAC and IP route components of the MAC+IP route. However, maintaining two separate sequence numbers adds significant complexity, debugging challenges, and backward compatibility issues. Therefore, this document addresses these requirements using a single sequence number attribute.
MAC+IPルートのMACおよびIPルートコンポーネントに個別のシーケンス番号を使用することにより、動き全体の一定のMAC-IPアドレスマッピングを維持しないユースケースは、潜在的にアドレス指定できます。ただし、2つの個別のシーケンス番号を維持すると、大幅な複雑さ、デバッグの課題、後方互換性の問題が追加されます。したがって、このドキュメントは、単一のシーケンス番号属性を使用してこれらの要件を扱います。
This section outlines the main components of the EVPN-IRB mobility solution specified in this document. Subsequent sections will detail the exact sequence number assignment procedures based on the concepts described here.
このセクションでは、このドキュメントで指定されているEVPN-IRBモビリティソリューションの主なコンポーネントの概要を説明します。次のセクションでは、ここで説明する概念に基づいて、正確なシーケンス番号割り当て手順を詳しく説明します。
The key concept presented here is to treat a local MAC-IP route as a child of the corresponding local MAC route within the local context of a PE. This ensures that the local MAC-IP route inherits the sequence number attribute from the parent local MAC-only route. In terms of object dependencies, this could be represented as the MAC-IP route being a dependent child of the parent MAC route:
ここで紹介する重要な概念は、ローカルMAC-IPルートを、PEのローカルコンテキスト内の対応するローカルMACルートの子供として扱うことです。これにより、ローカルMAC-IPルートが親のローカルMACのみのルートからシーケンス番号属性を継承することが保証されます。オブジェクトの依存関係に関しては、これはMAC-IPルートが親MACルートの依存した子であると表現できます。
Mx-IPx -----> Mx (seq# = N)
Thus, both the parent MAC route and the child MAC-IP routes share a common sequence number associated with the parent MAC route. This ensures that a single sequence number attribute carried in a combined MAC+IP route represents the sequence number for both a MAC-only route and a MAC+IP route, making the advertisement of the MAC-only route truly optional. This enables a MAC address to assume a different IP address upon moving and still establish the most recent reachability to the MAC address across the overlay network via the mobility attribute associated with the MAC+IP route advertisement. For instance, when Mx moves to a new location, it would be assigned a higher sequence number at its new location per [RFC7432]. If this move results in Mx assuming a different IP address, IPz, the local Mx+IPz route would inherit the new sequence number from Mx.
したがって、親MACルートと子MAC-IPルートの両方が、親MACルートに関連付けられた共通のシーケンス番号を共有します。これにより、複合MAC+IPルートに搭載された単一のシーケンス番号属性が、MACのみのルートとMac+IPルートの両方のシーケンス番号を表すことが保証され、Macのみのルートの広告が本当にオプションになります。これにより、MACアドレスが移動すると異なるIPアドレスを想定し、MAC+IPルート広告に関連付けられたモビリティ属性を介してオーバーレイネットワーク全体のMACアドレスへの最新の到達可能性を確立することができます。たとえば、MXが新しい場所に移動すると、[RFC7432]ごとに新しい場所でより高いシーケンス番号が割り当てられます。この動きの結果、MXが別のIPアドレスを想定している場合、IPZ、ローカルMX+IPZルートはMXから新しいシーケンス番号を継承します。
Local MAC and local MAC-IP routes are typically sourced from data plane learning and ARP/NDP learning, respectively, and can be learned in the control plane in any order. Implementations can either replicate the inherited sequence number in each MAC-IP entry or maintain a single attribute in the parent MAC route by creating a forward reference local MAC object for cases where a local MAC-IP route is learned before the local MAC route.
ローカルMACおよびローカルMAC-IPルートは、通常、データプレーンの学習とARP/NDP学習からそれぞれ供給され、いずれの順序でコントロールプレーンで学ぶことができます。実装は、各MAC-IPエントリの継承されたシーケンス番号を複製するか、ローカルMAC-IPルートがローカルMACルートの前に学習される場合のフォワードリファレンスローカルMACオブジェクトを作成することにより、親MACルートの単一の属性を維持することができます。
For the shared MAC address scenario, multiple local MAC-IP sibling routes inherit the sequence number attribute from the common parent MAC route:
共有MACアドレスシナリオの場合、複数のローカルMAC-IP兄弟ルートが共通の親MACルートからシーケンス番号属性を継承します。
Mx-IP1 -----
| |
Mx-IP2 -----
. |
. +---> Mx (seq# = N)
. |
Mx-IPw -----
| |
Mx-IPx -----
Figure 4
In such cases, a host-IP move to a different physical server results in the IP moving to a new MAC address binding. A new MAC-IP route resulting from this move must be advertised with a sequence number higher than the previous MAC-IP route for this IP, advertised from the prior location. For example, consider a route Mx-IPx currently advertised with sequence number N from PE1. If IPx moves to a new physical server behind PE2 and is associated with MAC Mz, the new local Mz-IPx route must be advertised with a sequence number higher than N and higher than the previous Mz sequence number M. This allows PE devices, including PE1, PE2, and other remote PE devices, to determine and program the most recent MAC address binding and reachability for the IP. PE1, upon receiving this new Mz-IPx route with sequence number N+1 or M+1 (whichever is greater), would update IPx reachability via PE2 for symmetric IRB and update IPx's ARP/NDP binding to Mz for asymmetric IRB while clearing and withdrawing the stale Mx-IPx route with the lower sequence number.
そのような場合、ホストIPが異なる物理サーバーに移動すると、IPが新しいMACアドレスバインディングに移動します。この移動に起因する新しいMac-IPルートは、前の場所から宣伝されたこのIPの前のMac-IPルートよりも高いシーケンス番号で宣伝する必要があります。たとえば、PE1のシーケンス番号nで現在宣伝されているルートMX-IPXを検討してください。IPXがPE2の背後にある新しい物理サーバーに移動し、MAC MZに関連付けられている場合、新しいローカルMZ-IPXルートは、Nよりも高いシーケンス番号で以前のMZシーケンス番号Mよりも高い場合に宣伝する必要があります。PE1は、シーケンス番号N+1またはM+1（いずれか大きい方）でこの新しいMZ-IPXルートを受信すると、対称IRBのPE2を介してIPXの到達可能性を更新し、非対称IRBのIPXのARP/NDPバインディングを更新しながら、低いシーケンス数のMX-IPXルートをクリアおよび引き出します。
This implies that the sequence number associated with the local MAC route Mz and all local MAC-IP child routes of Mz at PE2 must be incremented to N+1 or M+1 if the previous Mz sequence number M is greater than N and is re-advertised across the overlay. While this re-advertisement of all local MAC-IP children routes affected by the parent MAC route adds overhead, it also avoids the need for maintaining and advertising two separate sequence number attributes for IP and MAC route components of MAC+IP RT-2. Implementations must be able to look up MAC-IP routes for a given IP and update the sequence number for its parent MAC route and for its MAC-IP route children.
これは、前のMZシーケンス数mがnより大きく、オーバーレイ全体で再承認される場合、ローカルMACルートMZおよびPE2のMZのすべてのローカルMAC-IPチャイルドルートをN+1またはM+1に増分する必要があることを意味します。Parent Mac Routeの影響を受けたすべてのローカルMAC-IP子供ルートの再承認はオーバーヘッドを追加しますが、Mac+IP RT-2のIPおよびMacルートコンポーネントの2つの別々のシーケンス番号属性を維持および宣伝する必要性も回避します。実装は、特定のIPのMAC-IPルートを検索し、親MACルートとMAC-IPルートの子供のシーケンス番号を更新できる必要があります。
To support mobility for multi-homed hosts, local MAC and MAC-IP routes learned on a shared ES must be advertised with the same sequence number by all PE devices to which the ES is multi-homed. This applies to local MAC-only routes as well. MAC and MAC-IP routes for a host that is attached to a local ES may be learned via data plane and ARP/NDP, respectively, as well as via BGP EVPN from another multi-homing PE to achieve local switching. MAC and MAC-IP routes learned via data plane and ARP/NDP are respectively referred to as local MAC routes and local MAC-IP routes. BGP EVPN learned MAC and MAC-IP routes for a host that is attached to a local ES are respectively referred to as Peer-Sync-Local MAC routes and Peer-Sync-Local MAC-IP routes as they are effectively local routes synchronized from a multi-homing peer. Local and Peer-Sync-Local route learning can occur in any order. Local MAC-IP routes advertised by all multi-homing PE devices sharing the ES must carry the same sequence number, independent of the order in which they are learned. This implies that:
マルチホームのホストのモビリティをサポートするには、共有ESで学習したローカルMACおよびMAC-IPルートを、ESがマルチホームのすべてのPEデバイスによって同じシーケンス番号で宣伝する必要があります。これは、ローカルMacのみのルートにも適用されます。ローカルESに接続されているホストのMACおよびMAC-IPルートは、それぞれデータプレーンとARP/NDPを介して学習できます。データプレーンとARP/NDPを介して学習したMACおよびMAC-IPルートは、それぞれローカルMACルートおよびローカルMAC-IPルートと呼ばれます。BGP EVPNは、ローカルESに接続されているホストのMacおよびMac-IPルートを学習しました。これは、それぞれピアシンクローカルMACルートおよびピアシンクローカルMAC-IPルートと呼ばれます。ローカルおよびピアシンクローカルルートの学習は、任意の順序で発生する可能性があります。ESを共有するすべてのマルチホミングPEデバイスによって宣伝されているローカルMAC-IPルートは、それらが学習されている順序とは無関係に、同じシーケンス番号を運ぶ必要があります。これはそれを意味します：
* On local or Peer-Sync-Local MAC-IP route learning, the sequence number for the local MAC-IP route must be compared and updated to the higher value.
* ローカルまたはピアシンクローカルMAC-IPルート学習では、ローカルMAC-IPルートのシーケンス番号を比較し、より高い値に更新する必要があります。
* On local or Peer-Sync-Local MAC route learning, the sequence number for the local MAC route must be compared and updated to the higher value.
* ローカルまたはピアシンクローカルMACルート学習では、ローカルMACルートのシーケンス番号を比較し、より高い値に更新する必要があります。
If an update to the local MAC-IP route sequence number is required as a result of the comparison with the Peer-Sync-Local MAC-IP route, it essentially amounts to a sequence number update on the parent local MAC route, resulting in an inherited sequence number update on the local MAC-IP route.
Peer-Sync-Local MAC-IPルートとの比較の結果としてローカルMAC-IPルートシーケンス番号の更新が必要な場合、基本的に親ローカルMACルートのシーケンス番号更新に相当し、ローカルMAC-IPルートの継承されたシーケンス番号更新が行われます。
The following sections specify the sequence number assignment procedures required for local MAC, local MAC-IP, Peer-Sync-Local MAC, and Peer-Sync-Local MAC-IP route learning events to achieve the outlined objectives.
次のセクションでは、ローカルMAC、ローカルMAC-IP、ピアシンクローカルMAC、およびピアシンクローカルMAC-IPルート学習イベントに必要なシーケンス番号割り当て手順を指定して、概説された目標を達成します。
A local Mx-IPx learning via ARP or NDP should result in the computation or re-computation of the parent MAC route Mx's sequence number. After this, the MAC-IP route Mx-IPx inherits the parent MAC route's sequence number. The parent MAC route Mx sequence number MUST be computed as follows:
ARPまたはNDPを介したローカルMX-IPX学習により、Parent Mac Route MXのシーケンス番号が計算または再構成されます。この後、MAC-IPルートMX-IPXは、親MACルートのシーケンス番号を継承します。親MACルートMXシーケンス番号は、次のように計算する必要があります。
* It MUST be higher than any existing remote MAC route for Mx, as per [RFC7432].
* [RFC7432]に従って、MXの既存のリモートMACルートよりも高くなければなりません。
* It MUST be at least equal to the corresponding Peer-Sync-Local MAC route sequence number, if present.
* 存在する場合は、少なくとも対応するピアシンクローカルMACルートシーケンス番号に等しくなければなりません。
* It MUST be higher than the "Mz" sequence number if the IP is also associated with a different remote MAC "Mz".
* IPが別のリモートMAC「MZ」にも関連付けられている場合、「MZ」シーケンス番号よりも高い必要があります。
Once the new sequence number for the MAC route Mx is computed as per the above criteria, all local MAC-IP routes associated with MAC Mx MUST inherit the updated sequence number.
MACルートMXの新しいシーケンス番号が上記の基準に従って計算されると、MAC MXに関連付けられたすべてのローカルMAC-IPルートが更新されたシーケンス番号を継承する必要があります。
The local MAC route Mx sequence number MUST be computed as follows:
ローカルMACルートMXシーケンス番号は、次のように計算する必要があります。
* It MUST be higher than any existing remote MAC route for Mx, as per [RFC7432].
* [RFC7432]に従って、MXの既存のリモートMACルートよりも高くなければなりません。
* It MUST be at least equal to the corresponding Peer-Sync-Local MAC route sequence number if one is present.
* 1つが存在する場合、それは少なくとも対応するピアシン - ローカルMACルートシーケンス番号に等しくなければなりません。
If the existing local MAC route sequence number is less than the Peer-Sync-Local MAC route sequence number, then the PE MUST update the local MAC route sequence number to be equal to the Peer-Sync-Local MAC route sequence number.
既存のローカルMACルートシーケンス番号がPeer-Sync-Local MACルートシーケンス番号よりも少ない場合、PEはローカルMACルートシーケンス番号をPeer-Sync-Local MACルートシーケンス番号に等しく更新する必要があります。
If the existing local MAC route sequence number is equal to or greater than the Peer-Sync-Local MAC route sequence number, no update is required to the local MAC route sequence number.
既存のローカルMACルートシーケンス番号がPeer-Sync-Local Macルートシーケンス番号以上である場合、ローカルMACルートシーケンス番号の更新は必要ありません。
Once the new sequence number for the MAC route Mx is computed as per the above criteria, all local MAC-IP routes associated with the MAC route Mx MUST inherit the updated sequence number. Note that the local MAC route sequence number might already be present if there was a local MAC-IP route learned prior to the local MAC route. In this case, the above may not result in any change in the local MAC route sequence number.
MACルートMXの新しいシーケンス番号が上記の基準に従って計算されると、MACルートMXに関連付けられたすべてのローカルMAC-IPルートが更新されたシーケンス番号を継承する必要があります。ローカルMACルートのルートがローカルMACルートの前に学習された場合、ローカルMACルートシーケンス番号が既に存在する可能性があることに注意してください。この場合、上記はローカルMACルートシーケンス番号の変更をもたらさない場合があります。
Upon receiving a remote MAC or MAC-IP route update associated with a MAC address Mx with a sequence number that is either:
MACアドレスMXに関連付けられたリモートMACまたはMAC-IPルートアップデートを受信すると、次のいずれかのシーケンス番号を使用して、
* higher than the sequence number assigned to a local route for MAC Mx or
* Mac Mxのローカルルートに割り当てられたシーケンス番号または
* equal to the sequence number assigned to a local route for MAC Mx, but the remote route is selected as best due to a lower VXLAN Tunnel End Point (VTEP) IP as per [RFC7432],
* Mac MXのローカルルートに割り当てられたシーケンス番号に等しくなりますが、[RFC7432]に従ってVXLANトンネルエンドポイント（VTEP）IPが低いため、リモートルートが最適に選択されます。
the following actions are REQUIRED on the receiving PE:
受信PEで次のアクションが必要です。
* The PE MUST trigger a probe and deletion procedure for all local MAC-IP routes associated with MAC Mx.
* PEは、MAC MXに関連付けられたすべてのローカルMAC-IPルートのプローブと削除手順をトリガーする必要があります。
* The PE MUST trigger a deletion procedure for the local MAC route for Mx.
* PEは、MXのローカルMACルートの削除手順をトリガーする必要があります。
Upon receiving a Peer-Sync-Local MAC route, the corresponding local MAC route Mx sequence number (if present) should be re-computed as follows:
ピアシンクローカルMACルートを受信すると、対応するローカルMACルートMXシーケンス番号（存在する場合）は次のように再計算する必要があります。
* If the current sequence number is less than the received Peer-Sync-Local MAC route sequence number, it MUST be increased to be equal to the received Peer-Sync-Local MAC route sequence number.
* 現在のシーケンス番号が受信されたピアシンコロカルMACルートシーケンス番号よりも少ない場合、受信されたピアシンクローカルMACルートシーケンス番号に等しくなるように増やす必要があります。
* If a local MAC route sequence number is updated as a result of the above, all local MAC-IP routes associated with MAC route Mx MUST inherit the updated sequence number.
* 上記の結果としてローカルMACルートシーケンス番号が更新された場合、MACルートMXに関連付けられたすべてのローカルMAC-IPルートは、更新されたシーケンス番号を継承する必要があります。
Because the MAC-only RT-2 advertisement is optional, receiving a Peer-Sync-Local MAC-IP route for a locally attached host results in a derived Peer-Sync-Local MAC Mx route entry. The corresponding local MAC Mx route sequence number (if present) should be re-computed as follows:
MACのみのRT-2広告はオプションであるため、ローカルに添付されたホストのピアシンクローカルMAC-IPルートを受信すると、派生したピアシンク - ローカルMAC MXルートエントリが得られます。対応するローカルMAC MXルートシーケンス番号（存在する場合）は、次のように再計算する必要があります。
* If the current sequence number is less than the received Peer-Sync-Local MAC route sequence number, it MUST be increased to be equal to the received Peer-Sync-Local MAC route sequence number.
* 現在のシーケンス番号が受信されたピアシンコロカルMACルートシーケンス番号よりも少ない場合、受信されたピアシンクローカルMACルートシーケンス番号に等しくなるように増やす必要があります。
* If a local MAC route sequence number is updated as a result of the above, all local MAC-IP routes associated with MAC route Mx MUST inherit the updated sequence number.
* 上記の結果としてローカルMACルートシーケンス番号が更新された場合、MACルートMXに関連付けられたすべてのローカルMAC-IPルートは、更新されたシーケンス番号を継承する必要があります。
Generally, if all PE nodes in the overlay network follow the above sequence number assignment procedures and the PE is advertising both MAC+IP and MAC routes, the sequence numbers advertised with the MAC and MAC+IP routes with the same MAC address would always be the same. However, an interoperability scenario with a different implementation could arise, where a non-compliant PE implementation assigns and advertises independent sequence numbers to MAC and MAC+IP routes. To handle this case, if different sequence numbers are received for remote MAC+IP routes and corresponding remote MAC routes from a remote PE, the sequence number associated with the remote MAC route MUST be:
一般に、オーバーレイネットワーク内のすべてのPEノードが上記のシーケンス番号割り当て手順に従い、PEがMac+IPとMacルートの両方を宣伝している場合、同じMacアドレスを持つMacおよびMac+IPルートで宣伝されているシーケンス番号は常に同じです。ただし、異なる実装を備えた相互運用性シナリオが発生する可能性があります。非準拠のPE実装は、MACおよびMAC+IPルートに独立したシーケンス番号を割り当てて宣伝します。このケースを処理するには、リモートMAC+IPルートとリモートPEから対応するリモートMACルートに対して異なるシーケンス番号を受信した場合、リモートMACルートに関連付けられたシーケンス番号は次のとおりです。
* computed and interpreted as the highest of all received sequence numbers with remote MAC+IP and MAC routes with the same MAC address and
* リモートMAC+IPおよび同じMACアドレスを持つMACルートを使用して、受信したすべてのシーケンス番号の中で最も高いものとして計算および解釈されます
* re-computed on a MAC or MAC+IP route withdraw as per the above.
* 上記に従って、MacまたはMac+IPルートの撤回で再計算されます。
A MAC and/or IP address move to the local PE would then result in the MAC (and hence all MAC-IP) route sequence numbers being incremented from the above computed remote MAC route sequence number.
MACおよび/またはIPアドレスがローカルPEに移動すると、MAC（およびすべてのMac-IP）ルートシーケンス番号が上記の計算されたリモートMACルートシーケンス番号から増加します。
If MAC-only routes are not advertised at all, and different sequence numbers are received with multiple MAC+IP routes for a given MAC address, the sequence number associated with the derived remote MAC route should still be computed as the highest of all received MAC+IP route sequence numbers with the same MAC address.
MACのみのルートがまったく宣伝されておらず、特定のMACアドレスの複数のMAC+IPルートで異なるシーケンス番号が受信される場合、派生リモートMACルートに関連付けられたシーケンス番号は、同じMACアドレスを持つすべての受信MAC+IPルートシーケンス番号の中で最も高いものとして計算する必要があります。
Note that it is not required for a PE to maintain explicit knowledge of a remote PE being compliant or non-compliant with this specification as long as it implements the above logic to handle remote sequence numbers that are not synchronized between MAC route and MAC-IP route(s) for the same remote MAC address.
PEが、同じリモートMACアドレスのMACルートとMac-IPルート間で同期されないリモートシーケンス番号を処理するために上記のロジックを実装する限り、この仕様に準拠または非準拠であるという明示的な知識をPEが維持する必要はないことに注意してください。
In a MAC address sharing use case described in Section 5.2, a race condition is possible with simultaneous host moves between a pair of PEs. The example scenario below illustrates this race condition and its remediation:
セクション5.2で説明されているMACアドレス共有のユースケースでは、PESのペア間のホストの同時の動きでレース条件が可能です。以下の例のシナリオは、この人種の状態とその修復を示しています。
* PE1 with locally attached host IPs I1 and I2 that share MAC address M1. As a result, PE1 has local MAC-IP routes I1-M1 and I2-M1.
* MACアドレスM1を共有する局所的に添付されたホストIPS I1およびI2を備えたPE1。その結果、PE1にはローカルMAC-IPルートI1-M1およびI2-M1があります。
* PE2 with locally attached host IPs I3 and I4 that share MAC address M2. As a result, PE2 has local MAC-IP routes I3-M2 and I4-M2.
* MACアドレスM2を共有する局所的に添付されたホストIPS I3およびI4を備えたPE2。その結果、PE2にはローカルMAC-IPルートI3-M2およびI4-M2があります。
* A simultaneous move of I1 from PE1 to PE2 and of I3 from PE2 to PE1 will cause I1's MAC address to change from M1 to M2 and cause I3's MAC address to change from M2 to M1.
* PE1からPE2へのI1とPE2からPE1へのI3の同時移動により、I1のMACアドレスがM1からM2に変更され、I3のMACアドレスがM2からM1に変更されます。
* Route I3-M1 may be learned on PE1 before I1's local entry I1-M1 has been probed out on PE1 and/or route I1-M2 may be learned on PE2 before I3's local entry I3-M2 has been probed out on PE2.
* ルートI3-M1は、I1のローカルエントリI1-M1がPE1でプローブされる前にPE1で学習できます。I3のローカルエントリI3-M2がPE2でプローブされる前に、PE2でルートI1-M2が学習できます。
* In such a scenario, MAC route sequence number assignment rules defined in Section 6.1 will cause new MAC-IP routes I1-M2 and I3-M1 to bounce between PE1 and PE2 with sequence number increments until stale entries I1-M1 and I3-M2 have been probed out from PE1 and PE2, respectively.
* このようなシナリオでは、セクション6.1で定義されているMACルートシーケンス番号割り当てルールにより、新しいMAC-IPルートI1-M2とI3-M1が、古いエントリI1-M1とI3-M2がそれぞれPE1とPE2からプローブされるまで、シーケンス数の増分でPE1とPE2の間を跳ね返します。
An implementation MUST ensure proper probing procedures to remove stale ARP, NDP, and local MAC entries, following a move, on learning remote routes as defined in Section 6.3 (and as per [RFC9135]) to minimize exposure to this race condition.
実装では、この人種への暴露を最小限に抑えるために、セクション6.3（および[RFC9135]に従って）で定義されているリモートルートを学習するために、動きに続いて、古いARP、NDP、およびローカルMACエントリを削除するための適切な調査手順を確保する必要があります。
This section is optional and details ARP and NDP probing procedures that MAY be implemented to achieve faster host relearning and convergence on mobility events. PE1 and PE2 are used as two example PEs in the network to illustrate the mobility convergence scenarios in this section.
このセクションはオプションであり、モビリティイベントのより速いホストの再学習と収束を達成するために実装される可能性のあるARPおよびNDPプロービング手順を詳細に説明します。PE1とPE2は、ネットワーク内の2つの例PEとして使用され、このセクションのモビリティ収束シナリオを説明します。
* Following a host move from PE1 to PE2, the host's MAC address is discovered at PE2 as a local MAC route via data frames received from the host. If PE2 has a prior remote MAC-IP host route for this MAC address from PE1, an ARP/NDP probe MAY be triggered at PE2 to learn the MAC-IP address as a local adjacency and trigger EVPN RT-2 advertisement for this MAC-IP address across the overlay with new reachability via PE2. This results in a reliable "event-based" host IP learning triggered by a "MAC address learning event" across the overlay, and hence, a faster convergence of overlay routed flows to the host.
* PE1からPE2へのホスト移動に続いて、ホストのMACアドレスは、ホストから受信したデータフレームを介してローカルMACルートとしてPE2で発見されます。PE2にPE1からのこのMACアドレスの以前のリモートMAC-IPホストルートがある場合、ARP/NDPプローブをPE2でトリガーして、MAC-IPアドレスをローカル隣接として学習し、PE2を介した新しいリーチ性を備えたこのMAC-IPアドレスのEVPN RT-2アドレスをトリガーできます。これにより、オーバーレイ全体にわたって「MACアドレス学習イベント」によってトリガーされる信頼性の高い「イベントベースの」ホストIP学習が行われ、したがって、オーバーレイルーティングされたフローがホストに速く収束します。
* Following a host move from PE1 to PE2, once PE1 receives a MAC or MAC-IP route from PE2 with a higher sequence number, an ARP/NDP probe MAY be triggered at PE1 to clear the stale local MAC-IP neighbor adjacency or to relearn the local MAC-IP in case the host has moved back or is duplicated.
* PE1からPE2へのホスト移動に続いて、PE1がより高いシーケンス番号を持つPE2からMACまたはMAC-IPルートを受信すると、ARP/NDPプローブをPE1でトリガーして、ホストが戻ってきた場合や重複している場合に、陳腐化したローカルMAC-IP隣接隣接性をクリアします。
* Following a local MAC route age-out, if there is a local IP adjacency with this MAC address, an ARP/NDP probe MAY be triggered for this IP to either relearn the local MAC route and maintain local L3 and L2 reachability to this host or to clear the ARP/NDP entry if the host is no longer local. This accomplishes the clearance of stale ARP/NDP entries triggered by a MAC age-out event even when the ARP/NDP refresh timer is longer than the MAC age-out timer. Clearing stale IP neighbor entries facilitates traffic convergence if the host was silent and not discovered at its new location. Once the stale neighbor entry for the host is cleared, routed traffic flow destined for the host can re-trigger ARP/NDP discovery for this host at the new location.
* ローカルMACルートの年齢に続いて、このMACアドレスにローカルIP隣接がある場合、このIPがローカルMACルートを再学習し、このホストにローカルL3とL2の到達可能性を維持するか、ホストがもはやローカルでない場合はARP/NDPエントリをクリアするために、ARP/NDPプローブがトリガーされる場合があります。これにより、ARP/NDPリフレッシュタイマーがMac Age-Outタイマーよりも長い場合でも、Mac Age-Outイベントによってトリガーされる古いARP/NDPエントリのクリアランスが達成されます。古いIPネイバーエントリをクリアすると、ホストがサイレントで、新しい場所で発見されていない場合、トラフィックの収束が容易になります。ホストの古い隣人のエントリがクリアされると、ホスト用に運命づけられたルーティングされたトラフィックフローは、新しい場所でこのホストのARP/NDP発見を再トリガーできます。
The above probing logic may be generalized as probing for an IP neighbor anytime a resolving parent MAC route is inconsistent with the MAC-IP neighbor route, where inconsistency is defined as being not present or conflicting in terms of the route source being local or remote. The MAC-IP route to parent MAC route relationship described in Section 5.1 MAY be used to achieve this logic.
上記のプロービングロジックは、解決する親MACルートがMAC-IPネイバールートと矛盾するときはいつでもIP隣人のプロービングとして一般化される場合があります。ここでは、矛盾は存在しないか、ルートソースがローカルまたはリモートであるという点で矛盾していると定義されます。セクション5.1で説明されている親MACルート関係へのMAC-IPルートは、このロジックを実現するために使用できます。
An additional use case involves traffic to an end host in the overlay being entirely IP routed. In such a purely routed overlay:
追加のユースケースには、完全にIPルーティングされているオーバーレイのエンドホストへのトラフィックが含まれます。このような純粋にルーティングされたオーバーレイで：
* A host MAC route is never advertised in the EVPN overlay control plane.
* ホストMACルートは、EVPNオーバーレイコントロールプレーンに宣伝されていません。
* Host /32 or /128 IP reachability is distributed across the overlay via EVPN Route Type 5 (RT-5) along with a zero or non-zero ESI.
* HOST /32または /128 IPリーチ可能性は、EVPNルートタイプ5（RT-5）を介してオーバーレイ全体にゼロまたは非ゼロESIを介して配布されます。
* An overlay IP subnet may still be stretched across the underlay fabric. However, intra-subnet traffic across the stretched overlay is never bridged.
* オーバーレイIPサブネットは、アンダーレイファブリック全体に引き伸ばされる場合があります。ただし、伸びたオーバーレイを横切るサブネット内トラフィックは決して橋渡しされません。
* Both inter-subnet and intra-subnet traffic in the overlay is IP routed at the EVPN PE.
* オーバーレイ内のサブネット間トラフィックとサブネット内トラフィックの両方は、EVPN PEでIPルーティングされています。
Please refer to [RFC7814] for more details.
詳細については、[RFC7814]を参照してください。
Host mobility within the stretched subnet still needs support. In the absence of host MAC routes, the sequence number mobility Extended Community specified in Section 7.7 of [RFC7432] MAY be associated with a /32 or /128 host IP prefix advertised via EVPN Route Type 5. MAC mobility procedures defined in [RFC7432] can be applied to host IP prefixes as follows:
ストレッチされたサブネット内のホストモビリティは、まだサポートが必要です。ホストMACルートがない場合、[RFC7432]のセクション7.7で指定されたシーケンス番号モビリティ拡張コミュニティは、A /32または /128ホストIPプレフィックスに関連している可能性があります。EVPNルートタイプ5を介して宣伝されています。
* On local learning of a host IP on a new ESI, the host IP MUST be advertised with a sequence number higher than what is currently advertised with the old ESI.
* 新しいESIでのホストIPのローカル学習では、ホストIPは、現在古いESIで宣伝されているものよりも高いシーケンス番号で宣伝する必要があります。
* On receiving a host IP route advertisement with a higher sequence number, a PE MUST trigger ARP/NDP probe and deletion procedures on any local route for that IP with a lower sequence number. The PE will update the forwarding entry to point to the remote route with a higher sequence number and send an ARP/NDP probe for the local IP route. If the IP has moved, the probe will time out, and the local IP host route will be deleted.
* シーケンス番号が高いホストIPルート広告を受信すると、PEは、より低いシーケンス番号を持つIPのローカルルートでARP/NDPプローブと削除手順をトリガーする必要があります。PEは転送エントリを更新して、より高いシーケンス番号でリモートルートを指すようにし、ローカルIPルートのARP/NDPプローブを送信します。IPが移動した場合、プローブはタイムアウトし、ローカルIPホストルートが削除されます。
Note that there is only one sequence number associated with a host route at any time. For previous use cases where a host MAC address is advertised along with the host IP address, a sequence number is only associated with the MAC address. If the MAC is not advertised, as in this use case, a sequence number is associated with the host IP address.
いつでもホストルートに関連付けられたシーケンス番号は1つだけであることに注意してください。ホストMACアドレスがホストIPアドレスとともに宣伝されている以前のユースケースの場合、シーケンス番号はMACアドレスにのみ関連付けられます。このユースケースのように、Macが宣伝されていない場合、シーケンス番号はホストIPアドレスに関連付けられています。
This mobility procedure does not apply to "anycast" IPv6 hosts advertised via Neighbor Advertisement (NA) messages with the Override Flag (O Flag) set to 0. Refer to [RFC9161] for more details.
このモビリティ手順は、0に設定されたオーバーライドフラグ（oフラグ）を使用して、近隣広告（NA）メッセージを介して宣伝された「Anycast」ホストには適用されません。詳細については[RFC9161]を参照してください。
Duplicate host detection scenarios across EVPN-IRB can be classified as follows:
EVPN-IRB全体の重複したホスト検出シナリオは、次のように分類できます。
* Scenario A: Two hosts have the same MAC address (host IPs may or may not be duplicates).
* シナリオA：2つのホストには同じMACアドレスがあります（ホストIPSが重複している場合とそうでない場合があります）。
* Scenario B: Two hosts have the same IP address but different MAC addresses.
* シナリオB：2つのホストには同じIPアドレスがありますが、Macアドレスが異なります。
* Scenario C: Two hosts have the same IP address, and the host MAC address is not advertised.
* シナリオC：2人のホストには同じIPアドレスがあり、ホストMACアドレスは宣伝されていません。
As specified in [RFC9161], duplicate detection procedures for Scenarios B and C do not apply to "anycast" IPv6 hosts advertised via NA messages with the Override Flag (O Flag) set to 0.
[RFC9161]で指定されているように、シナリオBおよびCの重複検出手順は、オーバーライドフラグ（Oフラグ）を0に設定してNAメッセージを介して宣伝された「Anycast」ホストには適用されません。
In cases where duplicate hosts share the same MAC address, the MAC address is detected as duplicate using the duplicate MAC address detection procedure described in [RFC7432]. Corresponding MAC-IP routes with the same MAC address do not require separate duplicate detection and MUST inherit the duplicate property from the MAC route. If a MAC route is marked as duplicate, all associated MAC-IP routes MUST also be treated as duplicates. Duplicate detection procedures need only be applied to MAC routes.
重複ホストが同じMACアドレスを共有する場合、[RFC7432]で説明されている重複したMACアドレス検出手順を使用して、MACアドレスが複製として検出されます。同じMACアドレスを持つ対応するMAC-IPルートは、個別の重複検出を必要とせず、MACルートから複製プロパティを継承する必要があります。MACルートが複製としてマークされている場合、関連するすべてのMac-IPルートも複製として扱わなければなりません。重複した検出手順は、Macルートにのみ適用する必要があります。
Misconfigurations may lead to different MAC addresses being assigned the same IP address. This scenario is not detected by the duplicate MAC address detection procedures from [RFC7432] and can result in incorrect routing of traffic destined for the IP address.
誤った装備は、同じIPアドレスが割り当てられるさまざまなMACアドレスにつながる可能性があります。このシナリオは、[RFC7432]からの重複したMACアドレス検出手順では検出されず、IPアドレスに向けられたトラフィックのルーティングが誤っている可能性があります。
Such situations, when detected locally, are identified as a move scenario through the local MAC route sequence number computation procedure described in Section 6.1:
このような状況は、ローカルで検出された場合、セクション6.1で説明されているローカルMACルートシーケンス番号計算手順を介して移動シナリオとして識別されます。
* If the IP is associated with a different remote MAC "Mz", the sequence number MUST be higher than the "Mz" sequence number.
* IPが別のリモートMAC「MZ」に関連付けられている場合、シーケンス番号は「MZ」シーケンス番号よりも高い必要があります。
This move results in a sequence number increment for the local MAC route due to the remote MAC-IP route being associated with a different MAC address, which counts as an "IP move" against the IP, independent of the MAC. The duplicate detection procedure described in [RFC7432] can then be applied to the IP entity independent of the MAC. Once an IP is detected as duplicate, the corresponding MAC-IP route should be treated as duplicate. Associated MAC routes and any other MAC-IP routes related to this MAC should not be affected.
この移動により、リモートMAC-IPルートが異なるMACアドレスに関連付けられているため、ローカルMACルートのシーケンス番号増分が発生します。[RFC7432]で説明されている重複検出手順は、MACに依存しないIPエンティティに適用できます。IPが複製として検出されると、対応するMAC-IPルートを複製として扱う必要があります。関連するMACルートおよびこのMacに関連するその他のMac-IPルートは、影響を受けるべきではありません。
The duplicate IP detection procedure for this scenario is specified in [RFC9161]. An "IP move" is further clarified as follows:
このシナリオの重複IP検出手順は、[RFC9161]で指定されています。「IP Move」は次のようにさらに明確になります。
* Upon learning a local MAC-IP route Mx-IPx, check for existing remote or local routes for IPx with a different MAC address association (Mz-IPx). If found, count this as an "IP move" for IPx, independent of the MAC.
* ローカルMAC-IPルートMX-IPXを学習すると、異なるMACアドレスアソシエーション（MZ-IPX）を使用して、IPXの既存のリモートまたはローカルルートを確認します。見つかった場合は、これをMACとは無関係にIPXの「IP Move」としてカウントします。
* Upon learning a remote MAC-IP route Mz-IPx, check for existing local routes for IPx with a different MAC address association (Mx-IPx). If found, count this as an "IP move" for IPx, independent of the MAC.
* リモートMAC-IPルートMZ-IPXを学習したら、異なるMACアドレスアソシエーション（MX-IPX）を使用してIPXの既存のローカルルートを確認します。見つかった場合は、これをMACとは無関係にIPXの「IP Move」としてカウントします。
A MAC-IP route MUST be treated as duplicate if either:
MAC-IPルートは、次の場合に複製として扱う必要があります。
* the corresponding MAC route is marked as duplicate via the existing detection procedure, or
* 対応するMACルートは、既存の検出手順を介して複製としてマークされています。
* the corresponding IP is marked as duplicate via the extended procedure described above.
* 対応するIPは、上記の拡張手順を介して複製としてマークされます。
As described in Section 7, in a purely routed overlay scenario where only a host IP is advertised via EVPN RT-5 with a sequence number mobility attribute, procedures similar to the duplicate MAC address detection procedures specified in [RFC7432] can be applied to IP-only host routes for duplicate IP detection as follows:
セクション7で説明されているように、純粋にルーティングされたオーバーレイシナリオでは、[RFC7432]で指定されている重複したMACアドレス検出手順と同様の手順を使用して、EVPN RT-5を介してホストIPのみがEVPN RT-5を介して宣伝されています。
* Upon learning a local host IP route IPx, check for existing remote or local routes for IPx with a different ESI association. If found, count this as an "IP move" for IPx.
* ローカルホストIPルートIPXを学習したら、異なるESIアソシエーションを備えたIPXの既存のリモートルートまたはローカルルートを確認します。見つかった場合は、これをIPXの「IP移動」としてカウントします。
* Upon learning a remote host IP route IPx, check for existing local routes for IPx with a different ESI association. If found, count this as an "IP move" for IPx.
* リモートホストIPルートIPXを学習したら、異なるESIアソシエーションを持つIPXの既存のローカルルートを確認します。見つかった場合は、これをIPXの「IP移動」としてカウントします。
* Using configurable parameters "N" and "M", if "N" IP moves are detected within "M" seconds for IPx, then IPx should be treated as duplicate.
* 設定可能なパラメーター "n"および "m"を使用して、「n」IPの移動がIPXの「M」秒以内に検出された場合、IPXは重複として扱う必要があります。
Once a MAC or IP address is marked as duplicate and frozen, corrective action must be taken to un-provision one of the duplicate MAC or IP addresses. Un-provisioning refers to corrective action taken on the host side. Following this correction, normal operation will not resume until the duplicate MAC or IP address ages out, unless additional action is taken to expedite recovery.
MACまたはIPアドレスが複製および冷凍としてマークされたら、是正措置を複製したMACまたはIPアドレスの1つを非プロビジョンに移動する必要があります。国連プロビジョニングとは、ホスト側で取られた是正措置を指します。この修正に続いて、回復を促進するために追加のアクションが取られない限り、重複したMACまたはIPアドレスが老化するまで、通常の操作は再開されません。
Possible additional corrective actions for faster recovery are outlined in the following sections.
より速い回復のための可能な追加の是正措置については、次のセクションで概説します。
Unfreezing the duplicate or frozen MAC or IP route via a command-line interface (CLI) can be used to recover from the duplicate and frozen state following corrective un-provisioning of the duplicate MAC or IP address. Unfreezing the MAC or IP route should result in advertising it with a sequence number higher than that advertised from the other location.
コマンドラインインターフェイス（CLI）を介して複製またはフローズンMACまたはIPルートをフリーズして、重複したMACまたはIPアドレスの修正されていない非プロビジョニングに続いて、複製および凍結状態から回復することができます。MacまたはIPルートを解除すると、他の場所から宣伝されているものよりも高いシーケンス番号で宣伝することになります。
Two scenarios exist:
2つのシナリオが存在します。
* Scenario A: The duplicate MAC or IP address is un-provisioned at the location where it was not marked as duplicate.
* シナリオA：重複したMACまたはIPアドレスは、複製としてマークされていない場所で非プロビジョニングされていません。
* Scenario B: The duplicate MAC or IP address is un-provisioned at the location where it was marked as duplicate.
* シナリオB：重複したMacまたはIPアドレスは、複製としてマークされた場所で非プロビジョニングされていません。
Unfreezing the duplicate and frozen MAC or IP route will result in recovery to a steady state as follows:
複製およびフローズンMACまたはIPルートを解凍すると、次のように定常状態に回復します。
* Scenario A: If the duplicate MAC or IP address is un-provisioned at the non-duplicate location, unfreezing the route at the frozen location results in advertising with a higher sequence number, leading to automatic clearing of the local route at the un-provisioned location via ARP/NDP PROBE and DELETE procedures.
* シナリオA：重複したMacまたはIPアドレスが非重複場所で非プロビジョニングされていない場合、凍結した場所でルートを外すと、より高いシーケンス番号で広告が発生し、ARP/NDPプローブと削除手順を介して未開発の場所でローカルルートを自動的にクリアすることになります。
* Scenario B: If the duplicate host is un-provisioned at the duplicate location, unfreezing the route triggers an advertisement with a higher sequence number to the other location, prompting relearning and clearing of the local route at the original location upon receiving the remote route advertisement.
* シナリオB：重複したホストが複製場所で非プロビジョニングされている場合、ルートを固定すると、他の場所へのシーケンス番号が高い広告をトリガーし、リモートルートの広告を受け取った後、ローカルルートの再学習とクリアを促します。
The probes referred to in these scenarios are event-driven probes resulting from receiving a route with a higher sequence number. Periodic probes resulting from refresh timers may also occur independently.
これらのシナリオで言及されているプローブは、シーケンス番号が高いルートを受信したことに起因するイベント駆動型プローブです。更新タイマーから生じる定期的なプローブも独立して発生する場合があります。
In addition to the above, route clearing CLIs may be used to clear the local MAC or IP route after the duplicate host is un-provisioned:
上記に加えて、ルートクリアCLIを使用して、重複したホストが非生成された後、ローカルMACまたはIPルートをクリアすることができます。
* Clear MAC CLI: Used to clear a duplicate MAC route.
* Clear Mac CLI：重複したMacルートをクリアするために使用されます。
* Clear ARP/NDP: Used to clear a duplicate IP route.
* Clear ARP/NDP：重複するIPルートをクリアするために使用されます。
The route unfreeze CLI may still need to be executed if the route was un-provisioned and cleared from the non-duplicate location. Given that unfreezing the route via the CLI would result in auto-clearing from the un-provisioned location, as explained earlier, using a route clearing CLI for recovery from the duplicate state is optional.
ルートが非展開されていない場合は、ルートを解凍しているCLIを実行する必要がある場合があります。CLIを介してルートを外すと、前述のように、非生成の場所から自動クリア化が行われることを考えると、重複状態からの回復のためにCLIをクリアするルートを使用することはオプションです。
The security considerations discussed in [RFC7432] and [RFC9135] apply to this document. Methods described in this document further extend the consumption of sequence numbers for IRB deployments. Hence, they are subject to the same considerations if the control plane or data plane was to be compromised. As an example, if the host-facing data plane is compromised, spoofing attempts could result in a legitimate host being perceived as moved, eventually resulting in the host being marked as duplicate. The considerations for protecting control and data planes described in [RFC7432] are equally applicable to such mobility spoofing use cases.
[RFC7432]および[RFC9135]で説明されているセキュリティ上の考慮事項は、このドキュメントに適用されます。このドキュメントで説明されている方法は、IRB展開のシーケンス番号の消費をさらに拡張します。したがって、制御プレーンまたはデータプレーンが侵害される場合、それらは同じ考慮事項の対象となります。例として、ホストに向かうデータプレーンが侵害されている場合、スプーフィングの試みは合法的なホストが移動したと認識され、最終的にホストが重複しているとマークされる可能性があります。[RFC7432]で説明されている制御面とデータプレーンを保護するための考慮事項は、そのようなモビリティスプーフィングユースケースに等しく適用できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<https://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G.,
and T. King, "Operational Aspects of Proxy ARP/ND in
Ethernet Virtual Private Networks", RFC 9161,
DOI 10.17487/RFC9161, January 2022,
<https://www.rfc-editor.org/info/rfc9161>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee,
"Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016,
<https://www.rfc-editor.org/info/rfc7814>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
The authors would like to thank Gunter Van de Velde for the significant contributions to improve the readability of this document. The authors would also like to thank Sonal Agarwal and Larry Kreeger for multiple contributions through the implementation process. The authors would like to thank Vibov Bhan and Patrice Brissette for early feedback during the implementation and testing of several procedures defined in this document. The authors would like to thank Wen Lin for a detailed review and valuable comments related to MAC sharing race conditions. The authors would also like to thank Saumya Dikshit for a detailed review and valuable comments across the document.
著者は、この文書の読みやすさを改善するための重要な貢献について、Gunter Van de Veldeに感謝したいと思います。著者はまた、実装プロセスを通じて複数の貢献についてSonal AgarwalとLarry Kreegerに感謝したいと思います。著者は、この文書で定義されているいくつかの手順の実装とテスト中の早期フィードバックについて、Vibov BhanとPatrice Brissetteに感謝したいと思います。著者は、Mac共有レース条件に関連する詳細なレビューと貴重なコメントをWen Linに感謝したいと思います。著者はまた、ドキュメント全体で詳細なレビューと貴重なコメントをしてくれたSaumya Dikshitにも感謝したいと思います。
Gunter Van de Velde
Nokia
Email: van_de_velde@nokia.com
Wen Lin
Juniper
Email: wlin@juniper.net
Sonal Agarwal
Arrcus
Email: sonal@arrcus.com
Neeraj Malhotra (editor)
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: nmalhotr@cisco.com
Ali Sajassi
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
Aparna Pattekar
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States of America
Email: apjoshi@cisco.com
Jorge Rabadan
Nokia
777 E. Middlefield Road
Mountain View, CA 94043
United States of America
Email: jorge.rabadan@nokia.com
Avinash Lingala
AT&T
3400 W Plano Pkwy
Plano, TX 75075
United States of America
Email: ar977m@att.com
John Drake
Independent
Email: je_drake@yahoo.com