Internet Engineering Task Force (IETF) P. Brissette
Request for Comments: 9722 A. Sajassi
Updates: 8584 LA. Burdet, Ed.
Category: Standards Track Cisco
ISSN: 2070-1721 J. Drake
Independent
J. Rabadan
Nokia
May 2025
The Ethernet Virtual Private Network (EVPN) solution in RFC 7432 provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying the Highest Random Weight (HRW) algorithm for DF election to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates RFC 8584 by optionally introducing delays between some of the events therein.
RFC 7432のイーサネット仮想プライベートネットワーク（EVPN）ソリューションは、マルチホームのイーサネットセグメントの指定されたフォワーダー（DF）選挙手順を提供します。これらの手順は、障害時に不必要なDFステータスの変化を避けるために、DF選挙に最高のランダム重量（HRW）アルゴリズムを適用することにより、さらに強化されています。このドキュメントは、マルチホームのイーサネットセグメントに関連付けられた失敗したリンクまたはノードの回復時に高速DF選挙を提供することにより、これらの手順を改善します。このドキュメントは、その中のいくつかのイベント間に遅延を導入することにより、RFC 8584を更新します。
The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via a simple signaling in BGP between the recovered node and each of the other nodes in the multihoming group.
このソリューションは、そのイーサネットセグメントに関連付けられたEVPNインスタンス（EVI）の数とは無関係であり、回収されたノードとマルチホームグループの他の各ノードの間のBGPでの単純なシグナル伝達を介して実行されます。
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/rfc9722.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9722で取得できます。
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. Requirements Language
1.2. Terminology
1.3. Challenges with Existing Mechanism
1.4. Design Principles for a Solution
2. DF Election Synchronization Solution
2.1. BGP Encoding
2.2. Timestamp Verification
2.3. Updates to RFC 8584
3. Synchronization Scenarios
3.1. Concurrent Recoveries
4. Backwards Compatibility
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The Ethernet Virtual Private Network (EVPN) solution [RFC7432] is widely used in data center (DC) applications for Network Virtualization Overlay (NVO) and Data Center Interconnect (DCI) services and in service provider (SP) applications for next-generation virtual private LAN services.
イーサネット仮想プライベートネットワーク（EVPN）ソリューション[RFC7432]は、ネットワーク仮想化オーバーレイ（NVO）およびデータセンターインターコネクト（DCI）サービス（DCI）サービス（DCI）サービス（SP）の次世代仮想LANサービスのためのデータセンター（DCI）サービス（DCI）サービス（DCI）のアプリケーションで広く使用されています。
[RFC7432] describes Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures are enhanced further in [RFC8584] by applying the Highest Random Weight (HRW) algorithm for DF election in order to avoid unnecessary DF status changes upon a link or node failure associated with the multihomed Ethernet Segment.
[RFC7432]は、マルチホームのイーサネットセグメントの指定されたフォワーダー（DF）選挙手順について説明しています。これらの手順は、DF選挙に最高のランダム重量（HRW）アルゴリズムを適用することにより、[RFC8584]でさらに強化され、マルチホームのイーサネットセグメントに関連するリンクまたはノード障害に対する不必要なDFステータスの変化を回避します。
This document makes further improvements to the DF election procedures in [RFC8584] by providing an option for a fast DF election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This DF election is achieved independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment, and it is performed via straightforward signaling in BGP between the recovered node and each of the other nodes in the multihomed Ethernet Segment redundancy group.
この文書は、マルチホームのイーサネットセグメントに関連付けられた失敗したリンクまたはノードの回復時にDF選挙の高速な選挙のオプションを提供することにより、[RFC8584]のDF選挙手続きをさらに改善します。このDF選挙は、そのイーサネットセグメントに関連するEVPNインスタンス（EVI）の数とは無関係に達成され、回収されたノードとマルチホームのイーサネットセグメント冗長グループの他の各ノードの間のBGPでの簡単なシグナル伝達を介して実行されます。
This document updates the DF Election Finite State Machine (FSM) described in Section 2.1 of [RFC8584] by optionally introducing delays between some events, as further detailed in Section 2.3. The solution is based on a simple one-way signaling mechanism.
このドキュメントでは、セクション2.3で詳細に説明されているように、いくつかのイベント間に遅延を導入することにより、[RFC8584]のセクション2.1で説明されているDF選挙有限ステートマシン（FSM）を更新します。ソリューションは、単純な一方向シグナル伝達メカニズムに基づいています。
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] で説明されているように解釈されます。
PE:
PE:
Provider Edge
プロバイダーエッジ
DF:
DF:
Designated Forwarder. A PE that is currently forwarding (encapsulating/decapsulating) traffic for a given VLAN in and out of a site.
指定されたフォワーダー。サイトの内外にある特定のVLANのトラフィックを現在転送（カプセル化/脱カプセル化）しているPE。
NDF:
NDF:
Non-Designated Forwarder. A PE that is currently blocking traffic (see DF above).
指定されていないフォワーダー。現在トラフィックをブロックしているPE（上記のDFを参照）。
EVI:
EVI:
EVPN Instance. It spans the PE devices participating in that EVPN.
EVPNインスタンス。そのEVPNに参加しているPEデバイスにまたがっています。
HRW:
HRW:
Highest Random Weight algorithm [HRW98]
最高のランダムウェイトアルゴリズム[HRW98]
Service carving:
サービスカービング：
This refers to DF election, as defined in [RFC7432].
これは、[RFC7432]で定義されているDF選挙を指します。
SCT:
SCT:
Service Carving Time. Defined in this document as the time at which all nodes participating in an Ethernet Segment perform DF Election.
サービスの彫刻時間。このドキュメントでは、イーサネットセグメントに参加するすべてのノードがDF選挙を行う時間として定義されています。
In EVPN technology, multiple PE devices encapsulate and decapsulate data belonging to the same VLAN. Under certain conditions, this may cause duplicated Ethernet packets and potential loops if there is a momentary overlap in forwarding roles between two or more PE devices, potentially also leading to broadcast storms of frames forwarded back into the VLAN.
EVPNテクノロジーでは、複数のPEデバイスが同じVLANに属するデータをカプセル化および脱カプセル化します。特定の条件下では、これにより、2つ以上のPEデバイス間で瞬間的な役割が瞬間的に重複する場合、重複したイーサネットパケットと潜在的なループを引き起こす可能性があり、潜在的にVLANに転送されるフレームの嵐をブロードキャストすることにもつながります。
EVPN [RFC7432] currently specifies timer-based synchronization among PE devices within an Ethernet Segment redundancy group. This approach can lead to duplications and potential loops due to multiple DFs if the timer interval is too short or can lead to packet drops if the timer interval is too long.
現在、EVPN [RFC7432]は、イーサネットセグメント冗長グループ内のPEデバイス間のタイマーベースの同期を指定しています。このアプローチは、タイマー間隔が短すぎる場合、複数のDFSによる重複と潜在的なループにつながる可能性があります。
Split-horizon filtering, as described in Section 8.3 of [RFC7432], can prevent loops but does not address duplicates. However, if there are overlapping DFs of two different sites simultaneously for the same VLAN, the site identifier will differ when the packet re-enters the Ethernet Segment. Consequently, the split-horizon check will fail, resulting in Layer 2 loops.
[RFC7432]のセクション8.3で説明されているように、スプリットホリゾンフィルタリングは、ループを防ぐことができますが、重複に対処しません。ただし、同じVLANに対して2つの異なるサイトのDFSが同時に重複している場合、パケットがイーサネットセグメントに再入力すると、サイト識別子が異なります。その結果、スプリットホリゾンのチェックが失敗し、レイヤー2ループが発生します。
The updated DF procedures outlined in [RFC8584] use the well-known HRW algorithm to prevent the reshuffling of VLANs among PE devices within the Ethernet Segment redundancy group during failure or recovery events. This approach minimizes the impact on VLANs not assigned to the failed or recovered ports and eliminates the occurrence of loops or duplicates during such events.
[RFC8584]で概説されている更新されたDF手順は、よく知られているHRWアルゴリズムを使用して、故障または回復イベント中にイーサネットセグメント冗長グループ内のPEデバイス間のVLANの再シェアリングを防ぎます。このアプローチは、故障したポートまたは回復されたポートに割り当てられていないVLANへの影響を最小限に抑え、そのようなイベント中のループまたは重複の発生を排除します。
However, upon PE insertion or a port being newly added to a multihomed Ethernet Segment, the HRW cannot help either, as a transfer of the DF role to the new port must occur while the old DF is still active.
ただし、PE挿入またはポートがマルチホームのイーサネットセグメントに新たに追加されると、HRWも役に立たないため、古いDFがまだアクティブなときに新しいポートへのDFロールの転送が発生する必要があります。
+---------+
+-------------+ | |
| | | |
/ | PE1 |----| | +-------------+
/ | | | MPLS/ | | |---CE3
/ +-------------+ | VxLAN/ | | PE3 |
CE1 - | Cloud | | |
\ +-------------+ | |---| |
\ | | | | +-------------+
\ | PE2 |----| |
| | | |
+-------------+ | |
+---------+
Figure 1: CE1 Multihomed to PE1 and PE2
図1：CE1はPE1およびPE2にマルチホームされています
In Figure 1, when PE2 is inserted in the Ethernet Segment or its CE1-facing interface is recovered, PE1 will transfer the DF role of some VLANs to PE2 to achieve load-balancing. However, because there is no handshake mechanism between PE1 and PE2, overlapping of DF roles for a given VLAN is possible, which leads to duplication of traffic as well as Layer 2 loops.
図1では、PE2がイーサネットセグメントに挿入されるか、そのCE1に直面するインターフェイスが回復すると、PE1はいくつかのVLANのDF役割をPE2に転送して、負荷分散を実現します。ただし、PE1とPE2の間に握手メカニズムがないため、特定のVLANのDF役割の重複が可能であるため、トラフィックとレイヤー2ループの複製につながります。
Current EVPN specifications [RFC7432] and [RFC8584] rely on a timer-based approach for transferring the DF role to the newly inserted device. This can cause the following issues:
現在のEVPN仕様[RFC7432]および[RFC8584]は、DFロールを新しく挿入したデバイスに転送するためのタイマーベースのアプローチに依存しています。これにより、次の問題が発生する可能性があります。
* Loops and duplicates, if the timer value is too short
* タイマーの値が短すぎる場合、ループと複製
* Prolonged traffic loss, if the timer value is too long
* タイマーの値が長すぎる場合、交通量の長期
The clock-synchronization solution for fast DF recovery presented in this document follows several design principles and offers multiple advantages, namely:
このドキュメントに示されている高速DF回復のための時計回復ソリューションは、いくつかの設計原則に従い、いくつかの利点を提供します。
* Complex handshake signaling mechanisms and state machines are avoided in favor of a simple unidirectional signaling approach.
* 複雑な握手シグナル伝達メカニズムと状態マシンは、単純な一方向のシグナル伝達アプローチを支持して回避されます。
* The fast DF recovery solution maintains backwards compatibility (see Section 4) by ensuring that PEs reject any unrecognized new BGP EVPN Extended Community.
* 高速DF回復ソリューションは、PESが認識されていない新しいBGP EVPN拡張コミュニティを拒否することを確認することにより、後方互換性（セクション4を参照）を維持します（セクション4を参照）。
* Existing DF Election algorithms remain supported.
* 既存のDF選挙アルゴリズムは引き続きサポートされています。
* The fast DF recovery solution is independent of any BGP delays in propagation of Ethernet Segment routes (Route Type 4)
* 高速DF回復ソリューションは、イーサネットセグメントルートの伝播におけるBGP遅延とは無関係です（ルートタイプ4）
* The fast DF recovery solution is agnostic of the actual time synchronization mechanism used; however, an NTP-based representation of time is used for EVPN signaling.
* 高速DF回復ソリューションは、使用される実際の時間同期メカニズムの不可知論です。ただし、NTPベースの時間表現は、EVPNシグナル伝達に使用されます。
The solution in this document relies on nodes in the topology, more specifically the peering nodes of each Ethernet-Segment, to be clock-synchronized and to advertise the Time Synchronization capability. When this is not the case, or when clocks are badly desynchronized, network convergence and DF Election is no worse than that described in [RFC7432] due to the timestamp range checking (Section 2.2).
このドキュメントのソリューションは、トポロジのノード、より具体的には各イーサネットセグメントのピアリングノードに依存して、時計回りに合わせて、時間同期機能を宣伝します。そうでない場合、またはクロックがひどく非同期化されている場合、ネットワークの収束とDF選挙は、タイムスタンプの範囲チェックのために[RFC7432]に記載されているものよりも悪くありません（セクション2.2）。
The fast DF recovery solution relies on the concept of common clock alignment between partner PEs participating in a common Ethernet Segment, i.e., PE1 and PE2 in Figure 1. The main idea is to have all peering PEs of that Ethernet Segment perform DF election and apply the result at the same previously announced time.
高速DF回復ソリューションは、一般的なイーサネットセグメントに参加しているパートナーPE、つまりPE1とPE2の共通のクロックアラインメントの概念に依存しています。主なアイデアは、そのイーサネットセグメントのすべてのピアリングPEがDF選挙を実行し、以前に発表された同じ時間に結果を適用することです。
The DF Election procedure, as described in [RFC7432] and as optionally signaled in [RFC8584], is applied. All PEs attached to a given Ethernet Segment are clock-synchronized using a networking protocol for clock synchronization (e.g., NTP, Precision Time Protocol (PTP)). Whenever possible, recovery activities for failed PEs SHOULD NOT be initiated until after the underlying clock synchronization protocol has converged to benefit from this document's fast DF recovery procedures. When a new PE is inserted in an Ethernet Segment or when a failed PE of the Ethernet Segment recovers, that PE communicates to peering partners the current time plus the value of the timer for partner discovery from step 2 in Section 8.5 of [RFC7432]. This constitutes an "end time" or "absolute time" as seen from the local PE. That absolute time is called the Service Carving Time (SCT).
[RFC7432]で説明されており、[RFC8584]でオプションで合図されているように、DF選挙手続きが適用されます。特定のイーサネットセグメントに接続されているすべてのPEは、クロック同期のためのネットワークプロトコル（NTP、Precision Time Protocol（PTP））を使用してクロック同期されます。可能な限り、故障したPESの回復活動は、基礎となるクロック同期プロトコルがこのドキュメントの高速DF回復手順の恩恵を受けるまで収束するまで開始されるべきではありません。新しいPEがイーサネットセグメントに挿入された場合、またはイーサネットセグメントのPEが故障した場合、PEはピアリングパートナーに現在の時間と、[RFC7432]のセクション8.5のステップ2からのパートナー発見のタイマーの値と通信します。これは、ローカルPEから見た「終了時間」または「絶対時間」を構成します。その絶対時間は、サービス彫刻時間（SCT）と呼ばれます。
A new BGP EVPN Extended Community, the Service Carving Time, is advertised along with the Ethernet Segment Route Type 4 (RT-4) and communicates the SCT to other partners to ensure an orderly transfer of forwarding duties.
新しいBGP EVPN拡張コミュニティであるサービス彫刻時間は、イーサネットセグメントルートタイプ4（RT-4）とともに宣伝され、SCTを他のパートナーに伝えて、転送義務の整然とした転送を確保します。
Upon receipt of the new BGP EVPN Extended Community, partner PEs can determine the SCT of the newly inserted PE. To eliminate any potential for duplicate traffic or loops, the concept of "skew" is introduced: a small time offset to ensure a controlled and orderly transition when multiple PE devices are involved. The previously inserted PE(s) must perform service carving first for NDF to DF transitions. The receiving PEs subtract this skew (default = 10 ms) to the Service Carving Time and apply NDF to DF transitions first. This is followed shortly by the NDF to DF transitions on both PEs, after the skew delay. On the recovering PE, all services are already in NDF state, and no skew for DF to NDF transitions is required.
新しいBGP EVPN拡張コミュニティを受け取ると、パートナーPESは新しく挿入されたPEのSCTを決定できます。トラフィックまたはループの重複の可能性を排除するために、「スキュー」の概念が導入されます。複数のPEデバイスが関与する場合に制御された整然とした移行を確保するための小さな時間オフセットです。以前に挿入されたPE（s）は、最初にNDFからDFへの移行のためにサービスカービングを実行する必要があります。受信PESは、このスキュー（デフォルト= 10ミリ秒）をサービス彫刻時間に減算し、最初にDF遷移にNDFを適用します。これに続いて、スキュー遅延後、両方のPESのNDFからDFへの遷移が続きます。回復中のPEでは、すべてのサービスはすでにNDF状態にあり、DFからNDFへの移行のためのゆがみは必要ありません。
This document proposes a default skew value of 10 ms to allow completion of programming the DF to NDF transitions, but implementations may make the skew larger (or configurable) taking into consideration scale, hardware capabilities, and clock accuracy.
このドキュメントでは、10ミリ秒のデフォルトのスキュー値を提案して、DFからNDFへの遷移のプログラミングの完了を可能にしますが、実装により、スケーがより大きくなる（または構成可能）、スケール、ハードウェア機能、およびクロック精度を考慮すると、スキューが大きくなる可能性があります。
To summarize, all peering PEs perform service carving almost simultaneously at the time announced by the newly added/recovered PE. The newly inserted PE initiates the SCT and triggers service carving immediately on its local timer expiry. The previously inserted PE(s) receiving Ethernet Segment route (RT-4) with an SCT BGP extended community perform service carving shortly before the SCT for DF to NDF transitions and at the SCT for NDF to DF transitions.
要約すると、すべてのピアリングPEは、新しく追加/回復したPEによって発表された時点で、ほぼ同時にサービス彫刻を実行します。新しく挿入されたPEは、SCTを開始し、ローカルタイマーの有効期限にすぐにサービスを開始します。以前に挿入されたPE（s）は、SCT BGP拡張コミュニティを備えたイーサネットセグメントルート（RT-4）を、DFからNDFへの遷移のSCTの直前、およびNDFからDFへのSCTのSCTの直前にサービス彫刻を実行します。
A BGP extended community, with Type 0x06 and Sub-Type 0x0F, is defined to communicate the SCT for each Ethernet Segment:
タイプ0x06とサブタイプ0x0Fを備えたBGP拡張コミュニティは、各イーサネットセグメントのSCTを通信するために定義されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Sub-Type(0x0F)| Timestamp Seconds ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Timestamp Seconds | Timestamp Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service Carving Time
図2：サービスの彫刻時間
The timestamp exchanged uses the NTP prime epoch of 0 h 1 January 1900 UTC [RFC5905] and an adapted form of the 64-bit NTP timestamp format.
交換されたタイムスタンプは、1900年1月1日0 H 1 1のNTPプライムエポック[RFC5905]と64ビットNTPタイムスタンプ形式の適応フォームを使用しています。
The 64-bit NTP timestamp format consists of a 32-bit unsigned seconds field and a 32-bit fraction field, which are encoded in the Service Carving Time as follows:
64ビットNTPタイムスタンプ形式は、32ビットの符号なし秒フィールドと32ビットの画分フィールドで構成されており、次のようにサービスの彫刻時間にエンコードされています。
Timestamp Seconds:
タイムスタンプ秒：
32-bit NTP seconds are encoded in this field.
このフィールドでは、32ビットNTP秒がエンコードされています。
Timestamp Fraction:
タイムスタンプ分数：
The high-order 16 bits of the NTP "Fraction" field are encoded in this field.
このフィールドでは、NTP「画分」フィールドの高次16ビットがエンコードされています。
When rebuilding a 64-bit NTP timestamp format using the values from a received SCT BGP extended community, the lower-order 16 bits of the NTP "Fraction" field are set to 0. The use of a 16-bit fractional seconds value yields adequate precision of 15 microseconds (2^-16 s).
受信したSCT BGP拡張コミュニティの値を使用して64ビットNTPタイムスタンプ形式を再構築すると、NTPの「画分」フィールドの低次の16ビットが0に設定されます。
The format of the DF Election Extended Community that is used in this document is:
このドキュメントで使用されているDF選挙の拡張コミュニティの形式は次のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Sub-Type(0x06)| RSV | DF Alg | Bitmap ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bitmap | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DF Election Extended Community (RFC 8584)
図3：DF選挙拡張コミュニティ（RFC 8584）
The Bitmap field (2 octets) encodes "capabilities" [RFC8584], where this document introduces a new Time Synchronization capability indicated by "T".
ビットマップフィールド（2オクテット）は「機能」[RFC8584]をエンコードし、このドキュメントでは「T」で示される新しい時間同期機能を導入します。
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |A| |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bitmap Field in the DF Election Extended Community
図4：DF選挙の拡張コミュニティのビットマップフィールド
Bit 3:
ビット3：
Time Synchronization (corresponds to Bit 27 of the DF Election Extended Community). When set to 1, it indicates the desire to use the Time Synchronization capability with the rest of the PEs in the Ethernet Segment.
時間同期（DF選挙拡張コミュニティのビット27に対応）。1に設定すると、イーサネットセグメントのPEの残りの部分と時間同期機能を使用したいという欲求が示されます。
This capability is utilized in conjunction with the agreed-upon DF Election Type. For instance, if all the PE devices in the Ethernet Segment indicate the desire to use the Time Synchronization capability and request the DF Election Type to be the HRW, then the HRW algorithm is used in conjunction with this capability. A PE that does not support the procedures set out in this document or that receives a route from another PE in which the capability is not set MUST NOT delay DF election as this could lead to duplicate traffic in some instances (overlapping DFs).
この機能は、合意されたDF選挙タイプと組み合わせて利用されます。たとえば、イーサネットセグメント内のすべてのPEデバイスが時間同期機能を使用し、DF選挙の種類をHRWに要求したいという要望を示している場合、HRWアルゴリズムはこの機能と組み合わせて使用されます。このドキュメントに記載されている手順をサポートしていないPEまたは、機能が設定されていない別のPEからルートを受け取るPEは、DF選挙を遅らせないでください。
The NTP Era value is not exchanged, and participating PEs may consider the timestamps to be in the same Era as their local value. A DF Election operation occurring exactly at the next Era transition will be some time on February 7, 2036. Implementors and operators may address credible cases of rollover ambiguity (adjacent Eras n and n+1) as well as the security issue of unreasonably large or unreasonably small NTP timestamps in the following manner.
NTP ERAの価値は交換されておらず、参加しているPESは、タイムスタンプが地域の価値と同じ時代にあると考えるかもしれません。次の時代の移行で正確に発生するDF選挙運用は、2036年2月7日の時間となります。実装者とオペレーターは、ロールオーバーのあいまいさ（隣接するERAS NおよびN+1）の信頼できるケースと、次の方法で不当に大きいまたは不当に小さいNTPタイムスタンプのセキュリティ問題に対処することができます。
The procedures in this document address implicitly what occurs with receiving an SCT value in the past. This would be a naturally occurring event with a large BGP propagation delay: the receiving PE treats the DF Election at the peer as having already occurred and proceeds without starting any timer to further delay service carving, effectively falling back on behavior as specified in [RFC7432]. A PE that receives an SCT value smaller than its current time MUST discard the Service Carving Time and SHALL treat the DF Election at the peer as having occurred already.
このドキュメントの手順は、過去にSCT値を受信することで発生することを暗黙的に扱います。これは、BGP伝播遅延が大きい自然に発生するイベントです。受信PEは、ピアでDF選挙をすでに発生していると扱い、[RFC7432]で指定された行動に事実上戻るために、タイマーをさらに遅らせることなく進行します。現在の時刻よりも小さいSCT値を受け取るPEは、サービスの彫刻時間を破棄し、ピアでのDF選挙をすでに発生しているように扱う必要があります。
The more problematic scenario is the PE in Era n+1 that receives an SCT advertised by the PE still in Era n, with a very large SCT value. To address this Era rollover as well as the large values attack vector, implementations MUST validate the received SCT against an upper bound.
より問題のあるシナリオは、非常に大きなSCT値を持つ、ERA NでStillによって宣伝されているSCTを受け取るERA N+1のPEです。この時代のロールオーバーと大きな値攻撃ベクトルに対処するには、実装は受信したSCTを上限に対して検証する必要があります。
It is left to implementations to decide what constitutes an "unreasonably large" SCT value. A recommended approach, however, is to compare the received offset to the local peering timer value. In practice, peering timer values are configured uniformly across Ethernet Segment peers and may be treated as an upper bound on the offset of received SCT values. A PE that receives an SCT representing an offset larger than the local peering timer MUST discard the SCT and SHALL treat the DF Election at the peer as having already occurred, as above.
「不当に大きい」SCT値を構成するものを決定するために、実装に任されています。ただし、推奨されるアプローチは、受信したオフセットをローカルピアリングタイマーの値と比較することです。実際には、ピアリングタイマー値はイーサネットセグメントピア全体で均一に構成されており、受信したSCT値のオフセットの上限として扱われる場合があります。ローカルピアリングタイマーよりも大きいオフセットを表すSCTを受け取るPEは、SCTを破棄し、上記のようにピアでDF選挙を既に発生したと扱う必要があります。
This document introduces an additional delay to the events and transitions defined for the default DF election algorithm FSM in Section 2.1 of [RFC8584] without changing the FSM state or event definitions themselves.
このドキュメントでは、FSM状態またはイベントの定義自体を変更せずに、[RFC8584]のセクション2.1のデフォルトのDF選挙アルゴリズムFSMで定義されたイベントと移行の追加の遅延を紹介します。
Upon receiving an RCVD_ES message, the peering PE's FSM transitions from the DF_DONE state (indicating the DF election process was complete) to the DF_CALC state (indicating that a new DF calculation is needed). Due to the SCT included in the Ethernet Segment update, the completion of the DF_CALC state and the subsequent transition back to the DF_DONE state are delayed. This delay ensures proper synchronization and prevents conflicts. Consequently, the accompanying forwarding updates to the DF and NDF states are also deferred.
RCVD_ESメッセージを受信すると、ピアリングPEのFSMはDF_DONE状態（DF選挙プロセスが完了したことを示す）からDF_CALC状態（新しいDF計算が必要であることを示しています）に移行します。イーサネットセグメントの更新に含まれているSCTにより、DF_CALC状態の完了とその後のDF_DONE状態への遷移が遅れます。この遅延は、適切な同期を保証し、競合を防ぎます。その結果、DFおよびNDF状態への転送の付随する更新も延期されます。
Item 9 in Section 2.1 of [RFC8584], in the list "Corresponding actions when transitions are performed or states are entered/exited", is changed as follows:
[RFC8584]のセクション2.1の項目9、リスト「遷移が実行されたとき、または状態が入力/退出されるときの対応するアクション」は、次のように変更されます。
9. DF_CALC on CALCULATED: Mark the election result for the VLAN or VLAN bundle.
9. 計算されたDF_CALC：VLANまたはVLANバンドルの選挙結果をマークします。
9.1 If no Service Carving Time is present during the RCVD_ES event of Action 11, proceed to step 9.4
9.1 RCVD_ESアクション11のイベント中にサービスの彫刻時間がない場合は、ステップ9.4に進みます
9.2 If a Service Carving Time is present during the RCVD_ES event of Action 11, wait until the time indicated by the SCT minus skew before proceeding to step 9.3.
9.2 RCVD_ESアクション11のイベント中にサービスの彫刻時間が存在する場合は、SCTマイナススキューが示す時間までステップ9.3に進む前に待ちます。
9.3 Assume the role of NDF for the local PE concerning the VLAN or VLAN bundle. Wait the remaining skew time before proceeding to step 9.4.
9.3 VLANまたはVLANバンドルに関するローカルPEのNDFの役割を仮定します。ステップ9.4に進む前に、残りのスキュー時間を待ちます。
9.4 Assume the election result's role (DF or NDF) for the local PE concerning the VLAN or VLAN bundle and transition to the DF_DONE state.
9.4 VLANまたはVLANバンドルに関するローカルPEの選挙結果の役割（DFまたはNDF）がDF_Done状態に移行すると仮定します。
This revised approach ensures proper timing and synchronization in the DF election process, avoiding conflicts and ensuring accurate forwarding updates.
この改訂されたアプローチにより、DFの選挙プロセスにおける適切なタイミングと同期が保証され、紛争を回避し、正確な転送の更新を確保します。
Consider Figure 1 as an example, where initially PE2 has failed and PE1 has taken over. This scenario illustrates the problem with the DF Election mechanism described in Section 8.5 of [RFC7432], specifically in the context of the timer value configured for all PEs on the Ethernet Segment.
図1を例として考えてみましょう。最初にPE2が失敗し、PE1が引き継いでいる。このシナリオは、[RFC7432]のセクション8.5で説明されているDF選挙メカニズムの問題を示しています。特に、イーサネットセグメント上のすべてのPESで構成されたタイマー値のコンテキストです。
The following procedure is based on Section 8.5 of [RFC7432] with the default 3-second timer in step 2.
次の手順は、[RFC7432]のセクション8.5に基づいており、ステップ2のデフォルトの3秒のタイマーがあります。
1. Initial state: PE1 is in a steady-state and PE2 is recovering.
1. 初期状態：PE1は定常状態にあり、PE2は回復しています。
2. Recovery: PE2 recovers at an absolute time of t=99.
2. 回復：PE2はt = 99の絶対時間に回復します。
3. Advertisement: PE2 advertises RT-4, sent at t=100, to its partner (PE1).
3. 広告：PE2は、T = 100で送信されたRT-4をパートナー（PE1）に広告します。
4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 from other PE nodes.
4. タイマーの開始：PE2は、他のPEノードからRT-4を受信できるように3秒のタイマーを起動します。
5. Immediate carving: PE1 performs service carving immediately upon RT-4 reception, i.e., t=100 plus some BGP propagation delay.
5. 即時の彫刻：PE1は、RT-4受信の直後にサービス彫刻を実行します。つまり、T = 100とBGP伝播遅延です。
6. Delayed Carving: PE2 performs service carving at time t=103.
6. 遅延彫刻：PE2は、時間t = 103でサービス彫刻を実行します。
[RFC7432] favors traffic drops over duplicate traffic. With the above procedure, traffic drops will occur as part of each PE recovery sequence since PE1 transitions some VLANs to an NDF immediately upon RT-4 reception. The timer value (default = 3 seconds) directly affects the duration of the packet drops. A shorter (or zero) timer may result in duplicate traffic or traffic loops.
[RFC7432]は、重複するトラフィックよりもトラフィックの低下を支持します。上記の手順では、PE1がRT-4受信の直後にいくつかのVLANをNDFに遷移するため、各PE回復シーケンスの一部としてトラフィックドロップが発生します。タイマー値（デフォルト= 3秒）は、パケットドロップの持続時間に直接影響します。短い（またはゼロ）タイマーは、トラフィックまたはトラフィックループが重複する場合があります。
The following procedure is based on the SCT approach:
次の手順は、SCTアプローチに基づいています。
1. Initial state: PE1 is in a steady state, and PE2 is recovering.
1. 初期状態：PE1は定常状態にあり、PE2は回復しています。
2. Recovery: PE2 recovers at an absolute time of t=99.
2. 回復：PE2はt = 99の絶対時間に回復します。
3. Timer Start: PE2 starts at t=100 a 3-second timer to allow the reception of RT-4 from other PE nodes.
3. タイマーの開始：PE2はt = 100 A 3秒のタイマーから始まり、他のPEノードからRT-4を受信できるようにします。
4. Advertisement: PE2 advertises RT-4, sent at t=100, with a target SCT value of t=103 to its partner (PE1).
4. 広告：PE2は、T = 100で送信されたRT-4を広告し、ターゲットSCT値はT = 103のパートナー（PE1）に103に送信されます。
5. Service Carving Timer: PE1 starts the service carving timer, with the remaining time until t=103.
5. サービスカービングタイマー：PE1はサービスカービングタイマーを開始し、残りの時間はt = 103まで。
6. Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=103.
6. 同時彫刻：T = 103の絶対時間でPE1とPE2の両方が彫刻します。
To maintain the preference for minimal loss over duplicate traffic, PE1 SHOULD carve slightly before PE2 (with skew). The recovering PE2 performs both DF-to-NDF and NDF-to-DF transitions per VLAN at the timer's expiry. The original PE1, which received the SCT, applies the following:
重複するトラフィックよりも最小限の損失の好みを維持するために、PE1はPE2の前に少し前に彫る必要があります（スキュー付き）。回復するPE2は、タイマーの有効期限でVLANあたりのDF-to-NDFおよびNDF-to-DFの両方の遷移を実行します。SCTを受け取った元のPE1が以下を適用します。
* DF-to-NDF Transition(s): at t=SCT minus skew, where both PEs are NDF for the skew duration.
* df-to-ndf遷移：t = sct minus skewでは、両方のPEがスキュー期間中はndfです。
* NDF-to-DF Transition(s): at t=SCT.
* ndf-to-df遷移：t = sct。
This split behavior ensures a smooth DF role transition with minimal loss.
この分割動作により、最小限の損失でスムーズなDFロール遷移が保証されます。
The SCT approach mitigates the negative effect of requiring a timer for discovery of Ethernet Segment (ES) RT-4 from other PE nodes. Furthermore, the BGP transmission delay (from PE2 to PE1) of the ES RT-4 becomes a non-issue. The SCT approach shortens the 3-second timer window to the order of milliseconds.
SCTアプローチは、他のPEノードからイーサネットセグメント（ES）RT-4を発見するためにタイマーを要求することのマイナス効果を軽減します。さらに、ES RT-4のBGP透過遅延（PE2からPE1まで）は、問題以外になります。SCTアプローチは、3秒のタイマーウィンドウをミリ秒の順序まで短縮します。
The peering timer is a configurable value where 3 seconds represents the default. Configuring a timer value of 0, or so small as to expire during propagation of the BGP routes, is outside the scope of this document. In reality, the use of the SCT approach presented in this document encourages the use of larger peering timer values to overcome any sort of BGP route propagation delays.
ピアリングタイマーは、3秒がデフォルトを表す構成可能な値です。BGPルートの伝播中に期限切れになるように、タイマー値が0の場合、またはそれほど小さいものを構成することは、このドキュメントの範囲外です。現実には、このドキュメントで提示されたSCTアプローチの使用は、あらゆる種類のBGPルートの伝播遅延を克服するために、より大きなピアリングタイマー値を使用することを促進します。
In the eventuality that two or more PEs in a peering Ethernet Segment group are recovering concurrently or roughly at the same time, each will advertise a SCT. This SCT value would correspond to what each recovering PE considers the "end time" for DF Election. A similar situation arises in sequentially recovering PEs, when a second PE recovers approximately at the time of the first PE's advertised SCT expiry and with its own new SCT-2 outside of the initial SCT window.
Peering Ethernetセグメントグループの2つ以上のPEが同時またはほぼ同時に回復していることがあるということで、それぞれがSCTを宣伝します。このSCT値は、回復する各PEがDF選挙の「終了時間」と見なしているものに対応します。同様の状況が、最初のPEの広告SCT有効期限のほぼ時点で2番目のPEが回復し、最初のSCTウィンドウの外側に独自の新しいSCT-2を使用して、順次回復するPESで発生します。
In the case of multiple concurrent DF elections, each initiated by one of the recovering PEs, the SCTs must be ordered chronologically. All PEs SHALL execute only a single DF Election at the service carving time corresponding to the largest (latest) received timestamp value. This DF Election will lead peering PEs into a single coordinated DF Election update.
複数の同時DF選挙の場合、それぞれが回復しているPESの1つによって開始された場合、SCTは年代順に命じなければなりません。すべてのPEは、最大の（最新の）受け取ったタイムスタンプの価値に対応するサービス彫刻時間で、単一のDF選挙のみを実行するものとします。このDF選挙は、PEERENG PESを単一の調整されたDF選挙の最新情報に導きます。
Example:
例：
1. Initial State: PE1 is in a steady state, with services elected at PE1.
1. 初期状態：PE1は定常状態にあり、サービスはPE1で選出されます。
2. Recovery of PE2: PE2 recovers at time t=100 and advertises RT-4 with a target SCT value of t=103 to its partner (PE1).
2. PE2の回復：PE2は時間t = 100で回復し、ターゲットSCT値のt = 103をパートナー（PE1）でRT-4を宣伝します。
3. Timer Initiation by PE2: PE2 starts a 3-second timer to allow the reception of RT-4 from other PE nodes.
3. PE2によるタイマーの開始：PE2は、他のPEノードからRT-4を受信できるように3秒のタイマーを開始します。
4. Timer Initiation by PE1: PE1 starts the service carving timer, with the remaining time until t=103.
4. PE1：PE1によるタイマーの開始は、サービスカービングタイマーを開始し、残りの時間はt = 103までです。
5. Recovery of PE3: PE3 recovers at time t=102 and advertises RT-4 with a target SCT value of t=105 to its partners (PE1, PE2).
5. PE3の回復：PE3は、時間t = 102で回復し、ターゲットSCT値のt = 105でRT-4をパートナー（PE1、PE2）に宣伝します。
6. Timer Initiation by PE3: PE3 starts a 3-second timer to allow the reception of RT-4 from other PE nodes.
6. PE3によるタイマーの開始：PE3は、3秒のタイマーを開始して、他のPEノードからRT-4を受信できるようにします。
7. Timer Update by PE2: PE2 cancels the running timer and starts the service carving timer with the remaining time until t=105.
7. PE2によるタイマーの更新：PE2は実行中のタイマーをキャンセルし、T = 105まで残りの時間でサービスカービングタイマーを開始します。
8. Timer Update by PE1: PE1 updates its service carving timer, with the remaining time until t=105.
8. PE1によるタイマーの更新：PE1は、そのサービスカービングタイマーを更新し、残りの時間はt = 105までです。
9. Service Carving: PE1, PE2, and PE3 perform service carving at the absolute time of t=105.
9. サービス彫刻：PE1、PE2、およびPE3は、T = 105の絶対時間でサービス彫刻を実行します。
In the eventuality that a PE in an Ethernet Segment group recovers during the discovery window specified in Section 8.5 of [RFC7432] and does not support or advertise the T-bit, all PEs in the current peering sequence SHALL immediately revert to the default behavior described in [RFC7432].
[RFC7432]のセクション8.5で指定されたディスカバリーウィンドウ中にイーサネットセグメントグループのPEが回復し、Tビットをサポートまたは宣伝しない最終性では、現在のピアリングシーケンスのすべてのPESは、[RFC7432]で説明されているデフォルトの動作に直ちに元に戻すものとします。
For the DF election procedures to achieve global convergence and unanimity within a redundancy group, it is essential that all participating PEs agree on the DF election algorithm to be employed. However, it is possible that some PEs may continue to use the existing modulo-based DF election algorithm from [RFC7432] and not utilize the new SCT BGP extended community. PEs that operate using the baseline DF election mechanism will simply discard the new SCT BGP extended community as unrecognized.
DF選挙手続きが冗長性グループ内でグローバルな収束と全会一致を達成するために、参加するすべてのPESがDF選挙アルゴリズムに採用されることに同意することが不可欠です。ただし、一部のPESは、[RFC7432]の既存のモジュロベースのDF選挙アルゴリズムを引き続き使用し、新しいSCT BGP拡張コミュニティを利用しない可能性があります。ベースラインDF選挙メカニズムを使用して動作するPESは、新しいSCT BGP拡張コミュニティを認識されないものとして単純に破棄します。
A PE can indicate its willingness to support clock-synchronized carving by signaling the new "T" DF Election Capability and including the new SCT BGP extended community along with the Ethernet Segment Route Type 4. If one or more PEs attached to the Ethernet Segment do not signal T=1, then all PEs in the Ethernet Segment SHALL revert to the timer-based approach as specified in [RFC7432]. This reversion is particularly crucial in preventing VLAN shuffling when more than two PEs are involved.
PEは、新しい「T」DF選挙能力を通知し、新しいSCT BGP拡張コミュニティとイーサネットセグメントルートタイプ4を含むことにより、時計同期の彫刻をサポートする意欲を示すことができます。この回復は、2つ以上のPEが関与している場合にVLANシャッフルを防ぐために特に重要です。
In the event a new or extra RT-4 is received without the new "T" DF Election Capability in the midst of an ongoing DF Election sequence, all SCT-based delays are canceled, and the DF Election is immediately applied as specified in [RFC7432], as if no SCT had been previously exchanged.
進行中のDF選挙シーケンスの最中に、新しい「T」DF選挙能力なしで新しいRT-4または追加のRT-4が受け取られた場合、SCTベースのすべての遅延はキャンセルされ、DF選挙は[RFC7432]で指定されたとおりに、SCTが以前に交換されていないかのように直ちに適用されます。
The mechanisms in this document use the EVPN control plane as defined in [RFC7432]. Security considerations described in [RFC7432] are equally applicable.
このドキュメントのメカニズムは、[RFC7432]で定義されているようにEVPNコントロールプレーンを使用します。[RFC7432]で説明されているセキュリティ上の考慮事項は等しく適用できます。
For the new SCT Extended Community, attack vectors may be setting the value to zero, to a value in the past, or to large times in the future. Handling of this attack vector is addressed in Section 2.2 alongside NTP Era rollover ambiguity.
新しいSCT拡張コミュニティの場合、攻撃ベクトルは、値をゼロ、過去の値、または将来の大規模な時期に設定することができます。この攻撃ベクトルの取り扱いは、NTP ERAロールオーバーのあいまいさとともにセクション2.2で対処されています。
This document uses MPLS- and IP-based tunnel technologies to support data plane transport. Security considerations described in [RFC7432] and [RFC8365] are equally applicable.
このドキュメントでは、MPLSおよびIPベースのトンネルテクノロジーを使用して、データプレーントランスポートをサポートしています。[RFC7432]および[RFC8365]で説明されているセキュリティ上の考慮事項は等しく適用できます。
IANA has made the following assignment in the "EVPN Extended Community Sub-Types" registry set up by [RFC7153].
IANAは、[RFC7153]によって設定された「EVPN拡張コミュニティサブタイプ」レジストリで次の割り当てを行いました。
+================+======================+===========+
| Sub-Type Value | Name | Reference |
+================+======================+===========+
| 0x0F | Service Carving Time | RFC 9722 |
+----------------+----------------------+-----------+
Table 1
IANA has made the following assignment in the "DF Election Capabilities" registry set up by [RFC8584].
IANAは、[RFC8584]によって設定された「DF選挙能力」レジストリで次の割り当てを行いました。
+=====+======================+===========+
| Bit | Name | Reference |
+=====+======================+===========+
| 3 | Time Synchronization | RFC 9722 |
+-----+----------------------+-----------+
Table 2
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/info/rfc7153>.
[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>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC8584] Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake,
J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet
VPN Designated Forwarder Election Extensibility",
RFC 8584, DOI 10.17487/RFC8584, April 2019,
<https://www.rfc-editor.org/info/rfc8584>.
[HRW98] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings
to Increase Hit Rates", IEEE/ACM Transactions on
Networking, vol. 6, no. 1, February 1998,
<https://www.microsoft.com/en-us/research/wp-
content/uploads/2017/02/HRW98.pdf>.
Authors would like to acknowledge helpful comments and contributions of Satya Mohanty and Bharath Vasudevan. Also thank you to Anoop Ghanwani and Gunter van de Velde for their thorough review with valuable comments and corrections.
著者は、サティヤ・モハンティとバラート・ヴァスデヴァンの有益なコメントと貢献を認めたいと思います。また、貴重なコメントと修正を伴う徹底的なレビューをしてくれたAnoop GhanwaniとGunter Van de Veldeにも感謝します。
In addition to the authors listed on the front page, the following coauthors have also contributed substantially to this document:
フロントページにリストされている著者に加えて、次の共著者もこのドキュメントに大きく貢献しています。
Gaurav Badoni
Cisco
Email: gbadoni@cisco.com
Dhananjaya Rao
Cisco
Email: dhrao@cisco.com
Patrice Brissette
Cisco
Email: pbrisset@cisco.com
Ali Sajassi
Cisco
Email: sajassi@cisco.com
Luc André Burdet (editor)
Cisco
Email: lburdet@cisco.com
John Drake
Independent
Email: je_drake@yahoo.com
Jorge Rabadan
Nokia
Email: jorge.rabadan@nokia.com