[要約] RFC 8469は、イーサネット制御ワードの使用を推奨するものであり、イーサネットフレームの信頼性と可用性を向上させることを目的としています。イーサネット制御ワードは、フレームのエラーチェックやタイムスタンプなどの情報を含むため、ネットワークのパフォーマンス向上に役立ちます。
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 8469 A. Malis
Updates: 4448 Huawei
Category: Standards Track I. Bagdonas
ISSN: 2070-1721 Equinix
November 2018
Recommendation to Use the Ethernet Control Word
イーサネットコントロールワードの使用に関する推奨事項
Abstract
概要
The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
RFC 4448で定義されているイーサネットの疑似配線（PW）カプセル化では、コントロールワード（CW）の使用がオプションであることを指定しています。 CWがない場合、イーサネットPWパケットは、ラベルスイッチングルータ（LSR）によってIPパケットとして誤って識別される可能性があります。これにより、パケットに対して誤った等価コストマルチパス（ECMP）パスが選択され、パケットの順序が正しくなくなる可能性があります。この問題は、イーサネットメディアアクセス制御（MAC）アドレスが0x4または0x6で始まる機器の配備により、さらに深刻になっています。イーサネットPW CWを使用すると、この問題に対処できます。このドキュメントでは、例外的な状況を除いて、イーサネットPW CWの使用を推奨しています。
This document updates RFC 4448.
このドキュメントはRFC 4448を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8469.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8469で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. Background ......................................................4
4. Recommendation ..................................................5
5. Equal-Cost Multipath (ECMP) .....................................5
6. Mitigations .....................................................6
7. Operational Considerations ......................................6
8. Security Considerations .........................................7
9. IANA Considerations .............................................7
10. References .....................................................7
10.1. Normative References ......................................7
10.2. Informative References ....................................8
Acknowledgments ....................................................9
Authors' Addresses .................................................9
The pseudowire (PW) encapsulation of Ethernet, as defined in [RFC4448], specifies that the use of the control word (CW) is optional. It is common for label switching routers (LSRs) to search past the end of the label stack to determine whether the payload is an IP packet and then, if it is, select the next hop based on the so-called "five-tuple" (IP source address, IP destination address, protocol/next-header, transport-layer source port, and transport-layer destination port). In the absence of a PW CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR) selecting the ECMP path based on the five-tuple. This may lead to the selection of the wrong ECMP path for the packet, leading in turn to the misordering of packets. Further discussion of this topic is published in [RFC4928].
[RFC4448]で定義されているイーサネットの疑似配線（PW）カプセル化は、制御ワード（CW）の使用がオプションであることを指定します。ラベルスイッチングルーター（LSR）がペイロードがIPパケットであるかどうかを判断するためにラベルスタックの最後を越えて検索し、そうである場合は、いわゆる「5タプル」に基づいて次のホップを選択するのが一般的です。 （IPソースアドレス、IP宛先アドレス、プロトコル/次のヘッダー、トランスポート層ソースポート、およびトランスポート層宛先ポート）。 PW CWがない場合、5つのタプルに基づいてECMPパスを選択するラベルスイッチングルータ（LSR）によって、イーサネットPWパケットがIPパケットとして誤って識別される可能性があります。これにより、パケットの間違ったECMPパスが選択され、パケットの順序が正しくなくなる可能性があります。このトピックの詳細については、[RFC4928]で公開されています。
Flow misordering can also happen in a single-path scenario when traffic classification and differential forwarding treatment mechanisms are in use. These errors occur when a forwarder incorrectly assumes that the packet is IP and applies a forwarding policy based on fields in the PW payload.
フローの順序の乱れは、トラフィックの分類と差分転送の処理メカニズムが使用されているときに、単一パスのシナリオでも発生する可能性があります。これらのエラーは、フォワーダーがパケットをIPであると誤って想定し、PWペイロードのフィールドに基づいて転送ポリシーを適用すると発生します。
IPv4 and IPv6 packets start with the values 0x4 and 0x6, respectively. Misidentification can arise if an Ethernet PW packet without a CW is carrying an Ethernet packet with a destination address that starts with either of these values.
IPv4およびIPv6パケットは、それぞれ値0x4および0x6で始まります。 CWのないイーサネットPWパケットが、これらの値のいずれかで始まる宛先アドレスを持つイーサネットパケットを伝送している場合、誤識別が発生する可能性があります。
This problem has recently become more serious for a number of reasons. First, the IEEE Registration Authority Committee (RAC) has assigned Ethernet MAC addresses that start with 0x4 or 0x6, and equipment that uses MAC addresses in these series has been deployed in networks. Second, concerns over privacy have led to the use of MAC address randomization, which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values approximately one time in eight.
この問題は最近、いくつかの理由でより深刻になっています。まず、IEEE Registration Authority Committee（RAC）が0x4または0x6で始まるイーサネットMACアドレスを割り当て、これらのシリーズのMACアドレスを使用する機器がネットワークに配備されました。第2に、プライバシーに対する懸念から、ローカルMACアドレスをランダムに割り当ててプライバシーを保護するMACアドレスのランダム化が使用されています。ランダムな割り当てを行うと、これらの2つの値のいずれかで始まるアドレスが8分の1程度になります。
The use of the Ethernet PW CW addresses this problem.
イーサネットPW CWを使用すると、この問題に対処できます。
This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
このドキュメントでは、例外的な状況を除いて、イーサネットPW CWの使用を推奨しています。
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]で説明されているように解釈されます。
Ethernet PW encapsulation is specified in [RFC4448]. Of particular relevance is Section 4.6, part of which is quoted below for the convenience of the reader. Note that RFC 4448 uses the citation [PWE3-CW] to refer to [RFC4385] and the citation [VCCV] to refer to the document that was eventually published as [RFC5085].
イーサネットPWカプセル化は[RFC4448]で指定されています。特に関連があるのはセクション4.6で、その一部は読者の便宜のために以下に引用されています。 RFC 4448では引用[PWE3-CW]を使用して[RFC4385]を参照し、引用[VCCV]を使用して最終的に[RFC5085]として公開されたドキュメントを参照していることに注意してください。
The control word defined in this section is based on the Generic PW MPLS Control Word as defined in [PWE3-CW]. It provides the ability to sequence individual frames on the PW, avoidance of equal-cost multiple-path load-balancing (ECMP) [RFC2992], and Operations and Management (OAM) mechanisms including VCCV [VCCV].
このセクションで定義されているコントロールワードは、[PWE3-CW]で定義されている汎用PW MPLSコントロールワードに基づいています。 PW上の個々のフレームをシーケンス処理する機能、等コストマルチパスロードバランシング（ECMP）[RFC2992]、およびVCCV [VCCV]を含む運用と管理（OAM）メカニズムの回避を提供します。
[PWE3-CW] states, "If a PW is sensitive to packet misordering and is being carried over an MPLS PSN that uses the contents of the MPLS payload to select the ECMP path, it MUST employ a mechanism which prevents packet misordering." This is necessary because ECMP implementations may examine the first nibble after the MPLS label stack to determine whether the labeled packet is IP or not. Thus, if the source MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. This may increase out-of-order frames on a given PW, or cause OAM packets to follow a different path than actual traffic (see Section 4.4.3, "Frame Ordering").
[PWE3-CW]は、「PWがパケットの順序の乱れに敏感で、MPLSペイロードの内容を使用してECMPパスを選択するMPLS PSNを介して伝送される場合、パケットの順序の乱れを防ぐメカニズムを採用する必要があります。」 ECMPの実装では、MPLSラベルスタックの後の最初のニブルを調べて、ラベル付きパケットがIPかどうかを判断する場合があるため、これが必要です。したがって、コントロールワードが存在しないPWで伝送されるイーサネットフレームの送信元MACアドレスが0x4または0x6で始まる場合、IPv4またはIPv6パケットと間違われる可能性があります。これは、MPLSネットワークの構成とトポロジーに応じて、特定のPWのすべてのパケットが同じパスをたどらない状況につながる可能性があります。これにより、特定のPWのフレームの順序が乱れたり、OAMパケットが実際のトラフィックとは異なるパスをたどったりする可能性があります（セクション4.4.3「フレームの順序付け」を参照）。
The features that the control word provides may not be needed for a given Ethernet PW. For example, ECMP may not be present or active on a given MPLS network, strict frame sequencing may not be required, etc. If this is the case, the control word provides little value and is therefore optional. Early Ethernet PW implementations have been deployed that do not include a control word or the ability to process one if present. To aid in backwards compatibility, future implementations MUST be able to send and receive frames without the control word present.
コントロールワードが提供する機能は、特定のイーサネットPWには必要ない場合があります。たとえば、ECMPが存在しないか、特定のMPLSネットワークでアクティブになっていない、厳密なフレームシーケンスが不要な場合などがあります。その場合、コントロールワードはほとんど値を提供しないため、オプションです。初期のイーサネットPW実装が展開されており、コントロールワードや、存在する場合にそれを処理する機能が含まれていません。下位互換性を支援するために、将来の実装では、制御ワードが存在しなくてもフレームを送受信できなければなりません（MUST）。
When PWs were first deployed, some equipment of commercial significance was unable to process the Ethernet CW. In addition, at that time, it was believed that no Ethernet MAC address had been issued by the IEEE Registration Authority Committee (RAC) that started with 0x4 or 0x6; thus, it was thought to be safe to deploy Ethernet PWs without the CW.
PWが最初に導入されたとき、商業的に重要な一部の機器はイーサネットCWを処理できませんでした。さらに、当時、IEEE Registration Authority Committee（RAC）は、0x4または0x6で始まるイーサネットMACアドレスを発行していないと考えられていました。したがって、CWなしでイーサネットPWを展開しても安全であると考えられていました。
Since that time, the RAC has issued Ethernet MAC addresses that start with 0x4 or with 0x6. Therefore, the assumption that, in practical networks, there would be no confusion between an Ethernet PW packet without the CW and an IP packet is no longer correct.
それ以来、RACは0x4または0x6で始まるイーサネットMACアドレスを発行しています。したがって、実際のネットワークでは、CWのないイーサネットPWパケットとIPパケットの間に混乱がないという仮定は、もはや正しくありません。
Possibly through the use of unauthorized Ethernet MAC addresses, this assumption has been unsafe for a while, leading some equipment vendors to implement more complex, proprietary methods to discriminate between Ethernet PW packets and IP packets. Such mechanisms rely on the heuristics of examining the transit packets to try to find out the exact payload type of the packet and cannot be reliable due to the random nature of the payload carried within such packets.
おそらく無許可のイーサネットMACアドレスの使用により、この仮定はしばらく安全ではなく、一部の機器ベンダーはイーサネットPWパケットとIPパケットを区別するためのより複雑な独自の方法を実装するようになりました。このようなメカニズムは、パケットの正確なペイロードタイプを見つけるためにトランジットパケットを調べるヒューリスティックに依存しており、そのようなパケット内で運ばれるペイロードのランダムな性質のため、信頼できません。
A posting on the NANOG email list highlighted this problem:
NANOGメーリングリストへの投稿により、この問題が明らかになりました。
<https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html>
The ambiguity between an MPLS payload that is an Ethernet PW and one that is an IP packet is resolved when the Ethernet PW CW is used. This document updates [RFC4448] to state that both the ingress provider edge (PE) and the egress PE SHOULD support the Ethernet PW CW and that, if supported, the CW MUST be used.
イーサネットPW CWを使用すると、イーサネットPWであるMPLSペイロードとIPパケットであるMPLSペイロードのあいまいさが解決されます。このドキュメントは、[RFC4448]を更新して、入力プロバイダーエッジ（PE）と出力PEの両方がイーサネットPW CWをサポートする必要があり、サポートされている場合はCWを使用する必要があることを述べています。
Where the application of ECMP to Ethernet PW traffic is required and where both the ingress and the egress PEs support Entropy Label Indicator / Entropy Label (ELI/EL) [RFC6790] and Flow-Aware Transport of Pseudowires (FAT PW) [RFC6391], then either method may be used. The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. In the case of multi-segment PWs, if ELI/EL is used, then it SHOULD be used on every segment of the PW. The method by which usage of ELI/EL on every segment is guaranteed is out of the scope of this document.
ECMPのイーサネットPWトラフィックへの適用が必要な場合、および入力と出力の両方のPEがエントロピーラベルインジケーター/エントロピーラベル（ELI / EL）[RFC6790]およびフロー対応の疑似配線のトランスポート（FAT PW）[RFC6391]をサポートする場合、その後、どちらの方法を使用してもかまいません。同じPWで両方の方法を使用することは通常必要ではなく、状況によって必要とされない限り回避する必要があります。マルチセグメントPWの場合、ELI / ELを使用すると、PWのすべてのセグメントで使用する必要があります（SHOULD）。すべてのセグメントでのELI / ELの使用を保証する方法は、このドキュメントの範囲外です。
Where the volume of traffic on an Ethernet PW is such that ECMP is required, then one of two methods may be used:
イーサネットPWのトラフィック量がECMPを必要とする量である場合、2つの方法のいずれかを使用できます。
o Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network, specified in [RFC6391], or
o [RFC6391]で指定されたMPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート、または
o Label Switched Path (LSP) entropy labels, specified in [RFC6790].
o [RFC6790]で指定されているラベルスイッチドパス（LSP）エントロピーラベル。
RFC 6391 works by increasing the entropy of the bottom-of-stack label. It requires that both the ingress and egress PEs support this feature. It also requires that sufficient LSRs on the LSP between the ingress and egress PE be able to select an ECMP path on an MPLS packet with the resultant stack depth.
RFC 6391は、スタックの最下位ラベルのエントロピーを増やすことで機能します。入力と出力の両方のPEがこの機能をサポートする必要があります。また、入力PEと出力PEの間のLSP上の十分なLSRが、MPLSパケット上のECMPパスを選択して、結果のスタック深度を取得できることも必要です。
RFC 6790 works by including an entropy value in the LSP part of the label stack. This requires that the ingress and egress PEs support the insertion and removal of the EL and the ELI and that sufficient LSRs on the LSP are able to perform ECMP based on the EL.
RFC 6790は、ラベルスタックのLSP部分にエントロピー値を含めることで機能します。これには、入力および出力PEがELおよびELIの挿入と削除をサポートし、LSP上の十分なLSRがELに基づいてECMPを実行できることが必要です。
In both cases, there are considerations in getting Operations, Administration, and Maintenance (OAM) packets to follow the same path as a data packet. This is described in detail in Section 7 of [RFC6391] and Section 6 of [RFC6790]. However, in both cases, the situation is improved compared to the ECMP behavior in the case where the Ethernet PW CW was not used, since there is currently no known method of getting a PW OAM packet to follow the same path as a PW data packet subjected to ECMP based on the five-tuple of the IP payload.
どちらの場合も、運用、管理、およびメンテナンス（OAM）パケットがデータパケットと同じパスをたどるようにするための考慮事項があります。これについては、[RFC6391]のセクション7と[RFC6790]のセクション6で詳しく説明しています。ただし、どちらの場合も、PW OAMパケットがPWデータパケットと同じパスをたどる既知の方法がないため、イーサネットPW CWが使用されなかった場合のECMP動作と比較して状況は改善されます。 IPペイロードの5タプルに基づくECMPの対象。
The PW label is pushed before the LSP label. As the ELI/EL labels are part of the LSP layer rather than part of the PW layer, they are pushed after the PW label has been pushed.
PWラベルはLSPラベルの前にプッシュされます。 ELI / ELラベルはPWレイヤーの一部ではなくLSPレイヤーの一部であるため、PWラベルがプッシュされた後にプッシュされます。
Where it is not possible to use the Ethernet PW CW, the effects of ECMP can be disabled by carrying the PW over a traffic-engineered path that does not subject the payload to load balancing (for example, RSVP-TE [RFC3209]). However, such paths may be subjected to link-bundle load balancing, and, of course, the single LSP has to carry the full PW load.
イーサネットPW CWを使用できない場合、ペイロードをロードバランシングの対象としないトラフィックエンジニアリングパス（たとえば、RSVP-TE [RFC3209]）でPWを伝送することにより、ECMPの影響を無効にできます。ただし、そのようなパスはリンクバンドルのロードバランシングの影響を受ける可能性があり、当然、単一のLSPが完全なPW負荷を負担する必要があります。
In some cases, the inclusion of a CW in the PW is determined by equipment configuration. Furthermore, it is possible that the default configuration in such cases is to disable use of the CW. Care needs to be taken to ensure that software that implements this recommendation does not depend on existing configuration settings that prevent the use of a CW. It is recommended that platform software emit a rate-limited message indicating that the CW can be used but is disabled due to existing configuration.
場合によっては、PWにCWを含めるかどうかは、機器の構成によって決まります。さらに、このような場合のデフォルト設定では、CWの使用を無効にすることができます。この推奨事項を実装するソフトウェアが、CWの使用を妨げる既存の構成設定に依存しないように注意する必要があります。プラットフォームソフトウェアは、CWを使用できるが既存の構成により無効になっていることを示すレート制限メッセージを送信することをお勧めします。
Instead of including a payload type in the packet, MPLS relies on the control plane to signal the payload type that follows the bottom of the label stack. Some LSRs attempt to deduce the packet type by MPLS payload inspection, in some cases looking past the PW CW. If the payload appears to be IP or IP carried in an Ethernet header, they perform an ECMP calculation based on what they assume to be the five-tuple fields. However, deduction of the payload type in this way is not an exact science, and where a packet that is not IP is mistaken for an IP packet, the result can be packets delivered out of order. Misordering of this type can be difficult for an operator to diagnose. When enabling capability that allows information gleaned from packet inspection past the PW CW to be used in any ECMP calculation, operators should be aware that this may cause Ethernet frames to be delivered out of order despite the presence of the CW.
パケットにペイロードタイプを含める代わりに、MPLSはコントロールプレーンに依存して、ラベルスタックの下部に続くペイロードタイプを通知します。一部のLSRは、MPLSペイロード検査によってパケットタイプを推測しようとしますが、場合によってはPW CWを通過します。ペイロードがIPまたはイーサネットヘッダーで運ばれるIPのように見える場合、ペイロードは5タプルフィールドと見なされるものに基づいてECMP計算を実行します。ただし、この方法でのペイロードタイプの推定は正確な科学ではなく、IPでないパケットがIPパケットと間違えられると、結果としてパケットが順不同で配信される可能性があります。このタイプの誤った順序は、オペレーターが診断するのが難しい場合があります。 PW CWを通過したパケット検査から収集した情報をECMP計算で使用できるようにする機能を有効にする場合、オペレーターは、これによりCWが存在してもイーサネットフレームが順不同で配信される可能性があることに注意する必要があります。
This document expresses a preference for one existing and widely deployed Ethernet PW encapsulation over another. These methods have identical security considerations, which are discussed in [RFC4448]. This document introduces no additional security issues.
このドキュメントは、1つの既存の広く展開されているイーサネットPWカプセル化の優先度を示しています。これらの方法には、[RFC4448]で説明されている同じセキュリティ上の考慮事項があります。このドキュメントでは、追加のセキュリティ問題は紹介されていません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、DOI 10.17487 / RFC4385、2006年2月、<https://www.rfc-editor.org/info/rfc4385>。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.
[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、DOI 10.17487 / RFC4448、April 2006 、<https://www.rfc-editor.org/info/rfc4448>。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, <https://www.rfc-editor.org/info/rfc4928>.
[RFC4928] Swallow、G.、Bryant、S。、およびL. Andersson、「MPLSネットワークにおける等コストマルチパス処理の回避」、BCP 128、RFC 4928、DOI 10.17487 / RFC4928、2007年6月、<https：// www。 rfc-editor.org/info/rfc4928>。
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <https://www.rfc-editor.org/info/rfc6391>.
[RFC6391]ブライアント、S。、編、フィルスフィルス、C。、ドラフズ、U。、コンペラ、V。、リーガン、J。、およびS.アマンテ、「MPLSパケット交換ネットワーク上の疑似配線のフロー対応トランスポート」 、RFC 6391、DOI 10.17487 / RFC6391、2011年11月、<https://www.rfc-editor.org/info/rfc6391>。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、and L. Yong、 "The Use of Entropy Labels in MPLS Forwarding"、RFC 6790、DOI 10.17487 / RFC6790、November 2012、 <https://www.rfc-editor.org/info/rfc6790>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「Analysis of an Equal-Cost Multi-Path Algorithm」、RFC 2992、DOI 10.17487 / RFC2992、2000年11月、<https://www.rfc-editor.org/info/rfc2992>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5085]ナドー、T。、エド。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<https://www.rfc-editor.org/info / rfc5085>。
Acknowledgments
謝辞
The authors thank Job Snijders for drawing attention to this problem. The authors also thank Pat Thaler for clarifying the matter of local MAC address assignment. We thank Sasha Vainshtein for his valuable review comments.
この問題に注意を向けてくれたJob Snijdersに感謝します。著者は、ローカルMACアドレス割り当ての問題を明確にしてくれたPat Thalerにも感謝します。 Sasha Vainshteinの貴重なレビューコメントに感謝します。
Authors' Addresses
著者のアドレス
Stewart Bryant Huawei
スチュワートブライアントファーウェイ
Email: stewart.bryant@gmail.com
Andrew G. Malis Huawei
アンドリューG.マリスファーウェイ
Email: agmalis@gmail.com
Ignas Bagdonas Equinix
イグナスバグドナースエクイニクス
Email: ibagdona.ietf@gmail.com>