[要約] RFC 8611は、リンク集約グループ（LAG）インターフェースに対するラベルスイッチパス（LSP）Pingおよびトレースルートのマルチパスサポートに関する仕様です。このRFCの目的は、LAGインターフェース上のLSPのパフォーマンスと可用性を向上させることです。
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 8611 Big Switch Networks
Updates: 8029 G. Swallow
Category: Standards Track SETC
ISSN: 2070-1721 S. Litkowski
B. Decraene
Orange
J. Drake
Juniper Networks
M. Chen
Huawei
June 2019
Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
ラベルアグリゲーショングループ（LAG）インターフェイスのラベルスイッチドパス（LSP）pingおよびTracerouteマルチパスサポート
Abstract
概要
This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
このドキュメントでは、RFC 8029で指定されているMPLSラベルスイッチドパス（LSP）PingおよびTracerouteメカニズムの拡張機能を定義しています。この拡張機能により、MPLS LSP PingおよびTracerouteメカニズムは、レイヤー2（L2）等コストマルチパス（ ECMP）over Link Aggregation Group（LAG）インターフェイス。さらに、Label Switching Router（LSR）でサポートされている機能を判別できるメカニズムが定義されています。
This document updates RFC 8029.
このドキュメントはRFC 8029を更新します。
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/rfc8611.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8611で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4
3. LSR Capability Discovery . . . . . . . . . . . . . . . . . . 6
3.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
3.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 7
4. Mechanism to Discover L2 ECMP . . . . . . . . . . . . . . . . 7
4.1. Initiator LSR Procedures . . . . . . . . . . . . . . . . 7
4.2. Responder LSR Procedures . . . . . . . . . . . . . . . . 8
4.3. Additional Initiator LSR Procedures . . . . . . . . . . . 10
5. Mechanism to Validate L2 ECMP Traversal . . . . . . . . . . . 11
5.1. Incoming LAG Member Links Verification . . . . . . . . . 11
5.1.1. Initiator LSR Procedures . . . . . . . . . . . . . . 11
5.1.2. Responder LSR Procedures . . . . . . . . . . . . . . 12
5.1.3. Additional Initiator LSR Procedures . . . . . . . . . 12
5.2. Individual End-to-End Path Verification . . . . . . . . . 14
6. LSR Capability TLV . . . . . . . . . . . . . . . . . . . . . 14
7. LAG Description Indicator Flag: G . . . . . . . . . . . . . . 15
8. Local Interface Index Sub-TLV . . . . . . . . . . . . . . . . 16
9. Remote Interface Index Sub-TLV . . . . . . . . . . . . . . . 17
10. Detailed Interface and Label Stack TLV . . . . . . . . . . . 17
10.1. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1.1. Incoming Label Stack Sub-TLV . . . . . . . . . . . . 19
10.1.2. Incoming Interface Index Sub-TLV . . . . . . . . . . 20
11. Rate-Limiting on Echo Request/Reply Messages . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13.1. LSR Capability TLV . . . . . . . . . . . . . . . . . . . 22
13.1.1. LSR Capability Flags . . . . . . . . . . . . . . . . 22
13.2. Local Interface Index Sub-TLV . . . . . . . . . . . . . 22
13.2.1. Interface Index Flags . . . . . . . . . . . . . . . 22
13.3. Remote Interface Index Sub-TLV . . . . . . . . . . . . . 23
13.4. Detailed Interface and Label Stack TLV . . . . . . . . . 23
13.4.1. Sub-TLVs for TLV Type 6 . . . . . . . . . . . . . . 23
13.4.2. Interface and Label Stack Address Types . . . . . . 25
13.5. DS Flags . . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. LAG with Intermediate L2 Switch Issues . . . . . . . 27
A.1. Equal Numbers of LAG Members . . . . . . . . . . . . . . 27
A.2. Deviating Numbers of LAG Members . . . . . . . . . . . . 27
A.3. LAG Only on Right . . . . . . . . . . . . . . . . . . . . 27
A.4. LAG Only on Left . . . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
The MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms [RFC8029] are powerful tools designed to diagnose all available Layer 3 (L3) paths of LSPs, including diagnostic coverage of L3 Equal-Cost Multipath (ECMP). In many MPLS networks, Link Aggregation Groups (LAGs), as defined in [IEEE802.1AX], provide Layer 2 (L2) ECMP and are often used for various reasons. MPLS LSP Ping and Traceroute tools were not designed to discover and exercise specific paths of L2 ECMP. This produces a limitation for the following scenario when an LSP traverses a LAG:
MPLSラベルスイッチドパス（LSP）PingおよびTracerouteメカニズム[RFC8029]は、L3等コストマルチパス（ECMP）の診断カバレッジを含む、LSPの利用可能なすべてのレイヤー3（L3）パスを診断するように設計された強力なツールです。多くのMPLSネットワークでは、[IEEE802.1AX]で定義されているリンク集約グループ（LAG）がレイヤー2（L2）ECMPを提供し、さまざまな理由でよく使用されます。 MPLS LSP PingおよびTracerouteツールは、L2 ECMPの特定のパスを検出して実行するようには設計されていません。これにより、LSPがLAGを通過するときに、次のシナリオに制限が生じます。
o Label switching over some member links of the LAG is successful, but fails over other member links of the LAG.
o LAGの一部のメンバーリンクを介したラベルスイッチングは成功しますが、LAGの他のメンバーリンクをフェイルオーバーします。
o MPLS echo request for the LSP over the LAG is load-balanced on one of the member links that is label switching successfully.
o LAGを介したLSPに対するMPLSエコー要求は、ラベルスイッチングが正常に行われているメンバーリンクの1つで負荷分散されます。
With the above scenario, MPLS LSP Ping and Traceroute will not be able to detect the label-switching failure of the problematic member link(s) of the LAG. In other words, lack of L2 ECMP diagnostic coverage can produce an outcome where MPLS LSP Ping and Traceroute can be blind to label-switching failures over a problematic LAG interface. It is, thus, desirable to extend the MPLS LSP Ping and Traceroute to have deterministic diagnostic coverage of LAG interfaces.
上記のシナリオでは、MPLS LSP PingおよびTracerouteは、LAGの問題のあるメンバーリンクのラベルスイッチング障害を検出できません。言い換えると、L2 ECMP診断カバレッジの欠如は、MPLS LSP PingおよびTracerouteが問題のあるLAGインターフェイスを介したラベルスイッチングの失敗を知らないという結果をもたらす可能性があります。そのため、MPLS LSP PingとTracerouteを拡張して、LAGインターフェイスの確定的な診断カバレッジを確保することが望まれます。
The work toward a solution to this problem was motivated by issues encountered in live networks.
この問題の解決に向けた取り組みは、ライブネットワークで発生した問題に動機付けられました。
The following acronyms/terms are used in this document:
このドキュメントでは、次の頭字語/用語が使用されています。
o MPLS - Multiprotocol Label Switching.
o MPLS-マルチプロトコルラベルスイッチング。
o LSP - Label Switched Path.
o LSP-ラベルスイッチドパス。
o LSR - Label Switching Router.
o LSR-ラベルスイッチングルーター。
o ECMP - Equal-Cost Multipath.
o ECMP-等コストマルチパス。
o LAG - Link Aggregation Group.
o LAG-リンク集約グループ。
o Initiator LSR - The LSR that sends the MPLS echo request message.
o イニシエーターLSR-MPLSエコー要求メッセージを送信するLSR。
o Responder LSR - The LSR that receives the MPLS echo request message and sends the MPLS echo reply message.
o レスポンダーLSR-MPLSエコー要求メッセージを受信し、MPLSエコー応答メッセージを送信するLSR。
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]で説明されているように解釈されます。
This document defines a new TLV to discover the capabilities of a responder LSR and extensions for use with the MPLS LSP Ping and Traceroute mechanisms to describe Multipath Information for individual LAG member links, thus allowing MPLS LSP Ping and Traceroute to discover and exercise specific paths of L2 ECMP over LAG interfaces. The reader is expected to be familiar with the Downstream Detailed Mapping TLV (DDMAP) described in Section 3.4 of [RFC8029].
このドキュメントでは、MPLS LSP PingおよびTracerouteメカニズムで使用するためのレスポンダーLSRおよび拡張機能を検出するための新しいTLVを定義し、個々のLAGメンバーリンクのマルチパス情報を記述して、MPLS LSP PingおよびTracerouteが特定のパスを検出および実行できるようにしますLAGインターフェイス上のL2 ECMP。読者は、[RFC8029]のセクション3.4で説明されているダウンストリーム詳細マッピングTLV（DDMAP）に精通している必要があります。
The solution consists of the MPLS echo request containing a DDMAP TLV and the new LSR Capability TLV to indicate that separate load-balancing information for each L2 next hop over LAG is desired in the MPLS echo reply. The responder LSR places the same LSR Capability TLV in the MPLS echo reply to provide acknowledgement back to the initiator LSR. It also adds, for each downstream LAG member, load-balancing information (i.e., multipath information and interface index). This mechanism is applicable to all types of LSPs that can traverse LAG interfaces. Many LAGs are built from peer-to-peer links, with router X and router X+1 having direct connectivity and the same number of LAG members. It is possible to build LAGs asymmetrically by using Ethernet switches between two routers. Appendix A lists some use cases for which the mechanisms defined in this document may not be applicable. Note that the mechanisms described in this document do not impose any changes to scenarios where an LSP is pinned down to a particular LAG member (i.e., the LAG is not treated as one logical interface by the LSP).
このソリューションは、DDMAP TLVと新しいLSR機能TLVを含むMPLSエコー要求で構成され、MPLSエコー応答でLAGを介した各L2ネクストホップの個別のロードバランシング情報が必要であることを示します。応答側のLSRは、MPLSエコー応答に同じLSR機能TLVを配置して、開始側のLSRに確認応答を返します。また、ダウンストリームの各LAGメンバーに対して、負荷分散情報（つまり、マルチパス情報とインターフェースインデックス）を追加します。このメカニズムは、LAGインターフェイスを通過できるすべてのタイプのLSPに適用できます。多くのLAGはピアツーピアリンクから構築されており、ルーターXとルーターX + 1は直接接続されており、LAGメンバーの数は同じです。 2つのルーター間でイーサネットスイッチを使用することにより、LAGを非対称に構築することが可能です。付録Aは、このドキュメントで定義されているメカニズムが適用できない場合があるいくつかの使用例を示しています。このドキュメントで説明されているメカニズムは、LSPが特定のLAGメンバーに固定されているシナリオに変更を課さないことに注意してください（つまり、LAGはLSPによって1つの論理インターフェイスとして扱われません）。
The following figure and description provide an example of an LDP network.
次の図と説明は、LDPネットワークの例を示しています。
<----- LDP Network ----->
+-------+
| |
A-------B=======C-------E
| |
+-------D-------+
---- Non-LAG
==== LAG comprising of two member links
Figure 1: Example LDP Network
図1：LDPネットワークの例
When node A is initiating LSP Traceroute to node E, node B will return to node A load-balancing information for the following entries:
ノードAがノードEへのLSP Tracerouteを開始すると、ノードBは次のエントリのノードA負荷分散情報に戻ります。
1. Downstream C over Non-LAG (upper path).
1. 非LAG経由のダウンストリームC（上のパス）。
2. First Downstream C over LAG (middle path).
2. LAG上の最初のダウンストリームC（中間パス）。
3. Second Downstream C over LAG (middle path).
3. LAG上の2番目のダウンストリームC（中間パス）。
4. Downstream D over Non-LAG (lower path).
4. 非LAG経由のダウンストリームD（下のパス）。
This document defines:
このドキュメントでは次のことを定義しています。
o in Section 3, a mechanism to discover capabilities of responder LSRs;
o セクション3では、レスポンダLSRの機能を発見するメカニズム。
o in Section 4, a mechanism to discover L2 ECMP information;
o セクション4では、L2 ECMP情報を検出するメカニズム。
o in Section 5, a mechanism to validate L2 ECMP traversal;
o セクション5では、L2 ECMPトラバーサルを検証するメカニズム。
o in Section 6, the LSR Capability TLV;
o セクション6では、LSR機能TLV。
o in Section 7, the LAG Description Indicator flag;
o セクション7では、LAG記述インジケータフラグ。
o in Section 8, the Local Interface Index Sub-TLV;
o セクション8では、Local Interface Index Sub-TLV。
o in Section 9, the Remote Interface Index Sub-TLV; and
o セクション9では、Remote Interface Index Sub-TLV。そして
o in Section 10, the Detailed Interface and Label Stack TLV.
o セクション10の詳細なインターフェイスとラベルスタックTLV。
The MPLS Ping operates by an initiator LSR sending an MPLS echo request message and receiving back a corresponding MPLS echo reply message from a responder LSR. The MPLS Traceroute operates in a similar way except the initiator LSR potentially sends multiple MPLS echo request messages with incrementing TTL values.
MPLS Pingは、MPLSエコー要求メッセージを送信し、レスポンダーLSRから対応するMPLSエコー応答メッセージを受信するイニシエーターLSRによって動作します。 MPLS Tracerouteは、イニシエーターLSRが複数のMPLSエコー要求メッセージを増分TTL値とともに送信する可能性があることを除いて、同様の方法で動作します。
There have been many extensions to the MPLS Ping and Traceroute mechanisms over the years. Thus, it is often useful, and sometimes necessary, for the initiator LSR to deterministically disambiguate the differences between:
長年にわたって、MPLS PingおよびTracerouteメカニズムには多くの拡張機能がありました。したがって、イニシエーターLSRが以下の違いを確定的に明確にすることは、しばしば有用であり、時には必要です。
o The responder LSR sent the MPLS echo reply message with contents C because it has feature X, Y, and Z implemented.
o レスポンダーLSRは、機能X、Y、およびZが実装されているため、コンテンツCのMPLSエコー応答メッセージを送信しました。
o The responder LSR sent the MPLS echo reply message with contents C because it has a subset of features X, Y, and Z (i.e., not all of them) implemented.
o レスポンダーLSRには、コンテンツCのMPLSエコー応答メッセージが送信されました。これには、機能X、Y、およびZ（つまり、それらのすべてではない）のサブセットが実装されているためです。
o The responder LSR sent the MPLS echo reply message with contents C because it does not have features X, Y, or Z implemented.
o レスポンダーLSRは、機能X、Y、またはZが実装されていないため、コンテンツCのMPLSエコー応答メッセージを送信しました。
To allow the initiator LSR to disambiguate the above differences, this document defines the LSR Capability TLV (described in Section 6). When the initiator LSR wishes to discover the capabilities of the responder LSR, the initiator LSR includes the LSR Capability TLV in the MPLS echo request message. When the responder LSR receives an MPLS echo request message with the LSR Capability TLV included, if it knows the LSR Capability TLV, then it MUST include the LSR Capability TLV in the MPLS echo reply message with the LSR Capability TLV describing the features and extensions supported by the local LSR. Otherwise, an MPLS echo reply must be sent back to the initiator LSR with the return code set to "One or more of the TLVs was not understood", according to the rules defined in Section 3 of [RFC8029]. Then, the initiator LSR can send another MPLS echo request without including the LSR Capability TLV.
イニシエータLSRが上記の違いを明確にするために、このドキュメントではLSR機能TLVを定義しています（セクション6で説明）。イニシエーターLSRがレスポンダーLSRの機能を検出したい場合、イニシエーターLSRはMPLSエコー要求メッセージにLSR機能TLVを含めます。レスポンダLSRがLSR機能TLVが含まれているMPLSエコー要求メッセージを受信するとき、LSR機能TLVがわかっている場合、サポートされている機能と拡張機能を説明するLSR機能TLVを含むMPSエコー応答メッセージにLSR機能TLVを含める必要があります。ローカルLSRによる。それ以外の場合は、[RFC8029]のセクション3で定義されているルールに従って、MPLSエコー応答を「1つ以上のTLVが認識されなかった」に設定された戻りコードでイニシエーターLSRに送り返す必要があります。次に、イニシエーターLSRは、LSR機能TLVを含めずに別のMPLSエコー要求を送信できます。
It is RECOMMENDED that implementations supporting the LAG multipath extensions defined in this document include the LSR Capability TLV in MPLS echo request messages.
このドキュメントで定義されているLAGマルチパス拡張をサポートする実装には、MPLSエコー要求メッセージにLSR機能TLVを含めることをお勧めします。
If an initiator LSR does not know what capabilities a responder LSR can support, it can send an MPLS echo request message and carry the LSR Capability TLV to the responder to discover the capabilities that the responder LSR can support.
イニシエータLSRは、レスポンダLSRがサポートできる機能を知らない場合、MPLSエコー要求メッセージを送信し、LSR機能TLVをレスポンダに伝送して、レスポンダLSRがサポートできる機能を検出できます。
When a responder LSR receives an MPLS echo request message that carries the LSR Capability TLV, the following procedures are used:
レスポンダLSRがLSR機能TLVを伝送するMPLSエコー要求メッセージを受信すると、次の手順が使用されます。
If the responder knows how to process the LSR Capability TLV, the following procedures are used:
レスポンダがLSR機能TLVの処理方法を知っている場合、次の手順が使用されます。
o The responder LSR MUST include the LSR Capability TLV in the MPLS echo reply message.
o レスポンダLSRは、LSR機能TLVをMPLSエコー応答メッセージに含める必要があります。
o If the responder LSR understands the LAG Description Indicator flag:
o レスポンダーLSRがLAG説明インジケーターフラグを理解している場合：
* Set the Downstream LAG Info Accommodation flag if the responder LSR is capable of describing the outgoing LAG member links separately; otherwise, clear the Downstream LAG Info Accommodation flag.
* レスポンダーLSRが発信LAGメンバーリンクを個別に記述できる場合は、ダウンストリームLAG情報調整フラグを設定します。それ以外の場合は、ダウンストリームLAG情報調整フラグをクリアします。
* Set the Upstream LAG Info Accommodation flag if the responder LSR is capable of describing the incoming LAG member links separately; otherwise, clear the Upstream LAG Info Accommodation flag.
* レスポンダーLSRが着信LAGメンバーリンクを個別に説明できる場合は、アップストリームLAG情報調整フラグを設定します。それ以外の場合は、アップストリームLAG情報宿泊施設フラグをクリアします。
Through LSR Capability Discovery as defined in Section 3, the initiator LSR can understand whether the responder LSR can describe incoming/outgoing LAG member links separately in the DDMAP TLV.
セクション3で定義されているLSR機能ディスカバリーを通じて、イニシエーターLSRは、応答側LSRが着信/発信LAGメンバーリンクをDDMAP TLVで個別に記述できるかどうかを理解できます。
Once the initiator LSR knows that a responder can support this mechanism, then it sends an MPLS echo request carrying a DDMAP TLV with the LAG Description Indicator flag (G) set to the responder LSR. The LAG Description Indicator flag (G) indicates that separate load- balancing information for each L2 next hop over a LAG is desired in the MPLS echo reply. The new LAG Description Indicator flag is described in Section 7.
イニシエーターLSRは、レスポンダーがこのメカニズムをサポートできることを認識すると、LAG Descriptionインジケーターフラグ（G）が設定されたDDMAP TLVを運ぶMPLSエコー要求をレスポンダーLSRに送信します。 LAG説明インジケータフラグ（G）は、MPLSエコー応答で、LAGを介した各L2ネクストホップの個別の負荷分散情報が必要であることを示します。新しいLAG説明インジケーターフラグについては、セクション7で説明します。
When a responder LSR receives an MPLS echo request message with the LAG Description Indicator flag set in the DDMAP TLV, if the responder LSR understands the LAG Description Indicator flag and is capable of describing outgoing LAG member links separately, the following procedures are used, regardless of whether or not the outgoing interfaces include LAG interfaces:
レスポンダーLSRがDDMAP TLVに設定されたLAG説明インジケーターフラグを含むMPLSエコー要求メッセージを受信するとき、レスポンダーLSRがLAG説明インジケーターフラグを理解し、発信LAGメンバーリンクを個別に説明できる場合は、次の手順が使用されます発信インターフェイスにLAGインターフェイスが含まれているかどうかの確認：
o For each downstream interface that is a LAG interface:
o LAGインターフェースである各ダウンストリームインターフェースについて：
* The responder LSR MUST include a DDMAP TLV when sending the MPLS echo reply. There is a single DDMAP TLV for the LAG interface, with member links described using sub-TLVs.
* レスポンダLSRは、MPLSエコー応答を送信するときにDDMAP TLVを含める必要があります。 LAGインターフェイスには単一のDDMAP TLVがあり、メンバーリンクはサブTLVを使用して記述されています。
* The responder LSR MUST set the LAG Description Indicator flag in the DS Flags field of the DDMAP TLV.
* レスポンダーLSRは、DDMAP TLVのDS FlagsフィールドにLAG Description Indicatorフラグを設定する必要があります。
* In the DDMAP TLV, the Local Interface Index Sub-TLV, Remote Interface Index Sub-TLV, and Multipath Data Sub-TLV are used to describe each LAG member link. All other fields of the DDMAP TLV are used to describe the LAG interface.
* DDMAP TLVでは、ローカルインターフェイスインデックスサブTLV、リモートインターフェイスインデックスサブTLV、およびマルチパスデータサブTLVを使用して、各LAGメンバーリンクを記述します。 DDMAP TLVの他のすべてのフィールドは、LAGインターフェイスを記述するために使用されます。
* For each LAG member link of the LAG interface:
* LAGインターフェースの各LAGメンバーリンクについて：
+ The responder LSR MUST add a Local Interface Index Sub-TLV (described in Section 8) with the LAG Member Link Indicator flag set in the Interface Index Flags field. It describes the interface index of this outgoing LAG member link (the local interface index is assigned by the local LSR).
+ レスポンダLSRは、インターフェイスインデックスフラグフィールドに設定されたLAGメンバーリンクインジケータフラグを使用して、ローカルインターフェイスインデックスサブTLV（セクション8で説明）を追加する必要があります。この発信LAGメンバーリンクのインターフェイスインデックスを記述します（ローカルインターフェイスインデックスはローカルLSRによって割り当てられます）。
+ The responder LSR MAY add a Remote Interface Index Sub-TLV (described in Section 9) with the LAG Member Link Indicator flag set in the Interface Index Flags field. It describes the interface index of the incoming LAG member link on the downstream LSR (this interface index is assigned by the downstream LSR). How the local LSR obtains the interface index of the LAG member link on the downstream LSR is outside the scope of this document.
+ レスポンダLSRは、インターフェースインデックスフラグフィールドにLAGメンバーリンクインジケータフラグを設定して、リモートインターフェースインデックスサブTLV（セクション9で説明）を追加できます（MAY）。ダウンストリームLSRの着信LAGメンバーリンクのインターフェイスインデックスを記述します（このインターフェイスインデックスはダウンストリームLSRによって割り当てられます）。ローカルLSRがダウンストリームLSR上のLAGメンバーリンクのインターフェイスインデックスを取得する方法は、このドキュメントの範囲外です。
+ The responder LSR MUST add a Multipath Data Sub-TLV for this LAG member link, if the received DDMAP TLV requested multipath information.
+ 受信したDDMAP TLVがマルチパス情報を要求した場合、レスポンダーLSRは、このLAGメンバーリンクのマルチパスデータサブTLVを追加する必要があります。
Based on the procedures described above, every LAG member link will have a Local Interface Index Sub-TLV and a Multipath Data Sub-TLV entry in the DDMAP TLV. The order of the sub-TLVs in the DDMAP TLV for a LAG member link MUST be Local Interface Index Sub-TLV immediately followed by Multipath Data Sub-TLV, except as follows. A LAG member link MAY also have a corresponding Remote Interface Index Sub-TLV. When a Local Interface Index Sub-TLV, a Remote Interface Index Sub-TLV, and a Multipath Data Sub-TLV are placed in the DDMAP TLV to describe a LAG member link, they MUST be placed in the order of Local Interface Index Sub-TLV, Remote Interface Index Sub-TLV, and Multipath Data Sub-TLV. The blocks of Local Interface Index, Remote Interface Index (optional), and Multipath Data Sub-TLVs for each member link MUST appear adjacent to each other and be in order of increasing local interface index.
上記の手順に基づいて、すべてのLAGメンバーリンクには、DDMAP TLVにローカルインターフェイスインデックスサブTLVとマルチパスデータサブTLVエントリがあります。 LAGメンバーリンクのDDMAP TLV内のサブTLVの順序は、次の場合を除いて、ローカルインターフェイスインデックスサブTLVの直後にマルチパスデータサブTLVが続く必要があります。 LAGメンバーリンクには、対応するリモートインターフェイスインデックスサブTLVも含まれる場合があります。ローカルインターフェイスインデックスサブTLV、リモートインターフェイスインデックスサブTLV、およびマルチパスデータサブTLVをDDMAP TLVに配置してLAGメンバーリンクを記述する場合、ローカルインターフェイスインデックスサブTLVの順序で配置する必要があります。 TLV、Remote Interface Index Sub-TLV、およびMultipath Data Sub-TLV。各メンバーリンクのローカルインターフェイスインデックス、リモートインターフェイスインデックス（オプション）、およびマルチパスデータサブTLVのブロックは、互いに隣接して表示され、ローカルインターフェイスインデックスの昇順である必要があります。
A responder LSR possessing a LAG interface with two member links would send the following DDMAP for this LAG interface:
2つのメンバーリンクを持つLAGインターフェイスを持つレスポンダLSRは、このLAGインターフェイスに次のDDMAPを送信します。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index Sub-TLV of LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of DDMAP in MPLS Echo Reply
図2：MPLSエコー応答のDDMAPの例
When none of the received multipath information maps to a particular LAG member link, then the responder LSR MUST still place the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV for that LAG member link in the DDMAP TLV. The value of the Multipath Length field of the Multipath Data Sub-TLV is set to zero.
受信したマルチパス情報が特定のLAGメンバーリンクにマップされていない場合でも、レスポンダーLSRは、そのLAGメンバーリンクのローカルインターフェイスインデックスサブTLVとマルチパスデータサブTLVをDDMAP TLVに配置する必要があります。 Multipath Data Sub-TLVのMultipath Lengthフィールドの値はゼロに設定されます。
The procedures in Section 4.2 allow an initiator LSR to:
セクション4.2の手順により、イニシエーターLSRは以下を実行できます。
o Identify whether or not the responder LSR can describe outgoing LAG member links separately, by looking at the LSR Capability TLV.
o LSR機能TLVを調べて、レスポンダーLSRが発信LAGメンバーリンクを個別に記述できるかどうかを識別します。
o Utilize the value of the LAG Description Indicator flag in DS Flags to identify whether each received DDMAP TLV describes a LAG interface or a non-LAG interface.
o DS FlagsのLAG Description Indicatorフラグの値を利用して、受信した各DDMAP TLVがLAGインターフェイスまたは非LAGインターフェイスを表すかどうかを識別します。
o Obtain multipath information that is expected to traverse the specific LAG member link described by the corresponding interface index.
o 対応するインターフェイスインデックスで記述された特定のLAGメンバーリンクを通過すると予想されるマルチパス情報を取得します。
When an initiator LSR receives a DDMAP containing LAG member information from a downstream LSR with TTL=n, then the subsequent DDMAP sent by the initiator LSR to the downstream LSR with TTL=n+1 through a particular LAG member link MUST be updated according to the following procedures:
イニシエーターLSRがTTL = nのダウンストリームLSRからLAGメンバー情報を含むDDMAPを受信すると、特定のLAGメンバーリンクを介してイニシエーターLSRがTTL = n + 1のダウンストリームLSRに送信する後続のDDMAPは、以下の手順：
o The Local Interface Index Sub-TLVs MUST be removed in the sending DDMAP.
o ローカルインターフェイスインデックスのサブTLVは、送信DDMAPから削除する必要があります。
o If the Remote Interface Index Sub-TLVs were present and the initiator LSR is traversing over a specific LAG member link, then the Remote Interface Index Sub-TLV corresponding to the LAG member link being traversed SHOULD be included in the sending DDMAP. All other Remote Interface Index Sub-TLVs MUST be removed from the sending DDMAP.
o リモートインターフェイスインデックスサブ-TLVが存在し、イニシエーターLSRが特定のLAGメンバーリンクをトラバースしている場合、トラバースされるLAGメンバーリンクに対応するリモートインターフェイスインデックスサブ-TLVを送信側DDMAPに含める必要があります。他のすべてのリモートインターフェイスインデックスサブTLVは、送信DDMAPから削除する必要があります。
o The Multipath Data Sub-TLVs MUST be updated to include just one Multipath Data Sub-TLV. The initiator LSR MAY just keep the Multipath Data Sub-TLV corresponding to the LAG member link being traversed or combine the Multipath Data Sub-TLVs for all LAG member links into a single Multipath Data Sub-TLV when diagnosing further downstream LSRs.
o マルチパスデータサブTLVは、マルチパスデータサブTLVを1つだけ含むように更新する必要があります。イニシエーターLSRは、トラバースされているLAGメンバーリンクに対応するマルチパスデータサブTLVを保持するか、さらに下流のLSRを診断するときに、すべてのLAGメンバーリンクのマルチパスデータサブTLVを単一のマルチパスデータサブTLVに結合する場合があります。
o All other fields of the DDMAP are to comply with procedures described in [RFC8029].
o DDMAPの他のすべてのフィールドは、[RFC8029]で説明されている手順に準拠しています。
Figure 3 is an example that shows how to use the DDMAP TLV to send a notification about which member link (link #1 in the example) will be chosen to send the MPLS echo request message to the next downstream LSR:
図3は、DDMAP TLVを使用して、MPLSエコー要求メッセージを次のダウンストリームLSRに送信するために選択されるメンバーリンク（例ではリンク＃1）に関する通知を送信する方法を示す例です。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DDMAP fields describing LAG interface (DS Flags with G set) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[OPTIONAL] Remote Interface Index Sub-TLV of LAG member link #1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Data Sub-TLV LAG member link #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example of DDMAP in MPLS Echo Request
図3：MPLSエコー要求のDDMAPの例
Section 4 defines the responder LSR procedures to construct a DDMAP for a downstream LAG. The Remote Interface Index Sub-TLV that describes the incoming LAG member links of the downstream LSR is optional, because this information from the downstream LSR is often not available on the responder LSR. In such case, the traversal of LAG member links can be validated with procedures described in Section 5.1. If LSRs can provide the Remote Interface Index Sub-TLVs, then the validation procedures described in Section 5.2 can be used.
セクション4では、ダウンストリームLAGのDDMAPを構築するためのレスポンダーLSR手順を定義します。ダウンストリームLSRからのこの情報はレスポンダーLSRで利用できないことが多いため、ダウンストリームLSRの着信LAGメンバーリンクを記述するリモートインターフェイスインデックスサブTLVはオプションです。そのような場合、LAGメンバーリンクのトラバーサルは、セクション5.1で説明されている手順で検証できます。 LSRがRemote Interface Index Sub-TLVを提供できる場合、セクション5.2で説明されている検証手順を使用できます。
Without downstream LSRs returning Remote Interface Index Sub-TLVs in the DDMAP, validation of the LAG member link traversal requires that the initiator LSR traverses all available LAG member links and takes the results through additional logic. This section provides the mechanism for the initiator LSR to obtain additional information from the downstream LSRs and describes the additional logic in the initiator LSR to validate the L2 ECMP traversal.
ダウンストリームLSRがDDMAPでリモートインターフェイスインデックスサブTLVを返さない場合、LAGメンバーリンクトラバーサルの検証では、イニシエーターLSRが使用可能なすべてのLAGメンバーリンクをトラバースし、追加のロジックを通じて結果を取得する必要があります。このセクションでは、イニシエーターLSRがダウンストリームLSRから追加情報を取得するメカニズムを提供し、L2 ECMPトラバーサルを検証するためのイニシエーターLSRの追加ロジックについて説明します。
An MPLS echo request carrying a DDMAP TLV with the Interface and Label Stack Object Request flag and LAG Description Indicator flag set is sent to indicate the request for Detailed Interface and Label Stack TLV with additional LAG member link information (i.e., interface index) in the MPLS echo reply.
インターフェイスおよびラベルスタックオブジェクト要求フラグとLAG説明インジケーターフラグセットが設定されたDDMAP TLVを伝送するMPLSエコー要求が送信され、追加のLAGメンバーリンク情報（つまり、インターフェイスインデックス）を持つ詳細なインターフェイスおよびラベルスタックTLVの要求を示しますMPLSエコー応答。
When it receives an echo request with the LAG Description Indicator flag set, a responder LSR that understands that flag and is capable of describing the incoming LAG member link SHOULD use the following procedures, regardless of whether or not the incoming interface was a LAG interface:
LAG Description Indicatorフラグが設定されたエコー要求を受信すると、そのフラグを理解し、着信LAGメンバーリンクを記述できるレスポンダLSRは、着信インターフェイスがLAGインターフェイスであるかどうかに関係なく、次の手順を使用する必要があります。
o When the I flag (Interface and Label Stack Object Request flag) of the DDMAP TLV in the received MPLS echo request is set:
o 受信したMPLSエコー要求のDDMAP TLVのIフラグ（インターフェースおよびラベルスタックオブジェクト要求フラグ）が設定されている場合：
* The responder LSR MUST add the Detailed Interface and Label Stack TLV (described in Section 10) in the MPLS echo reply.
* レスポンダLSRは、MPLSエコー応答に詳細インターフェイスとラベルスタックTLV（セクション10で説明）を追加する必要があります。
* If the incoming interface is a LAG, the responder LSR MUST add the Incoming Interface Index Sub-TLV (described in Section 10.1.2) in the Detailed Interface and Label Stack TLV. The LAG Member Link Indicator flag MUST be set in the Interface Index Flags field, and the Interface Index field set to the LAG member link that received the MPLS echo request.
* 着信インターフェイスがLAGの場合、レスポンダーLSRは、詳細インターフェイスとラベルスタックTLVに着信インターフェイスインデックスサブTLV（セクション10.1.2で説明）を追加する必要があります。 LAGメンバーリンクインジケーターフラグは、インターフェイスインデックスフラグフィールドに設定する必要があり、インターフェイスインデックスフィールドは、MPLSエコー要求を受信したLAGメンバーリンクに設定する必要があります。
These procedures allow the initiator LSR to utilize the Incoming Interface Index Sub-TLV in the Detailed Interface and the Label Stack TLV to derive, if the incoming interface is a LAG, the identity of the incoming LAG member.
これらの手順により、イニシエーターLSRは、詳細インターフェイスの着信インターフェイスインデックスサブTLVとラベルスタックTLVを利用して、着信インターフェイスがLAGの場合、着信LAGメンバーのIDを導出できます。
Along with procedures described in Section 4, the procedures described in this section will allow an initiator LSR to know:
セクション4で説明されている手順に加えて、このセクションで説明されている手順により、イニシエーターLSRは次のことを知ることができます。
o The expected load-balance information of every LAG member link, at LSR with TTL=n.
o TTL = nのLSRでのすべてのLAGメンバーリンクの予想される負荷分散情報。
o With specific entropy, the expected interface index of the outgoing LAG member link at TTL=n.
o 特定のエントロピーを使用して、TTL = nでの発信LAGメンバーリンクの予想されるインターフェイスインデックス。
o With specific entropy, the interface index of the incoming LAG member link at TTL=n+1.
o 特定のエントロピーでは、TTL = n + 1での着信LAGメンバーリンクのインターフェイスインデックス。
Depending on the LAG traffic division algorithm, the messages may or may not traverse different member links. The expectation is that there's a relationship between the interface index of the outgoing LAG member link at TTL=n and the interface index of the incoming LAG member link at TTL=n+1 for all entropies examined. In other words, the messages with a set of entropies that load-balances to outgoing LAG member link X at TTL=n should all reach the next hop on the same incoming LAG member link Y at TTL=n+1.
LAGトラフィック分割アルゴリズムに応じて、メッセージは異なるメンバーリンクを通過する場合と通過しない場合があります。予想されるのは、調べたすべてのエントロピーについて、TTL = nでの発信LAGメンバーリンクのインターフェイスインデックスとTTL = n + 1での着信LAGメンバーリンクのインターフェイスインデックスの間に関係があることです。つまり、TTL = nで発信LAGメンバーリンクXに負荷分散する一連のエントロピーを持つメッセージはすべて、TTL = n + 1で同じ着信LAGメンバーリンクYのネクストホップに到達する必要があります。
With additional logic, the initiator LSR can perform the following checks in a scenario where it (a) knows that there is a LAG that has two LAG members, between TTL=n and TTL=n+1, and (b) has the multipath information to traverse the two LAG member links.
追加のロジックにより、イニシエーターLSRは、（a）TTL = nとTTL = n + 1の間に2つのLAGメンバーがあるLAGがあり、（b）マルチパスがあるというシナリオで次のチェックを実行できます2つのLAGメンバーリンクをトラバースするための情報。
The initiator LSR sends two MPLS echo request messages to traverse the two LAG member links at TTL=n+1:
イニシエーターLSRは2つのMPLSエコー要求メッセージを送信して、TTL = n + 1で2つのLAGメンバーリンクを通過します。
o Success case:
o 成功事例：
* One MPLS echo request message reaches TTL=n+1 on LAG member link 1.
* 1つのMPLSエコー要求メッセージがLAGメンバーリンク1でTTL = n + 1に到達します。
* The other MPLS echo request message reaches TTL=n+1 on LAG member link 2.
* 他のMPLSエコー要求メッセージは、LAGメンバーリンク2でTTL = n + 1に到達します。
The two MPLS echo request messages sent by the initiator LSR reach the immediate downstream LSR from two different LAG member links.
イニシエーターLSRによって送信された2つのMPLSエコー要求メッセージは、2つの異なるLAGメンバーリンクからすぐ下流のLSRに到達します。
o Error case:
o エラーケース：
* One MPLS echo request message reaches TTL=n+1 on LAG member link 1.
* 1つのMPLSエコー要求メッセージがLAGメンバーリンク1でTTL = n + 1に到達します。
* The other MPLS echo request message also reaches TTL=n+1 on LAG member link 1.
* 他のMPLSエコー要求メッセージも、LAGメンバーリンク1でTTL = n + 1に到達します。
* One or both MPLS echo request messages cannot reach the immediate downstream LSR on whichever link.
* 一方または両方のMPLSエコー要求メッセージは、どちらのリンクでもすぐ下流のLSRに到達できません。
One or two MPLS echo request messages sent by the initiator LSR cannot reach the immediate downstream LSR, or the two MPLS echo request messages reach at the immediate downstream LSR from the same LAG member link.
イニシエーターLSRによって送信された1つまたは2つのMPLSエコー要求メッセージが直接ダウンストリームLSRに到達できないか、2つのMPLSエコー要求メッセージが同じLAGメンバーリンクから直接ダウンストリームLSRに到達します。
Note that the procedures defined above will provide a deterministic result for LAG interfaces that are back-to-back connected between LSRs (i.e., no L2 switch in between). If there is an L2 switch between the LSR at TTL=n and the LSR at TTL=n+1, there is no guarantee that every incoming interface at TTL=n+1 can be traversed, even when traversing every outgoing LAG member link at TTL=n. Issues resulting from LAG with an L2 switch in between are further described in Appendix A. LAG provisioning models in operator networks should be considered when analyzing the output of LSP Traceroute that is exercising L2 ECMPs.
上記で定義された手順は、LSR間でバックツーバック接続されている（つまり、間にL2スイッチがない）LAGインターフェースの確定的な結果を提供することに注意してください。 TTL = nのLSRとTTL = n + 1のLSRの間にL2スイッチがある場合、すべての発信LAGメンバーリンクを通過する場合でも、TTL = n + 1のすべての着信インターフェースを通過できる保証はありません。 TTL = n。 L2スイッチが間にあるLAGに起因する問題については、付録Aで詳しく説明します。L2ECMPを実行しているLSP Tracerouteの出力を分析するときは、オペレーターネットワークのLAGプロビジョニングモデルを考慮する必要があります。
When the Remote Interface Index Sub-TLVs are available from an LSR with TTL=n, then the validation of LAG member link traversal can be performed by the downstream LSR of TTL=n+1. The initiator LSR follows the procedures described in Section 4.3.
リモートインターフェイスインデックスサブTLVがTTL = nのLSRから利用できる場合、LAGメンバーリンクトラバーサルの検証は、TTL = n + 1のダウンストリームLSRによって実行できます。イニシエータLSRは、セクション4.3で説明されている手順に従います。
The DDMAP validation procedures for the downstream responder LSR are then updated to include the comparison of the incoming LAG member link to the interface index described in the Remote Interface Index Sub-TLV in the DDMAP TLV. Failure of this comparison results in the return code being set to "Downstream Mapping Mismatch (5)".
次に、ダウンストリームレスポンダーLSRのDDMAP検証手順が更新され、着信LAGメンバーリンクとDDMAP TLVのリモートインターフェイスインデックスサブTLVで説明されているインターフェイスインデックスとの比較が含まれます。この比較に失敗すると、戻りコードが「ダウンストリームマッピングの不一致（5）」に設定されます。
This document defines a new TLV that is referred to as the LSR Capability TLV. It MAY be included in the MPLS echo request message and the MPLS echo reply message. An MPLS echo request message and an MPLS echo reply message MUST NOT include more than one LSR Capability TLV. The presence of an LSR Capability TLV in an MPLS echo request message is a request that a responder LSR includes an LSR Capability TLV in the MPLS echo reply message, with the LSR Capability TLV describing features and extensions that the responder LSR supports.
このドキュメントでは、LSR機能TLVと呼ばれる新しいTLVを定義します。これは、MPLSエコー要求メッセージとMPLSエコー応答メッセージに含めることができます。 MPLSエコー要求メッセージとMPLSエコー応答メッセージには、複数のLSR機能TLVを含めることはできません。 MPLSエコー要求メッセージ内のLSR機能TLVの存在は、レスポンダーLSRがMPLSエコー応答メッセージ内のLSR機能TLVを含み、LSR機能TLVがレスポンダーLSRがサポートする機能と拡張機能を記述しているという要求です。
The format of the LSR Capability TLV is as below:
LSR機能TLVのフォーマットは次のとおりです。
LSR Capability TLV Type is 4. Length is 4. The LSR Capability TLV has the following format:
LSR機能TLVタイプは4です。長さは4です。LSR機能TLVの形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSR Capability TLV
図4：LSR機能TLV
Where:
ただし：
The Type field is 2 octets in length, and the value is 4.
Typeフィールドの長さは2オクテットで、値は4です。
The Length field is 2 octets in length, and the value is 4.
長さフィールドの長さは2オクテットで、値は4です。
The LSR Capability Flags field is 4 octets in length; this document defines the following flags:
LSR機能フラグフィールドの長さは4オクテットです。このドキュメントでは、次のフラグを定義しています。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |U|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines two flags. The unallocated flags MUST be set to zero when sending and ignored on receipt. Both the U and the D flag MUST be cleared in the MPLS echo request message when sending and ignored on receipt. Zero, one, or both of the flags (U and D) MAY be set in the MPLS echo reply message.
このドキュメントでは、2つのフラグを定義しています。未割り当てフラグは、送信時にゼロに設定し、受信時に無視する必要があります。送信時にMPLSエコー要求メッセージでUフラグとDフラグの両方をクリアし、受信時に無視する必要があります。ゼロ、1つ、または両方のフラグ（UおよびD）がMPLSエコー応答メッセージに設定される場合があります。
Flag Name and Meaning
---- ----------------
U Upstream LAG Info Accommodation
UアップストリームLAG情報
An LSR sets this flag when the LSR is capable of describing a LAG member link in the Incoming Interface Index Sub-TLV in the Detailed Interface and Label Stack TLV.
LSRがこのフラグを設定するのは、LSRが詳細なインターフェイスとラベルスタックTLVの着信インターフェイスインデックスサブTLVでLAGメンバーリンクを記述できる場合です。
D Downstream LAG Info Accommodation
DダウンストリームLAG情報
An LSR sets this flag when the LSR is capable of describing LAG member links in the Local Interface Index Sub-TLV and the Multipath Data Sub-TLV in the Downstream Detailed Mapping TLV.
LSRがローカルインターフェースインデックスサブTLVのLAGメンバーリンクとダウンストリーム詳細マッピングTLVのマルチパスデータサブTLVを記述できる場合、LSRはこのフラグを設定します。
This document defines a new flag, the G flag (LAG Description Indicator), in the DS Flags field of the DDMAP TLV.
このドキュメントでは、DDMAP TLVのDSフラグフィールドに新しいフラグであるGフラグ（LAG説明インジケーター）を定義しています。
The G flag in the MPLS echo request message indicates the request for detailed LAG information from the responder LSR. In the MPLS echo reply message, the G flag MUST be set if the DDMAP TLV describes a LAG interface. It MUST be cleared otherwise.
MPLSエコー要求メッセージのGフラグは、レスポンダーLSRからの詳細なLAG情報の要求を示します。 MPLSエコー応答メッセージでは、DDMAP TLVがLAGインターフェイスを記述する場合、Gフラグを設定する必要があります。それ以外の場合はクリアする必要があります。
The G flag is defined as below:
Gフラグは次のように定義されています。
The Bit Number is 3.
ビット番号は3です。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |G|E|L|I|N|
+-+-+-+-+-+-+-+-+
Flag Name and Meaning
---- ----------------
G LAG Description Indicator
G LAG説明インジケーター
When this flag is set in the MPLS echo request, the responder LSR is requested to respond with detailed LAG information. When this flag is set in the MPLS echo reply, the corresponding DDMAP TLV describes a LAG interface.
このフラグがMPLSエコー要求で設定されると、レスポンダーLSRは、詳細なLAG情報で応答するように要求されます。このフラグがMPLSエコー応答で設定されている場合、対応するDDMAP TLVはLAGインターフェイスを記述します。
The Local Interface Index Sub-TLV describes the interface index assigned by the local LSR to an egress interface. One or more Local Interface Index sub-TLVs MAY appear in a DDMAP TLV.
ローカルインターフェイスインデックスサブTLVは、ローカルLSRによって出力インターフェイスに割り当てられたインターフェイスインデックスを記述します。 1つ以上のローカルインターフェイスインデックスサブTLVがDDMAP TLVに表示される場合があります。
The format of the Local Interface Index Sub-TLV is below:
Local Interface Index Sub-TLVの形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Local Interface Index Sub-TLV
図5：ローカルインターフェイスインデックスサブTLV
Where:
ただし：
o The Type field is 2 octets in length, and the value is 4.
o Typeフィールドの長さは2オクテットで、値は4です。
o The Length field is 2 octets in length, and the value is 4.
o 長さフィールドの長さは2オクテットで、値は4です。
o The Local Interface Index field is 4 octets in length; it is an interface index assigned by a local LSR to an egress interface. It's normally an unsigned integer and in network byte order.
o ローカルインターフェイスインデックスフィールドの長さは4オクテットです。これは、ローカルLSRによって出力インターフェイスに割り当てられたインターフェイスインデックスです。これは通常、符号なし整数で、ネットワークバイトオーダーです。
The Remote Interface Index Sub-TLV is an optional TLV; it describes the interface index assigned by a downstream LSR to an ingress interface. One or more Remote Interface Index sub-TLVs MAY appear in a DDMAP TLV.
Remote Interface Index Sub-TLVはオプションのTLVです。ダウンストリームLSRによって入力インターフェイスに割り当てられたインターフェイスインデックスについて説明します。 1つ以上のリモートインターフェイスインデックスサブTLVがDDMAP TLVに表示される場合があります。
The format of the Remote Interface Index Sub-TLV is below:
Remote Interface Index Sub-TLVのフォーマットは以下のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Remote Interface Index Sub-TLV
図6：リモートインターフェイスインデックスサブTLV
Where:
ただし：
o The Type field is 2 octets in length, and the value is 5.
o Typeフィールドの長さは2オクテットで、値は5です。
o The Length field is 2 octets in length, and the value is 4.
o 長さフィールドの長さは2オクテットで、値は4です。
o The Remote Interface Index field is 4 octets in length; it is an interface index assigned by a downstream LSR to an ingress interface. It's normally an unsigned integer and in network byte order.
o Remote Interface Indexフィールドは4オクテットの長さです。これは、ダウンストリームLSRによって入力インターフェイスに割り当てられたインターフェイスインデックスです。これは通常、符号なし整数で、ネットワークバイトオーダーです。
The Detailed Interface and Label Stack TLV MAY be included in an MPLS echo reply message to report the interface on which the MPLS echo request message was received and the label stack that was on the packet when it was received. A responder LSR MUST NOT insert more than one instance of this TLV into the MPLS echo reply message. This TLV allows the initiator LSR to obtain the exact interface and label stack information as it appears at the responder LSR.
詳細なインターフェイスとラベルスタックTLVをMPLSエコー応答メッセージに含めて、MPLSエコー要求メッセージが受信されたインターフェイスと、パケットが受信されたときにパケット上にあったラベルスタックを報告する場合があります。レスポンダーLSRは、このTLVの複数のインスタンスをMPLSエコー応答メッセージに挿入してはなりません（MUST NOT）。このTLVにより、イニシエーターLSRは、レスポンダーLSRに表示される正確なインターフェイスとラベルスタック情報を取得できます。
Detailed Interface and Label Stack TLV Type is 6. Length is K + Sub-TLV Length (sum of Sub-TLVs). K is the sum of all fields of this TLV prior to the list of Sub-TLVs, but the length of K depends on the Address Type. Details of this information is described below. The Detailed Interface and Label Stack TLV has the following format:
詳細なインターフェイスとラベルスタックのTLVタイプは6です。長さはK +サブTLV長さ（サブTLVの合計）です。 Kは、サブTLVのリストの前のこのTLVのすべてのフィールドの合計ですが、Kの長さはアドレスタイプによって異なります。この情報の詳細を以下に説明します。詳細インターフェイスとラベルスタックTLVの形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. List of Sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Detailed Interface and Label Stack TLV
図7：詳細なインターフェイスとラベルスタックTLV
The Detailed Interface and Label Stack TLV format is derived from the Interface and Label Stack TLV format (from [RFC8029]). Two changes are introduced. The first is that the label stack is converted into a sub-TLV. The second is that a new sub-TLV is added to describe an interface index. The other fields of the Detailed Interface and Label Stack TLV have the same use and meaning as in [RFC8029]. A summary of these fields is as below:
詳細なインターフェイスとラベルスタックのTLV形式は、インターフェイスとラベルスタックのTLV形式（[RFC8029]から）から派生しています。 2つの変更が導入されました。 1つ目は、ラベルスタックがサブTLVに変換されることです。 2つ目は、インターフェイスインデックスを記述するために新しいサブTLVが追加されることです。詳細インターフェイスとラベルスタックTLVの他のフィールドは、[RFC8029]と同じ使用法と意味を持っています。これらのフィールドの要約は次のとおりです。
Address Type
住所タイプ
The Address Type indicates if the interface is numbered or unnumbered. It also determines the length of the IP Address and Interface fields. The resulting total length of the initial part of the TLV is listed as "K Octets". The Address Type is set to one of the following values:
アドレスタイプは、インターフェイスに番号が付いているか番号が付いていないかを示します。また、IPアドレスおよびインターフェースフィールドの長さも決定します。 TLVの最初の部分の結果の全長は「Kオクテット」としてリストされます。アドレスタイプは、次のいずれかの値に設定されます。
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
IP Address and Interface
IPアドレスとインターフェース
IPv4 addresses and interface indices are encoded in 4 octets; IPv6 addresses are encoded in 16 octets.
IPv4アドレスとインターフェイスインデックスは4オクテットでエンコードされます。 IPv6アドレスは16オクテットでエンコードされます。
If the interface upon which the echo request message was received is numbered, then the Address Type MUST be set to IPv4 Numbered or IPv6 Numbered, the IP Address MUST be set to either the LSR's Router ID or the interface address, and the Interface MUST be set to the interface address.
エコー要求メッセージが受信されたインターフェースに番号が付けられている場合、アドレスタイプはIPv4番号またはIPv6番号に設定する必要があり、IPアドレスはLSRのルーターIDまたはインターフェースアドレスのいずれかに設定する必要があり、インターフェースはインターフェイスアドレスに設定します。
If the interface is unnumbered, the Address Type MUST be either IPv4 Unnumbered or IPv6 Unnumbered, the IP Address MUST be the LSR's Router ID, and the Interface MUST be set to the index assigned to the interface.
インターフェースが番号なしの場合、アドレスタイプはIPv4番号なしまたはIPv6番号なしでなければならず、IPアドレスはLSRのルーターIDでなければならず、インターフェースはインターフェースに割り当てられたインデックスに設定する必要があります。
Note: Usage of IPv6 Unnumbered has the same issue as [RFC8029], which is described in Section 3.4.2 of [RFC7439]. A solution should be considered and applied to both [RFC8029] and this document.
注：IPv6アンナンバードの使用には、[RFC7439]のセクション3.4.2で説明されている[RFC8029]と同じ問題があります。解決策を検討し、[RFC8029]とこのドキュメントの両方に適用する必要があります。
This section defines the sub-TLVs that MAY be included as part of the Detailed Interface and Label Stack TLV. Two sub-TLVs are defined:
このセクションでは、詳細インターフェイスとラベルスタックTLVの一部として含めることができるサブTLVを定義します。 2つのサブTLVが定義されています。
Sub-Type Sub-TLV Name
--------- ------------
1 Incoming Label Stack
2 Incoming Interface Index
The Incoming Label Stack Sub-TLV contains the label stack as received by an LSR. If any TTL values have been changed by this LSR, they SHOULD be restored.
Incoming Label Stack Sub-TLVには、LSRが受信したラベルスタックが含まれています。このLSRによってTTL値が変更された場合、それらを復元する必要があります（SHOULD）。
Incoming Label Stack Sub-TLV Type is 1. Length is variable, and its format is as below:
着信ラベルスタックのサブTLVタイプは1です。長さは可変で、その形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Incoming Label Stack Sub-TLV
図8：着信ラベルスタックサブTLV
The Incoming Interface Index Sub-TLV MAY be included in a Detailed Interface and Label Stack TLV. The Incoming Interface Index Sub-TLV describes the index assigned by a local LSR to the interface that received the MPLS echo request message.
Incoming Interface Index Sub-TLVは、Detailed Interface and Label Stack TLVに含まれる場合があります。 Incoming Interface Index Sub-TLVは、MPLSエコー要求メッセージを受信したインターフェイスにローカルLSRによって割り当てられたインデックスを示します。
Incoming Interface Index Sub-TLV Type is 2. Length is 8, and its format is as below:
Incoming Interface Index Sub-TLV Typeは2です。長さは8で、形式は次のとおりです。
0 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index Flags | Reserved (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Incoming Interface Index Sub-TLV
図9：着信インターフェイスインデックスサブTLV
Interface Index Flags
インターフェイスインデックスフラグ
The Interface Index Flags field is a bit vector with following format.
Interface Index Flagsフィールドは、次の形式のビットベクトルです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Must Be Zero) |M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag is defined: M. The remaining flags MUST be set to zero when sending and ignored on receipt.
1つのフラグが定義されています：M。残りのフラグは、送信時にゼロに設定し、受信時に無視する必要があります。
Flag Name and Meaning
---- ----------------
M LAG Member Link Indicator
M LAGメンバーリンクインジケーター
When this flag is set, the interface index described in this sub-TLV is a member of a LAG.
このフラグが設定されている場合、このサブTLVに記述されているインターフェイスインデックスはLAGのメンバーです。
Incoming Interface Index
着信インターフェイスインデックス
An Index assigned by the LSR to this interface. It's normally an unsigned integer and in network byte order.
LSRによってこのインターフェースに割り当てられたインデックス。これは通常、符号なし整数で、ネットワークバイトオーダーです。
An LSP may be over several LAGs. Each LAG may have many member links. To exercise all the links, many echo request/reply messages will be sent in a short period. It's possible that those messages may traverse a common path as a burst. Under some circumstances, this might cause congestion at the common path. To avoid potential congestion, it is RECOMMENDED that implementations randomly delay the echo request and reply messages at the initiator LSRs and responder LSRs. Rate-limiting of ping traffic is further specified in Section 5 of [RFC8029] and Section 4.1 of [RFC6425], which apply to this document as well.
LSPは複数のLAGを超える場合があります。各LAGには多数のメンバーリンクが含まれる場合があります。すべてのリンクを実行するために、多くのエコー要求/応答メッセージが短期間に送信されます。これらのメッセージがバーストとして共通のパスを通過する可能性があります。状況によっては、これにより共通パスで輻輳が発生する可能性があります。潜在的な輻輳を回避するために、実装はイニシエーターLSRとレスポンダーLSRでエコー要求と応答メッセージをランダムに遅延させることをお勧めします。 pingトラフィックのレート制限は、[RFC8029]のセクション5と[RFC6425]のセクション4.1でさらに指定されており、このドキュメントにも適用されます。
This document extends the LSP Traceroute mechanism [RFC8029] to discover and exercise L2 ECMP paths to determine problematic member link(s) of a LAG. These on-demand diagnostic mechanisms are used by an operator within an MPLS control domain.
このドキュメントは、LSP Tracerouteメカニズム[RFC8029]を拡張して、LAGの問題のあるメンバーリンクを特定するためにL2 ECMPパスを検出および実行します。これらのオンデマンド診断メカニズムは、MPLS制御ドメイン内のオペレーターによって使用されます。
[RFC8029] reviews the possible attacks and approaches to mitigate possible threats when using these mechanisms.
[RFC8029]は、これらのメカニズムを使用する場合に起こり得る攻撃と可能性のある脅威を軽減するためのアプローチをレビューします。
To prevent leakage of vital information to untrusted users, a responder LSR MUST only accept MPLS echo request messages from designated trusted sources via filtering the source IP address field of received MPLS echo request messages. As noted in [RFC8029], spoofing attacks only have a small window of opportunity. If an intermediate node hijacks these messages (i.e., causes non-delivery), the use of these mechanisms will determine the data plane is not working as it should. Hijacking of a responder node such that it provides a legitimate reply would involve compromising the node itself and the MPLS control domain. [RFC5920] provides additional MPLS network-wide operation recommendations to avoid attacks. Please note that source IP address filtering provides only a weak form of access control and is not, in general, a reliable security mechanism. Nonetheless, it is required here in the absence of any more robust mechanisms that might be used.
信頼できないユーザーへの重要な情報の漏えいを防ぐために、レスポンダーLSRは、受信したMPLSエコー要求メッセージのソースIPアドレスフィールドをフィルタリングすることにより、指定された信頼できるソースからのMPLSエコー要求メッセージのみを受け入れる必要があります。 [RFC8029]で述べられているように、なりすまし攻撃の機会はごくわずかです。中間ノードがこれらのメッセージを乗っ取る（つまり、配信されない）場合、これらのメカニズムを使用すると、データプレーンが正常に機能していないと判断されます。正当な応答を提供するような応答側ノードのハイジャックには、ノード自体とMPLS制御ドメインの侵害が含まれます。 [RFC5920]は、攻撃を回避するための追加のMPLSネットワーク全体の運用に関する推奨事項を提供します。送信元IPアドレスフィルタリングは弱い形式のアクセス制御しか提供せず、一般に信頼できるセキュリティメカニズムではないことに注意してください。それにもかかわらず、ここでは、使用される可能性のあるより堅牢なメカニズムがない場合に必要です。
IANA has assigned value 4 (from the range 0-16383) for the LSR Capability TLV from the "TLVs" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリの下の「TLVs」レジストリからLSR機能TLVに値4（範囲0〜16383）を割り当てました[IANA-MPLS-LSP- PING]。
Type TLV Name Reference
----- -------- ---------
4 LSR Capability RFC 8611
IANA has created a new "LSR Capability Flags" registry. The initial contents are as follows:
IANAは新しい「LSR機能フラグ」レジストリを作成しました。初期の内容は次のとおりです。
Value Meaning Reference
----- ------- ---------
31 D: Downstream LAG Info Accommodation RFC 8611
30 U: Upstream LAG Info Accommodation RFC 8611
0-29 Unassigned
Assignments of LSR Capability Flags are via Standards Action [RFC8126].
LSR機能フラグの割り当ては、標準アクション[RFC8126]を介して行われます。
IANA has assigned value 4 (from the range 0-16383) for the Local Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched」の「TLVs」レジストリの「Sub-TLVs for TLV Type 20」サブレジストリから、Local Interface Index Sub-TLVに値4（範囲0〜16383）を割り当てましたパス（LSP）Pingパラメータ」レジストリ[IANA-MPLS-LSP-PING]。
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
4 Local Interface Index RFC 8611
IANA has created a new "Interface Index Flags" registry. The initial contents are as follows:
IANAは新しい「インターフェースインデックスフラグ」レジストリを作成しました。初期の内容は次のとおりです。
Bit Number Name Reference
---------- -------------------------------- ---------
15 M: LAG Member Link Indicator RFC 8611
0-14 Unassigned
Assignments of Interface Index Flags are via Standards Action [RFC8126].
インターフェイスインデックスフラグの割り当ては、標準アクション[RFC8126]を介して行われます。
Note that this registry is used by the Interface Index Flags field of the following sub-TLVs:
このレジストリは、次のサブTLVのInterface Index Flagsフィールドで使用されることに注意してください。
o The Local Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV.
o ローカルインターフェイスインデックスサブTLV。これは、ダウンストリーム詳細マッピングTLVに存在する場合があります。
o The Remote Interface Index Sub-TLV, which may be present in the Downstream Detailed Mapping TLV.
o ダウンストリーム詳細マッピングTLVに存在する可能性があるリモートインターフェイスインデックスサブTLV。
o The Incoming Interface Index Sub-TLV, which may be present in the Detailed Interface and Label Stack TLV.
o 詳細インターフェイスおよびラベルスタックTLVに存在する可能性がある着信インターフェイスインデックスサブTLV。
IANA has assigned value 5 (from the range 0-16383) for the Remote Interface Index Sub-TLV from the "Sub-TLVs for TLV Type 20" subregistry of the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched」の「TLVs」レジストリの「Sub-TLVs for TLV Type 20」サブレジストリから、Remote Interface Index Sub-TLVに値5（範囲0-16383）を割り当てましたパス（LSP）Pingパラメータ」レジストリ[IANA-MPLS-LSP-PING]。
Sub-Type Sub-TLV Name Reference
-------- ------------ ---------
5 Remote Interface Index RFC 8611
IANA has assigned value 6 (from the range 0-16383) for the Detailed Interface and Label Stack TLV from the "TLVs" registry in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリの「TLVs」レジストリから、Detailed InterfaceおよびLabel Stack TLVに値6（範囲0〜16383）を割り当てました[IANA-MPLS -LSP-PING]。
Type TLV Name Reference
----- -------- ---------
6 Detailed Interface and Label Stack RFC 8611
RFC 8029 changed the registration procedures for TLV and sub-TLV registries for LSP Ping.
RFC 8029は、LSP PingのTLVおよびサブTLVレジストリの登録手順を変更しました。
IANA has created a new "Sub-TLVs for TLV Type 6" subregistry under the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリ[IANA-MPLS-LSP-PING]の「TLVs」レジストリの下に、新しい「Sub-TLVs for TLV Type 6」サブレジストリを作成しました。
This registry conforms with RFC 8029.
このレジストリはRFC 8029に準拠しています。
The registration procedures for this sub-TLV registry are:
このサブTLVレジストリの登録手順は次のとおりです。
Range Registration Procedure Note
----- ---------------------- -----
0-16383 Standards Action This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
16384-31743 RFC Required This range is for mandatory
TLVs or for optional TLVs that
require an error message if
not recognized.
31744-32767 Private Use Not to be assigned
32768-49161 Standards Action This range is for optional TLVs
that can be silently dropped if
not recognized.
49162-64511 RFC Required This range is for optional TLVs
that can be silently dropped if
not recognized.
64512-65535 Private Use Not to be assigned
The initial allocations for this registry are:
このレジストリの初期割り当ては次のとおりです。
Sub-Type Sub-TLV Name Reference Comment
-------- ------------ --------- -------
0 Reserved RFC 8611
1 Incoming Label Stack RFC 8611
2 Incoming Interface Index RFC 8611
3-31743 Unassigned
31744-32767 RFC 8611 Reserved for
Private Use
32768-64511 Unassigned
64512-65535 RFC 8611 Reserved for
Private Use
Note: IETF does not prescribe how the Private Use sub-TLVs are handled; however, if a packet containing a sub-TLV from a Private Use ranges is received by an LSR that does not recognize the sub-TLV, an error message MAY be returned if the sub-TLV is from the range 31744-32767, and the packet SHOULD be silently dropped if it is from the range 64511-65535.
注：IETFは、Private UseサブTLVの処理方法を規定していません。ただし、私用範囲からのサブTLVを含むパケットがサブTLVを認識しないLSRによって受信された場合、サブTLVが31744〜32767の範囲からのものである場合、エラーメッセージが返される場合があります。パケットが64511-65535の範囲にある場合、パケットは警告なしにドロップされるべきです（SHOULD）。
The Detailed Interface and Label Stack TLV shares the Interface and Label Stack Address Types with the Interface and Label Stack TLV. To reflect this, IANA has updated the name of the registry from "Interface and Label Stack Address Types" to "Interface and Label Stack and Detailed Interface and Label Stack Address Types".
詳細なインターフェイスおよびラベルスタックTLVは、インターフェイスおよびラベルスタックアドレスタイプをインターフェイスおよびラベルスタックTLVと共有します。これを反映するために、IANAはレジストリの名前を「インターフェースとラベルスタックのアドレスタイプ」から「インターフェースとラベルスタックと詳細なインターフェースとラベルスタックアドレスタイプ」に更新しました。
IANA has assigned a new bit number from the "DS Flags" subregistry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA-MPLS-LSP-PING].
IANAは、「Multiprotocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリ[IANA-MPLS-LSP-PING]の「DS Flags」サブレジストリから新しいビット番号を割り当てました。
Note: the "DS Flags" subregistry was created by [RFC8029].
注：「DS Flags」サブレジストリは[RFC8029]によって作成されました。
Bit number Name Reference
---------- ---------------------------------------- ---------
3 G: LAG Description Indicator RFC 8611
[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>。
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、and M. Chen、 "Detecting Multiprotocol Label Switched（MPLS）Data-Plane Failures、" RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https://www.rfc-editor.org/info/rfc8029>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[IANA-MPLS-LSP-PING] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <https://www.iana.org/assignments/ mpls-lsp-ping-parameters/>.
[IANA-MPLS-LSP-PING] IANA、「Multiprotocol Label Switching（MPLS）Label Switched Paths（LSPs）Ping Parameters」、<https://www.iana.org/assignments/ mpls-lsp-ping-parameters /> 。
[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std. 802.1AX.
[IEEE802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Link Aggregation」、IEEE Std。 802.1AX。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<https://www.rfc-editor.org/info/rfc5920>。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>.
[RFC6425] Saxena、S.、Ed。、Swallow、G.、Ali、Z.、Farrel、A.、Yasukawa、S.、and T. Nadeau、 "Detecting Data-Plane Failures in Point-to-Multipoint MPLS- LSP Pingの拡張機能」、RFC 6425、DOI 10.17487 / RFC6425、2011年11月、<https://www.rfc-editor.org/info/rfc6425>。
[RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, DOI 10.17487/RFC7439, January 2015, <https://www.rfc-editor.org/info/rfc7439>.
[RFC7439]ジョージ、W、エド。 C. Pignataro、編、「IPv6のみのMPLSネットワークを操作するためのギャップ分析」、RFC 7439、DOI 10.17487 / RFC7439、2015年1月、<https://www.rfc-editor.org/info/rfc7439>。
Several flavors of provisioning models that use a "LAG with L2 switch" and the corresponding MPLS data-plane ECMP traversal validation issues are described in this appendix.
この付録では、「L2スイッチを備えたLAG」を使用するプロビジョニングモデルのいくつかの種類と、対応するMPLSデータプレーンECMPトラバーサル検証の問題について説明します。
R1 ==== S1 ==== R2
The issue with this LAG provisioning model is that packets traversing a LAG member from Router 1 (R1) to intermediate L2 switch (S1) can get load-balanced by S1 towards Router 2 (R2). Therefore, MPLS echo request messages traversing a specific LAG member from R1 to S1 can actually reach R2 via any of the LAG members, and the sender of the MPLS echo request messages has no knowledge of this nor any way to control this traversal. In the worst case, MPLS echo request messages with specific entropies will exercise every LAG member link from R1 to S1 and can all reach R2 via the same LAG member link. Thus, it is impossible for the MPLS echo request sender to verify that packets intended to traverse a specific LAG member link from R1 to S1 did actually traverse that LAG member link and to deterministically exercise "receive" processing of every LAG member link on R2. (Note: As far as we can tell, there's not a better option than "try a bunch of entropy labels and see what responses you can get back", and that's the same remedy in all the described topologies.)
このLAGプロビジョニングモデルの問題は、ルーター1（R1）から中間L2スイッチ（S1）にLAGメンバーを通過するパケットが、ルーター1（R2）に向けてS1によって負荷分散される可能性があることです。したがって、特定のLAGメンバーをR1からS1にトラバースするMPLSエコー要求メッセージは、実際には任意のLAGメンバーを介してR2に到達でき、MPLSエコー要求メッセージの送信者はこれを認識せず、このトラバーサルを制御する方法もありません。最悪の場合、特定のエントロピーを持つMPLSエコー要求メッセージは、すべてのLAGメンバーリンクをR1からS1に行使し、すべて同じLAGメンバーリンクを介してR2に到達できます。したがって、MPLSエコー要求の送信者は、特定のLAGメンバーリンクをR1からS1にトラバースすることを目的としたパケットが実際にそのLAGメンバーリンクをトラバースし、R2上のすべてのLAGメンバーリンクの「受信」処理を確定的に実行することを確認できません。 （注：私たちが知る限り、「一連のエントロピーラベルを試して、どのような応答が返されるかを確認する」よりも優れたオプションはありません。これは、説明されているすべてのトポロジで同じ方法です。）
____
R1 ==== S1 ==== R2
There are deviating numbers of LAG members on the two sides of the L2 switch. The issue with this LAG provisioning model is the same as with the previous model: the sender of MPLS echo request messages has no knowledge of the L2 load-balancing algorithm nor entropy values to control the traversal.
L2スイッチの両側に異なる数のLAGメンバーがあります。このLAGプロビジョニングモデルの問題は前のモデルと同じです。MPLSエコー要求メッセージの送信者は、L2ロードバランシングアルゴリズムの知識も、走査を制御するエントロピー値も持っていません。
R1 ---- S1 ==== R2
The issue with this LAG provisioning model is that there is no way for an MPLS echo request sender to deterministically exercise both LAG member links from S1 to R2. And without such, "receive" processing of R2 on each LAG member cannot be verified.
このLAGプロビジョニングモデルの問題は、MPLSエコー要求送信者がS1からR2への両方のLAGメンバーリンクを確定的に実行する方法がないことです。そして、これがないと、各LAGメンバーでのR2の「受信」処理を検証できません。
R1 ==== S1 ---- R2
The MPLS echo request sender has knowledge of how to traverse both LAG members from R1 to S1. However, both types of packets will terminate on the non-LAG interface at R2. It becomes impossible for the MPLS echo request sender to know that MPLS echo request messages intended to traverse a specific LAG member from R1 to S1 did indeed traverse that LAG member.
MPLSエコー要求の送信者は、両方のLAGメンバーをR1からS1にトラバースする方法を知っています。ただし、どちらのタイプのパケットも、R2の非LAGインターフェイスで終端します。 MPLSエコー要求の送信者は、特定のLAGメンバーをR1からS1にトラバースすることを目的としたMPLSエコー要求メッセージが実際にそのLAGメンバーをトラバースしたことを知ることができなくなります。
Acknowledgements
謝辞
The authors would like to thank Nagendra Kumar and Sam Aldrin for providing useful comments and suggestions. The authors would like to thank Loa Andersson for performing a detailed review and providing a number of comments.
著者は、有用なコメントと提案を提供してくれたNagendra KumarとSam Aldrinに感謝します。著者は、詳細なレビューを行い、多数のコメントを提供してくれたLoa Anderssonに感謝します。
The authors also would like to extend sincere thanks to the MPLS RT review members who took the time to review and provide comments. The members are Eric Osborne, Mach Chen, and Yimin Shen. The suggestion by Mach Chen to generalize and create the LSR Capability TLV was tremendously helpful for this document and likely for future documents extending the MPLS LSP Ping and Traceroute mechanisms. The suggestion by Yimin Shen to create two separate validation procedures had a big impact on the contents of this document.
著者はまた、時間をかけてレビューを行い、コメントを提供してくれたMPLS RTレビューメンバーに心から感謝したいと思います。メンバーはエリック・オズボーン、マッハ・チェン、イミン・シェンです。 LSR機能TLVを一般化して作成するというMach Chenの提案は、このドキュメントにとって非常に役立ち、MPLS LSP PingおよびTracerouteメカニズムを拡張する将来のドキュメントにとっても非常に役立ちました。 2つの個別の検証手順を作成するというYimin Shenの提案は、このドキュメントの内容に大きな影響を与えました。
Authors' Addresses
著者のアドレス
Nobo Akiya Big Switch Networks
Nobo Akiya Big Switch Networks
Email: nobo.akiya.dev@gmail.com
George Swallow Southend Technical Center
ジョージスワローサウスエンドテクニカルセンター
Email: swallow.ietf@gmail.com
Stephane Litkowski Orange
ステファンリトコウスキーオレンジ
Email: stephane.litkowski@orange.com
Bruno Decraene Orange
ブルーノデクレイエンオレンジ
Email: bruno.decraene@orange.com
John E. Drake Juniper Networks
ジョンE.ドレイクジュニパーネットワークス
Email: jdrake@juniper.net
Mach(Guoyi) Chen Huawei
マッハ（GUお一）陳湖Aは
Email: mach.chen@huawei.com