[要約] RFC 7737は、Label Switched Path (LSP) PingおよびTracerouteの応答モードの簡素化に関するものです。その目的は、LSP PingおよびTracerouteの応答モードをより効率的かつ簡潔にすることです。
Internet Engineering Task Force (IETF) N. Akiya
Request for Comments: 7737 Big Switch Networks
Updates: 7110 G. Swallow
Category: Standards Track C. Pignataro
ISSN: 2070-1721 Cisco Systems
L. Andersson
M. Chen
Huawei
January 2016
Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification
ラベルスイッチドパス（LSP）pingおよびtraceroute応答モードの簡素化
Abstract
概要
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.
マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）のpingおよびTracerouteは、応答モードフィールドを使用して、MPLSエコー応答で使用されるメソッドを通知します。このドキュメントでは、「指定されたパスを介して返信する」返信モードの手順を更新します。この応答モードの値は5です。この更新により、リバースLSPをリターンパスとして使用する必要があることを示す簡単な方法が作成されます。このドキュメントでは、オプションのTLVを追加して、返信モードの値の順序付きリストを運ぶことができます。
This document updates RFC 7110.
このドキュメントはRFC 7110を更新します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7737.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7737で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. "Reply via Specified Path" Reply Mode Update . . . . . . 5
3.2. Reply Mode Order TLV . . . . . . . . . . . . . . . . . . 6
4. Relationships to Other LSP Ping and Traceroute Features . . . 8
4.1. Backwards Compatibility with "Reply via Specified Path"
Reply Mode . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Example 1: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Example 2: Reply Mode Order TLV Usage with Reply Path
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy LSP Ping . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Proxy LSR Sending an MPLS Echo Request . . . . . . . 10
4.3.2. Proxy LSR Sending an MPLS Proxy Ping Reply . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. New Reply Mode Order TLV . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Reply Mode Order TLV Beneficial Scenarios . . . . . 14
A.1. Incorrect Forwarding Scenario . . . . . . . . . . . . . . 14
A.2. Non-Co-Routed Bidirectional LSP Scenario . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping, as described in [RFC4379], allows an initiator Label Switching Router (LSR) to encode instructions (Reply Mode) on how a responder LSR should send the response back to the initiator LSR. [RFC7110] also allows the initiator LSR to encode a TLV (Reply Path TLV) that can instruct the responder LSR to use a specific LSP to send the response back to the initiator LSR. Both approaches are powerful, as they provide the ability for the initiator LSR to control the return path.
[RFC4379]で説明されているマルチプロトコルラベルスイッチング（MPLS）ラベルスイッチドパス（LSP）pingにより、イニシエーターラベルスイッチングルーター（LSR）は、レスポンダーLSRがイニシエーターに応答を送信する方法に関する指示（応答モード）をエンコードできます。 LSR。 [RFC7110]では、イニシエータLSRがTLV（応答パスTLV）をエンコードすることもできます。TLV（応答パスTLV）は、特定のLSPを使用して応答をイニシエータLSRに送り返すように応答側LSRに指示できます。どちらのアプローチも、イニシエーターLSRがリターンパスを制御する機能を提供するため、強力です。
However, it is becoming increasingly difficult for an initiator LSR to select a valid return path to encode in the MPLS LSP echo request packets. If the initiator LSR does not select a valid return path, the MPLS LSP echo reply will not get back to the initiator LSR. This results in a false failure of MPLS LSP Ping and Traceroute operations. In an effort to minimize such false failures, different implementations have chosen different default return path encoding for different LSP types and LSP operations. The problem with implementations having different default return path encoding is that the MPLS echo reply will not work in many cases, and the default value may not be the preferred choice of the operators.
ただし、イニシエーターLSRがMPLS LSPエコー要求パケットにエンコードする有効な戻りパスを選択することがますます難しくなっています。イニシエーターLSRが有効な戻りパスを選択しない場合、MPLS LSPエコー応答はイニシエーターLSRに戻りません。これにより、MPLS LSP pingおよびtraceroute操作の誤った障害が発生します。このような誤った失敗を最小限に抑えるために、さまざまな実装では、さまざまなLSPタイプとLSP操作に対してさまざまなデフォルトのリターンパスエンコーディングを選択しています。デフォルトのリターンパスエンコーディングが異なる実装の問題は、多くの場合MPLSエコー応答が機能せず、デフォルト値が演算子の優先選択ではない可能性があることです。
This document describes the following:
このドキュメントでは、以下について説明します。
o In Section 2, further description of the problems;
o セクション2では、問題の詳細な説明。
o In Section 3, a solution to minimize false failures while accommodating operator preferences;
o セクション3では、オペレーターの好みに対応しながら、誤った失敗を最小限に抑えるソリューション。
o In Section 4, relationships to other LSP Ping and Traceroute features;
o セクション4では、他のLSP pingおよびTraceroute機能との関係。
o In Appendix A, examples of scenarios where the mechanism described in this document provides benefits.
o 付録Aでは、このドキュメントで説明されているメカニズムがメリットをもたらすシナリオの例を示します。
This document updates [RFC7110] by allowing the usage of the "Reply via Specified Path" (value=5) Reply Mode without including the Reply Path TLV. The update creates a simple way to indicate that the reverse LSP should be used as the return path.
このドキュメントは、[RFC7110]を更新し、「指定されたパスを介して返信」（値= 5）返信モードを返信パスTLVを含めずに使用できるようにします。更新により、リバースLSPをリターンパスとして使用する必要があることを示す簡単な方法が作成されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
It is becoming increasingly difficult for implementations to automatically supply a workable return path encoding for all MPLS LSP Ping and Traceroute operations across all LSP types. There are several factors that contribute to this complication.
すべてのLSPタイプにわたるすべてのMPLS LSP PingおよびTraceroute操作に実行可能なリターンパスエンコーディングを自動的に提供することは、実装にとってますます困難になっています。この合併症を引き起こす要因はいくつかあります。
o Some LSPs have a control channel, and some do not. Some LSPs have a reverse LSP, and some do not. Some LSPs have IP reachability in the reverse direction, and some do not.
o 一部のLSPには制御チャネルがあり、一部にはありません。一部のLSPにはリバースLSPがあり、一部にはありません。一部のLSPには逆方向のIP到達可能性がありますが、そうでないものもあります。
o LSRs on some LSPs can have different available return path(s). Available return path(s) can depend on whether the responder LSR is a transit LSR or an egress LSR. In the case of a bidirectional LSP, available return path(s) on transit LSRs can also depend on whether the LSP is completely co-routed, partially co-routed, or associated (i.e., the LSPs in the two directions are not co-routed).
o 一部のLSPのLSRは、異なる使用可能なリターンパスを持つことができます。使用可能なリターンパスは、レスポンダーLSRがトランジットLSRであるか、出力LSRであるかによって異なります。双方向LSPの場合、トランジットLSRで使用可能なリターンパスは、LSPが完全に同じルートであるか、部分的に同じルートであるか、関連付けられているか（つまり、2方向のLSPが同じではない）にも依存します。ルーティング済み）。
o MPLS echo request packets may incorrectly terminate on an unintended target that can have different available return path(s) than the intended target.
o MPLSエコー要求パケットは、意図したターゲットとは異なる使用可能なリターンパスを持つ可能性のある意図しないターゲットで誤って終了する場合があります。
o The MPLS LSP Ping operation is expected to terminate on an egress LSR. However, MPLS LSP Ping operations with specific TTL values and MPLS LSP Traceroute operations can terminate on both transit LSR(s) and the egress LSR.
o MPLS LSP Ping操作は、出力LSRで終了することが期待されています。ただし、特定のTTL値を使用したMPLS LSP PingオペレーションとMPLS LSP Tracerouteオペレーションは、トランジットLSRと出力LSRの両方で終了できます。
Except for the case where the responder LSR does not have an IP route back to the initiator LSR, it is possible to use the "Reply via an IPv4/IPv6 UDP packet" (value=2) Reply Mode value in all cases. However, some operators prefer the control channel and a reverse LSP as the default return path if they are both available, although this is not always the case.
レスポンダーLSRがイニシエーターLSRに戻るIPルートを持っていない場合を除いて、すべての場合に「IPv4 / IPv6 UDPパケットを介した応答」（値= 2）応答モード値を使用できます。ただし、常にそうであるとは限りませんが、一部のオペレーターは、両方が使用可能な場合、デフォルトの戻りパスとして制御チャネルとリバースLSPを好みます。
When specific return path encoding is supplied by users or applications, then there are no issues in choosing the return path encoding. When specific return path encoding is not supplied by users or applications, then implementations use extra logic to compute, and sometimes guess, the default return path encodings. If a responder LSR receives an MPLS echo request containing return path instructions that cannot be accommodated due to unavailability, then the responder LSR often drops such packets. This failure mode results in the initiator LSR not receiving the intended MPLS LSP echo reply packets. The scenario described here is a potentially acceptable result in some failure cases, like a broken LSP, where the MPLS echo request terminated on an unintended target. However, if the initiator LSR does not receive an MPLS echo reply even after the responder LSR receives the MPLS echo request and is able to verify the request, information is still sent back to the user(s); this is considered a false failure.
ユーザーまたはアプリケーションによって特定のリターンパスエンコーディングが提供されている場合、リターンパスエンコーディングの選択に問題はありません。ユーザーまたはアプリケーションによって特定のリターンパスエンコーディングが提供されていない場合、実装は追加のロジックを使用して、デフォルトのリターンパスエンコーディングを計算し、場合によっては推測します。レスポンダーLSRが、使用不可のために対応できない戻りパス命令を含むMPLSエコー要求を受信した場合、レスポンダーLSRはそのようなパケットをドロップすることがよくあります。この障害モードにより、イニシエーターLSRは、意図したMPLS LSPエコー応答パケットを受信しなくなります。ここで説明するシナリオは、LSPの破損など、MPLSエコー要求が意図しないターゲットで終了した場合など、一部の障害の場合に許容できる結果です。ただし、レスポンダーLSRがMPLSエコー要求を受信し、要求を確認できた後でも、イニシエーターLSRがMPLSエコー応答を受信しない場合でも、情報はユーザーに返送されます。これは誤った失敗と見なされます。
Many operators prefer particular return path(s) over other return path(s) for specific LSP types. To accommodate operator-preferred paths, implementations may default to operator-preferred return paths for particular operations or allow a default return path to be configured. It would not be considered beneficial to use a preferred return path for an intended target LSR if there is previous knowledge at the initiator LSR that the return path is not available. Using an unavailable preferred return path would undesirably result in the initiator LSR not receiving the MPLS echo return packets. It would be considered beneficial, for given operations, if the sender of the MPLS echo request would be able to determine return path availability before the operation is initiated.
多くのオペレーターは、特定のLSPタイプに対して、他のリターンパスよりも特定のリターンパスを好みます。オペレーターが優先するパスに対応するために、実装は特定の操作に対してオペレーターが優先する戻りパスをデフォルトにするか、デフォルトの戻りパスを構成することができます。イニシエーターLSRでリターンパスが利用できないという事前の知識がある場合、目的のターゲットLSRに優先リターンパスを使用することは有益とは見なされません。使用できない優先リターンパスを使用すると、イニシエーターLSRがMPLSエコーリターンパケットを受信できなくなります。 MPLSエコー要求の送信者が、操作が開始される前にリターンパスの可用性を判断できる場合、特定の操作にとって有益であると見なされます。
This document (1) updates the procedures for the "Reply via Specified Path" Reply Mode to easily indicate the reverse LSP and (2) adds one optional TLV to describe an ordered list of Reply Modes. Based on operational needs, the TLV can list multiple Reply Mode values in a preferred order to allow the responder LSR to use the first available Reply Mode from the list. This eliminates the need for the initiator LSR to compute, or sometimes guess, the default return path encoding. This new mode of operation would result in simplified implementations across the various vendors and improve both usability and operational needs.
このドキュメントでは、（1）リバースLSPを簡単に示すために、「指定されたパスを介した返信」返信モードの手順を更新し、（2）返信モードの順序付きリストを説明するオプションのTLVを1つ追加します。運用上のニーズに基づいて、TLVは複数の応答モード値を優先順にリストして、レスポンダLSRがリストから最初に使用可能な応答モードを使用できるようにすることができます。これにより、イニシエーターLSRがデフォルトのリターンパスエンコーディングを計算する、または推測する必要がなくなります。この新しい操作モードにより、さまざまなベンダーでの実装が簡素化され、使いやすさと操作上のニーズの両方が改善されます。
This document updates the procedures for the "Reply via Specified Path" Reply Mode to easily indicate the reverse LSP. This document also adds an optional TLV that can carry an ordered list of Reply Modes.
このドキュメントでは、「指定されたパスを介して返信する」返信モードの手順を更新して、リバースLSPを簡単に示します。このドキュメントでは、応答モードの順序付きリストを伝送できるオプションのTLVも追加されています。
Some LSP types are capable of having a related LSP in the reverse direction, through signaling or other association mechanisms. Examples of such LSP types are bidirectional Resource Reservation Protocol-Traffic Engineering (RSVP-TE) LSPs [RFC3473] and MPLS Transport Profile (MPLS-TP) LSPs [RFC5960]. This document uses the term "reverse LSP" to refer to the LSP in the reverse direction of such LSP types. Note that this document restricts the scope of "reverse LSP" applicability to those reverse LSPs that are capable and allowed to carry the IP encapsulated MPLS echo reply.
一部のLSPタイプは、シグナリングまたはその他のアソシエーションメカニズムを介して、関連するLSPを逆方向に持つことができます。このようなLSPタイプの例は、双方向のリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）LSP [RFC3473]およびMPLSトランスポートプロファイル（MPLS-TP）LSP [RFC5960]です。このドキュメントでは、「逆LSP」という用語を使用して、そのようなLSPタイプの逆方向のLSPを指します。このドキュメントでは、「リバースLSP」の適用範囲を、IPカプセル化MPLSエコー応答の伝送が可能で許可されているリバースLSPに限定していることに注意してください。
[RFC7110] has defined the Reply Mode "Reply via Specified Path", which allows the initiator LSR to instruct the responder LSR to send the MPLS echo reply message on the reverse LSP. However, the instruction also requires the initiator LSR to include the Reply Path TLV with the B bit (Bidirectional bit) set in the Flags field. Additionally, [RFC7110] specifies that if the "Reply via Specified Path" Reply Mode is used the Reply Path TLV MUST be present.
[RFC7110]は、応答モード「Reply via Specified Path」を定義しました。これにより、イニシエーターLSRは、応答側LSRにMPLSエコー応答メッセージをリバースLSPで送信するように指示できます。ただし、この命令では、フラグフィールドにBビット（双方向ビット）が設定された応答パスTLVをイニシエーターLSRに含める必要もあります。さらに、[RFC7110]は、「指定されたパスを介した返信」返信モードが使用される場合、返信パスTLVが存在しなければならないことを指定しています。
This document updates the procedures for the "Reply via Specified Path" Reply Mode as follows:
このドキュメントでは、「指定されたパスを介して返信する」返信モードの手順を次のように更新します。
o The "Reply via Specified Path" Reply Mode MAY be used without including a Reply Path TLV.
o 「指定されたパスを介した返信」返信モードは、返信パスTLVを含めずに使用できます。
o The usage of the "Reply via Specified Path" Reply Mode without the inclusion of a Reply Path TLV implies the reverse LSP. In other words, the usage of the "Reply via Specified Path" Reply Mode without the inclusion of a Reply Path TLV has the same semantics as the usage of the "Reply via Specified Path" Reply Mode with the inclusion of a Reply Path TLV with the B bit set in the Flags field.
o 応答パスTLVを含まない「指定されたパスを介した応答」応答モードの使用は、逆LSPを意味します。言い換えると、応答パスTLVを含めないで「指定されたパスを介して返信する」返信モードを使用すると、応答パスTLVを含めて「指定されたパスを介して返信する」返信モードを使用する場合と同じセマンティクスになります。 Flagsフィールドで設定されたBビット。
This document updates the first sentence of Section 5.1 of [RFC7110] as follows:
このドキュメントは、[RFC7110]のセクション5.1の最初の文を次のように更新します。
o When sending an echo request, in addition to the rules and procedures defined in Section 4.3 of [RFC4379], the Reply Mode of the echo request MUST be set to "Reply via Specified Path", and a Reply Path TLV SHOULD be carried in the echo request message correspondingly; if the Reply Path TLV is not carried in the message, then it indicates the reverse LSP as the reply path.
o エコーリクエストを送信するときは、[RFC4379]のセクション4.3で定義されたルールと手順に加えて、エコーリクエストの返信モードを「指定されたパスを介して返信」に設定する必要があり、返信パスTLVを対応して要求メッセージをエコーします。応答パスTLVがメッセージに含まれていない場合、応答パスとしてリバースLSPを示します。
Note that the reverse LSP is in relation to the last Forwarding Equivalence Class (FEC) specified in the Target FEC Stack TLV.
リバースLSPは、ターゲットFECスタックTLVで指定された最後の転送等価クラス（FEC）に関連していることに注意してください。
This document also introduces a new optional TLV to describe a list of Reply Mode values. The new TLV will contain one or more Reply Mode values in preferred order. The first Reply Mode value is the most preferred, and the last Reply Mode value is the least preferred. The following rules apply when using the Reply Mode Order TLV:
このドキュメントでは、応答モードの値のリストを説明する新しいオプションのTLVも紹介しています。新しいTLVには、1つ以上の応答モード値が優先順に含まれます。最初の応答モードの値が最も優先され、最後の応答モードの値が最も優先されません。返信モードの順序TLVを使用する場合、次のルールが適用されます。
1. The Reply Mode Order TLV MUST NOT be included in any MPLS echo reply. If the initiator LSR receives an MPLS echo reply with the Reply Mode Order TLV, the initiator LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply Mode field of the received MPLS echo reply. It may be beneficial for implementations to provide counters and/or logs, with appropriate log dampening, to record this error case.
1.応答モードの順序TLVをMPLSエコー応答に含めることはできません。イニシエーターLSRが応答モード順序TLVでMPLSエコー応答を受信する場合、イニシエーターLSRは応答モード順序TLV全体を無視しなければならず、受信したMPLSエコー応答の応答モードフィールドからの値のみを使用しなければなりません（MUST）。このエラーケースを記録するために、適切なログダンプを備えたカウンターやログを提供することは、実装にとって有益である場合があります。
2. The Reply Mode Order TLV MAY be included in MPLS echo requests.
2. 応答モードの順序TLVは、MPLSエコー要求に含めることができます。
3. The Reply Mode field of an MPLS echo request MUST be set to a valid value even when supplying the Reply Mode Order TLV. The initiator LSR SHOULD set the Reply Mode field of an MPLS echo request to a value that corresponds to a return path that is most likely to be available, in case the responder LSR does not understand the Reply Mode Order TLV.
3. MPLSエコー要求のReply Modeフィールドは、Reply Mode Order TLVを提供する場合でも、有効な値に設定する必要があります。イニシエーターLSRは、レスポンダーLSRが応答モードの順序TLVを理解できない場合に備えて、MPLSエコー要求の応答モードフィールドを、利用可能性が最も高いリターンパスに対応する値に設定する必要があります（SHOULD）。
4. If a responder LSR understands the Reply Mode Order TLV but the TLV is not valid (due to the conditions described in items 6, 7, 8, and 9 below), then the responder LSR MUST ignore the whole Reply Mode Order TLV and MUST only use the value from the Reply Mode field of the received MPLS echo request. It may be beneficial for implementations to provide counters and/or logs, with appropriate log dampening, to record this error case.
4. レスポンダーLSRが応答モードオーダーTLVを理解しているが、TLVが有効でない場合（以下の項目6、7、8、9で説明されている条件により）、レスポンダーLSRは、応答モードオーダーTLV全体を無視しなければならず（MUST）受信したMPLSエコー要求の[応答モード]フィールドの値を使用します。このエラーケースを記録するために、適切なログダンプを備えたカウンターやログを提供することは、実装にとって有益である場合があります。
5. If a responder LSR understands the Reply Mode Order TLV and the TLV is valid, then the responder LSR MUST consider the Reply Mode values specified in the TLV and MUST NOT use the value specified in the Reply Mode field of the received MPLS echo request. In other words, a valid Reply Mode Order TLV overrides the value specified in the Reply Mode field of the received MPLS echo request.
5. 応答側LSRが応答モードの順序TLVを理解し、TLVが有効である場合、応答側LSRはTLVで指定された応答モード値を考慮しなければならず、受信したMPLSエコー要求の応答モードフィールドで指定された値を使用してはなりません（MUST NOT）。つまり、有効な応答モード順序TLVは、受信したMPLSエコー要求の[応答モード]フィールドで指定された値を上書きします。
6. The Reply Mode Order TLV MUST contain at least one Reply Mode value.
6. 応答モード順序TLVには、少なくとも1つの応答モード値が含まれている必要があります。
7. A Reply Mode value, except for Reply Mode value 5 (Reply via Specified Path), MUST NOT be repeated (i.e., MUST NOT appear multiple times) in the Reply Mode Order TLV.
7. 応答モード値5（指定されたパスを介した応答）を除いて、応答モード値は、応答モード順序TLVで繰り返されてはなりません（つまり、複数回出現してはなりません）。
8. Reply Mode value 5 (Reply via Specified Path) MAY be included more than once in the Reply Mode Order TLV. However, in such a case, a Reply Path TLV MUST be included for all instances of Reply Mode value 5 that are included in the Reply Mode Order TLV. In other words, three instances of Reply Mode value 5 in the Reply Mode Order TLV will each require a Reply Path TLV.
8. 応答モード値5（指定されたパスを介した応答）は、応答モード順序TLVに複数回含めることができます。ただし、そのような場合は、返信モード順序TLVに含まれている返信モード値5のすべてのインスタンスに返信パスTLVを含める必要があります。つまり、返信モード順序TLVの返信モード値5の3つのインスタンスには、それぞれ返信パスTLVが必要です。
9. The Reply Mode value 1 (Do not reply) MUST NOT be used in the Reply Mode Order TLV.
9. 返信モード値1（返信しない）は、返信モードオーダーTLVで使用してはなりません（MUST NOT）。
The responder LSR SHOULD select the first available return path in this TLV. The Reply Mode value corresponding to the selected return path MUST be set in the Reply Mode field of the MPLS echo reply to communicate back to the initiator LSR which return path was chosen.
レスポンダLSRは、このTLVで利用可能な最初のリターンパスを選択する必要があります（SHOULD）。選択されたリターンパスに対応するリプライモード値をMPLSエコー応答のリプライモードフィールドに設定して、どのリターンパスが選択されたイニシエータLSRに通信する必要があります。
The format of the TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Mode Order TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Reply Mode 1 | Reply Mode 2 | Reply Mode 3 | Reply Mode 4 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reply Mode Order TLV
図1：応答モードの順序TLV
This is a variable-length optional TLV. The Reply Mode Order TLV Type is 32770.
これは可変長のオプションのTLVです。 Reply Mode Order TLV Typeは32770です。
The Length field is 2 octets in length. It defines the length, in octets, of the list of Reply Mode values.
長さフィールドの長さは2オクテットです。応答モード値のリストの長さをオクテットで定義します。
Each Reply Mode field is 1 octet, and there is no padding.
各返信モードフィールドは1オクテットで、パディングはありません。
[RFC7110] introduces the "Reply via Specified Path" (value=5) Reply Mode. [RFC7110] also specifies that if this Reply Mode is used the Reply Path TLV MUST be included. This document relaxes the semantics and specifies that this Reply Mode MAY be used without the Reply Path TLV. This MAY be done to indicate that the reverse LSP SHALL be used as the return path.
[RFC7110]は、「指定されたパスを介した返信」（値= 5）返信モードを導入します。 [RFC7110]は、この返信モードを使用する場合、返信パスTLVを含める必要があることも指定しています。このドキュメントは、セマンティクスを緩和し、この応答モードが応答パスTLVなしで使用される場合があることを指定します。これは、リバースLSPがリターンパスとして使用される必要があることを示すために実行される場合があります。
If an initiator LSR that sent an MPLS echo request message with the "Reply via Specified Path" Reply Mode but without including the Reply Path TLV receives back an MPLS echo reply message with a return code of "Malformed echo request received", then the initiator LSR SHOULD assume that the responder LSR does not support the mechanism defined in this document.
「指定されたパスを介した返信」返信モードでMPLSエコー要求メッセージを送信したが、返信パスTLVを含まないイニシエーターLSRが、「不正なエコー要求を受信しました」という戻りコードを含むMPLSエコー応答メッセージを受信した場合、イニシエーターLSRは、レスポンダLSRがこのドキュメントで定義されているメカニズムをサポートしていないことを想定する必要があります（SHOULD）。
A Reply Path TLV [RFC7110] is defined to identify a single return path. When the initiator LSR wants to use the Reply Mode Order TLV to specify multiple return paths, then the initiator LSR SHOULD include multiple "Reply via Specified Path" (value=5) Reply Mode values and multiple corresponding Reply Path TLV objects (one Reply Path TLV corresponding to a "Reply via Specified Path" Reply Mode and one Reply Path TLV identifying a return path).
返信パスTLV [RFC7110]は、単一の返信パスを識別するために定義されています。イニシエーターLSRが応答モード順序TLVを使用して複数の戻りパスを指定する場合、イニシエーターLSRは複数の「指定されたパスを介した応答」（値= 5）応答モード値と複数の対応する応答パスTLVオブジェクト（1つの応答パス）を含める必要があります（SHOULD）。 「指定されたパス経由の返信」返信モードに対応するTLV、および返信パスを識別する1つの返信パスTLV）。
As described in Section 3.1, it is valid to use the "Reply via Specified Path" Reply Mode without inclusion in a Reply Path TLV. For the Reply Mode Order TLV, it is also valid to include a "Reply via Specified Path" Reply Mode value without a corresponding Reply Path TLV; this implies that the reverse LSP is the preferred return path. When multiple consecutive "Reply via Specified Path" Reply Mode values are included but fewer corresponding Reply Path TLV objects exist, the responder LSR SHOULD think that the former "Reply via Specified Path" Reply Mode values have corresponding Reply Path TLVs. The latter "Reply via Specified Path" Reply Mode values have no corresponding Reply Path TLVs. For example, if the Reply Mode Order TLV carries Reply Modes {5, 5, 5} and only two Reply Path TLVs carry FEC X and FEC Y, respectively, then the reply path order is as follows:
セクション3.1で説明されているように、応答パスTLVに含まれない「指定されたパスを介した応答」応答モードを使用することは有効です。応答モード順序TLVの場合、対応する応答パスTLVなしで「指定されたパス経由の応答」応答モード値を含めることも有効です。これは、リバースLSPが優先リターンパスであることを意味します。複数の連続する「指定されたパスを介した返信」返信モード値が含まれているが、対応する返信パスTLVオブジェクトが少ない場合、レスポンダーLSRは、以前の「指定されたパスを介した返信」返信モード値に対応する返信パスTLVがあると考えるべきです。後者の「指定されたパスを介した返信」返信モード値には、対応する返信パスTLVがありません。たとえば、応答モードの順序TLVが応答モード{5、5、5}を伝送し、2つの応答パスTLVのみがそれぞれFEC XとFEC Yを伝送する場合、応答パスの順序は次のようになります。
1. Reply via Specified Path (FEC X)
1. 指定されたパス経由で返信（FEC X）
2. Reply via Specified Path (FEC Y)
2. 指定されたパス経由で返信（FEC Y）
3. Reply via Specified Path (reverse LSP)
3. 指定されたパス経由で返信（リバースLSP）
If the initiator LSR was interested in encoding the following return paths:
イニシエータLSRが次のリターンパスのエンコードに関心がある場合：
1. Reply via application level control channel
1. アプリケーションレベルの制御チャネルを介した返信
2. FEC X
2. FEC 10
3. FEC Y
3. FEC Y
4. Reply via an IPv4/IPv6 UDP packet
4. IPv4 / IPv6 UDPパケット経由で返信
Then the MPLS echo request message is to carry:
次に、MPLSエコー要求メッセージは次のものを伝送します。
o The Reply Mode Order TLV carrying Reply Modes {4, 5, 5, 2}
o 返信モードの順序TLVが返信モードを運ぶ{4、5、5、2}
o One Reply Path TLV carrying FEC X
o FEC Xを伝送する1つの応答パスTLV
o One Reply Path TLV carrying FEC Y The encoding specified by the Reply Mode Order TLV and the Reply Path TLV in the MPLS echo request message will cause the responder LSR to prefer "Reply via application level control channel (4)", followed by FEC X, FEC Y, and then "Reply via an IPv4/IPv6 UDP packet (2)".
o FECを伝送する1つの応答パスTLV Y MPLSエコー要求メッセージの応答モード順序TLVと応答パスTLVで指定されたエンコードにより、レスポンダーLSRは「アプリケーションレベルの制御チャネル（4）を介した応答」を優先し、その後にFECが続きます。 X、FEC Y、次に「IPv4 / IPv6 UDPパケット経由で返信（2）」。
If the initiator LSR was interested in encoding the following return paths:
イニシエータLSRが次のリターンパスのエンコードに関心がある場合：
1. Reverse LSP
1. LSPを反転
2. Reply via an IPv4/IPv6 UDP packet
2. IPv4 / IPv6 UDPパケット経由で返信
3. FEC X
3. FEC 10
4. FEC Y
4. FEC Y
Then the MPLS echo request message is to carry:
次に、MPLSエコー要求メッセージは次のものを伝送します。
o The Reply Mode Order TLV carrying Reply Modes {5, 2, 5, 5}
o 返信モードのTLV返信モード{5、2、5、5、5}
o One Reply Path TLV with the B bit set
o Bビットが設定された1つの応答パスTLV
o One Reply Path TLV carrying FEC X
o FEC Xを伝送する1つの応答パスTLV
o One Reply Path TLV carrying FEC Y
o FEC Yを伝送する1つの応答パスTLV
The encoding specified by the Reply Mode Order TLV and the Reply Path TLV in the MPLS echo request message will cause the responder LSR to prefer the reverse LSP, followed by "Reply via an IPv4/IPv6 UDP packet (2)", FEC X, and then FEC Y.
MPLSエコー要求メッセージの応答モード順序TLVおよび応答パスTLVで指定されたエンコードにより、レスポンダーLSRはリバースLSPを優先し、「IPv4 / IPv6 UDPパケット（2）を介した応答」、FEC X、そしてFECY。
The mechanism defined in this document will work with Proxy LSP Ping as defined by [RFC7555]. The MPLS proxy ping request message can carry a Reply Mode value in the header and one or more Reply Mode values in the Reply Mode Order TLV. It is RECOMMENDED that Reply Mode 2 (Reply via an IPv4/IPv6 UDP packet) be used in the Reply Mode field of the MPLS proxy ping request message.
このドキュメントで定義されているメカニズムは、[RFC7555]で定義されているプロキシLSP Pingで動作します。 MPLSプロキシping要求メッセージは、ヘッダーの返信モード値と、返信モード順序TLVの1つ以上の返信モード値を運ぶことができます。 MPLSプロキシping要求メッセージの[応答モード]フィールドで、応答モード2（IPv4 / IPv6 UDPパケット経由の応答）を使用することをお勧めします。
If the proxy LSR is sending an MPLS echo request, then the proxy LSR MUST copy the following elements from the MPLS proxy ping request message to the MPLS echo request message: o The Reply Mode field.
プロキシLSRがMPLSエコー要求を送信している場合、プロキシLSRは、次の要素をMPLSプロキシping要求メッセージからMPLSエコー要求メッセージにコピーする必要があります。o応答モードフィールド。
o The Reply Mode Order TLV.
o Reply Mode Order TLV。
o The Reply Path TLV(s). If there is more than one Reply Path TLV, then the ordering of the TLVs MUST be preserved when copying.
o 応答パスTLV。複数の応答パスTLVがある場合、コピーするときにTLVの順序を維持する必要があります。
If the proxy LSR is sending an MPLS proxy ping reply, then it is RECOMMENDED that the Reply Mode Order TLV be ignored and the Reply Mode field in the MPLS proxy ping request message be used.
プロキシLSRがMPLSプロキシping応答を送信している場合は、応答モードの順序TLVを無視し、MPLSプロキシping要求メッセージの[応答モード]フィールドを使用することをお勧めします。
The security considerations specified in [RFC4379] and [RFC7110] also apply for this document.
[RFC4379]と[RFC7110]で指定されたセキュリティの考慮事項は、このドキュメントにも適用されます。
In addition, this document introduces the Reply Mode Order TLV. It provides a new way for an unauthorized source to gather more network information, especially information regarding the potential return path(s) of an LSP. To protect against unauthorized sources using MPLS echo request messages with the Reply Mode Order TLV to obtain network information, as also specified in [RFC4379], it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message.
さらに、このドキュメントでは、応答モードの順序TLVを紹介しています。これは、無許可の送信元がネットワーク情報、特にLSPの潜在的なリターンパスに関する情報を収集するための新しい方法を提供します。 [RFC4379]で指定されているように、ネットワーク情報を取得するために返信モードの順序TLVでMPLSエコー要求メッセージを使用して不正な送信元から保護するために、アクセスに対してMPLSエコー要求メッセージの送信元アドレスをチェックする手段を実装が提供することが推奨されますメッセージを受け入れる前にリストします。
Another potential security issue is that the MPLS echo request and reply messages are not encrypted; the contents of the MPLS echo request and reply messages may therefore be potentially exposed. Although the exposure is within the MPLS domain, if such exposure is a concern, some encryption mechanisms [MPLS-OPP-ENCR] may be employed.
別の潜在的なセキュリティ問題は、MPLSエコー要求と応答メッセージが暗号化されていないことです。したがって、MPLSエコー要求および応答メッセージの内容が公開される可能性があります。露出はMPLSドメイン内にありますが、そのような露出が懸念される場合は、いくつかの暗号化メカニズム[MPLS-OPP-ENCR]が使用される場合があります。
Section 2 described problems that increase complexity with respect to operations and implementations. In order to simplify operations and to allow LSP Ping and Traceroute to function efficiently whilst preserving code simplicity, it is RECOMMENDED that implementations allow devices to have configuration options to set operator-preferred Reply Modes. For example:
セクション2では、運用と実装に関して複雑さを増す問題について説明しました。操作を簡素化し、LSP PingとTracerouteを効率的に機能させながら、コードの単純さを維持するために、実装では、デバイスがオペレーター優先の応答モードを設定する構成オプションを持つことができるようにすることをお勧めします。例えば：
o For those operators who are more interested in MPLS echo reply packets reaching the initiator LSR:
o イニシエーターLSRに到達するMPLSエコー応答パケットに関心があるオペレーターの場合：
1. Reply via an IPv4/IPv6 UDP packet (2) 2. Reply via application level control channel (4)
1. IPv4 / IPv6 UDPパケット経由で返信（2）2.アプリケーションレベルの制御チャネル経由で返信（4）
3. Reply via Specified Path (5)
3. 指定されたパス経由で返信（5）
o For those operators who are more interested in MPLS echo reply packets testing the paths related to the forward LSP:
o フォワードLSPに関連するパスをテストするMPLSエコー応答パケットに関心のあるこれらのオペレーターの場合：
1. Reply via Specified Path (5)
1. 指定されたパス経由で返信（5）
2. Reply via application level control channel (4)
2. アプリケーションレベルの制御チャネル経由で返信（4）
3. Reply via an IPv4/IPv6 UDP packet (2)
3. IPv4 / IPv6 UDPパケット経由で返信（2）
IANA has assigned a new TLV type value from the "TLVs" sub-registry within the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, for the Reply Mode Order TLV.
IANAは、「Multiprotocol Label Switching Architecture（MPLS）Label Switched Paths（LSPs）Ping Parameters」レジストリ内の「TLVs」サブレジストリからの新しいTLVタイプ値を、応答モード順序TLVに割り当てました。
The new TLV Type value has been assigned from the range 32768-49161, as specified in Sections 3 and 7.2 of [RFC4379]; this range is for optional TLVs that can be silently dropped if not recognized.
[RFC4379]のセクション3および7.2で指定されているように、新しいTLVタイプ値は32768〜49161の範囲から割り当てられています。この範囲は、認識されない場合にサイレントにドロップできるオプションのTLV用です。
Type Meaning Reference
----- ------- ---------
32770 Reply Mode Order TLV RFC 7737
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, <http://www.rfc-editor.org/info/rfc4379>.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、DOI 10.17487 / RFC4379、2006年2月、<http://www.rfc-editor.org / info / rfc4379>。
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <http://www.rfc-editor.org/info/rfc7110>.
[RFC7110] Chen、M.、Cao、W.、Ning、S.、Jounay、F。、およびS. Delord、「Return Path Specified Label Switched Path（LSP）Ping」、RFC 7110、DOI 10.17487 / RFC7110、January 2014、<http://www.rfc-editor.org/info/rfc7110>。
[MPLS-OPP-ENCR] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-00, July 2015.
[MPLS-OPP-ENCR]ファレル、A。およびS.ファレル、「MPLSネットワークにおける日和見セキュリティ」、作業中、draft-ietf-mpls-opportunistic-encrypt-00、2015年7月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, DOI 10.17487/RFC5960, August 2010, <http://www.rfc-editor.org/info/rfc5960>.
[RFC5960] Frost、D。、編、Bryant、S。、編、およびM. Bocci、編、「MPLSトランスポートプロファイルデータプレーンアーキテクチャ」、RFC 5960、DOI 10.17487 / RFC5960、2010年8月、<http： //www.rfc-editor.org/info/rfc5960>。
[RFC7555] Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo Request", RFC 7555, DOI 10.17487/RFC7555, June 2015, <http://www.rfc-editor.org/info/rfc7555>.
[RFC7555] Swallow、G.、Lim、V。、およびS. Aldrin、「Proxy MPLS Echo Request」、RFC 7555、DOI 10.17487 / RFC7555、2015年6月、<http://www.rfc-editor.org/info / rfc7555>。
This section lists examples of how the Reply Mode Order TLV can be beneficial.
このセクションでは、応答モードの順序TLVがどのように役立つかを示す例を示します。
As shown in Figure 2, a network has an LSP with the forwarding path A-B-C-D-E. The LSP has a control channel.
図2に示すように、ネットワークには転送パスA-B-C-D-Eを持つLSPがあります。 LSPには制御チャネルがあります。
A------B------C------D------E
|
|
F
Forward Path: A-B-C-D-E
フォワードパス：A-B-C-D-E
Figure 2: Incorrect Forwarding
図2：不適切な転送
If D is incorrectly label switching to F (instead of E), then LSP Traceroute with "Reply via application level control channel (4)" will result in the following:
Dのラベルスイッチングが（Eではなく）Fに誤っている場合、「アプリケーションレベルの制御チャネル（4）を介した応答」を含むLSP Tracerouteの結果は次のようになります。
Success (Reply from B) Success (Reply from C) Success (Reply from D) Timeout... Complete
成功（Bからの返信）成功（Cからの返信）成功（Dからの返信）タイムアウト...完了
This is because F does not have a control channel on which to send the MPLS echo reply message. With the extensions described in this document, the same procedures can be performed with the Reply Mode Order TLV carrying {4, 2}. When LSP Traceroute is issued, then the following output may be displayed without any unnecessary timeout:
これは、FにMPLSエコー応答メッセージを送信するための制御チャネルがないためです。このドキュメントで説明する拡張機能を使用すると、{4、2}を伝送する応答モード順序TLVで同じ手順を実行できます。 LSP Tracerouteが発行されると、不要なタイムアウトなしで次の出力が表示される場合があります。
Success (Reply from B, Reply Mode: 4) Success (Reply from C, Reply Mode: 4) Success (Reply from D, Reply Mode: 4) FEC Mismatch (Reply from F, Reply Mode: 2) Complete
成功（Bからの返信、返信モード：4）成功（Cからの返信、返信モード：4）成功（Dからの返信、返信モード：4）FEC不一致（Fからの返信、返信モード：2）完了
The result provides more diagnostic information to the initiator LSR, and without any delay (i.e., timeout from one or more downstream LSRs).
その結果、イニシエーターLSRにより多くの診断情報が提供され、遅延（1つ以上のダウンストリームLSRからのタイムアウト）は発生しません。
As shown in Figure 3, a network has a bidirectional LSP where the forward LSP and the reverse LSP are not fully co-routed.
図3に示すように、ネットワークには双方向LSPがあり、フォワードLSPとリバースLSPが完全に同じルートになっているわけではありません。
+----C------D----+
/ \
A------B G------H
\ /
+----E------F----+
Forward Path: A-B-C-D-G-H (upper path) Reverse Path: H-G-F-E-B-A (lower path)
フォワードパス：A-B-C-D-G-H（上部パス）リバースパス：H-G-F-E-B-A（下部パス）
Figure 3: Non-Co-Routed Bidirectional LSP
図3：コルートされていない双方向LSP
Some operators may prefer and configure "Reply via Specified Path" as the default Reply Mode but without including the Reply Path TLV, to indicate that the reverse LSP is used as the return path when MPLS echo request messages are sent on bidirectional LSPs. Without the extensions described in this document, the following behaviors will be seen:
MPLSエコー要求メッセージが双方向LSPで送信されるときに、リバースLSPがリターンパスとして使用されることを示すために、一部のオペレータは、デフォルトの応答モードとして「指定されたパスを介した応答」を好み、設定しますが、応答パスTLVを含みません。このドキュメントで説明されている拡張機能がないと、次の動作が見られます。
o When LSP Ping is issued from A, the reply will come back on the reverse LSP from H.
o AからLSP Pingが発行されると、Hからの逆LSPで応答が返されます。
o When LSP Traceroute is issued from A, the replies will come back on the reverse LSP from B, G, and H but will encounter a timeout from C and D, as there are no reverse LSPs on those nodes.
o AからLSP Tracerouteが発行されると、B、G、およびHからの逆LSPで応答が返されますが、CおよびDからのタイムアウトが発生します。これらのノードには逆LSPがないためです。
o When LSP Ping with a specific TTL value is issued from A, whether a timeout will be encountered depends on the value of the TTL used (i.e., whether or not the MPLS echo request terminates on a node that has a reverse LSP).
o 特定のTTL値を持つLSP PingがAから発行される場合、タイムアウトが発生するかどうかは、使用されるTTLの値（つまり、MPLSエコー要求がリバースLSPを持つノードで終了するかどうか）に依存します。
One can argue that the initiator LSR can automatically generate the same MPLS echo request with a different Reply Mode value to those nodes that time out. However, such a mechanism will result in an extended time for the entire operation to complete (i.e., multiple seconds to multiple minutes). This is undesirable, and perhaps unacceptable if the "user" is an application.
イニシエーターLSRは、タイムアウトしたノードに対して、異なる応答モード値を使用して同じMPLSエコー要求を自動的に生成できると主張できます。ただし、このようなメカニズムでは、操作全体が完了するまでの時間が長くなります（つまり、数秒から数分）。これは望ましくなく、「ユーザー」がアプリケーションの場合はおそらく受け入れられません。
With the extensions described in this document, the same procedures can be performed with the Reply Mode Order TLV carrying {5, 2}. When LSP Traceroute is issued, then the following output may be displayed without any unnecessary timeout:
このドキュメントで説明されている拡張機能を使用すると、{5、2}を伝送する応答モード順序TLVで同じ手順を実行できます。 LSP Tracerouteが発行されると、不要なタイムアウトなしで次の出力が表示される場合があります。
Success (Reply Mode: 5) Success (Reply Mode: 2) Success (Reply Mode: 2) Success (Reply Mode: 5) Success (Reply Mode: 5) Complete
成功（返信モード：5）成功（返信モード：2）成功（返信モード：2）成功（返信モード：5）成功（返信モード：5）完了
Acknowledgements
謝辞
The authors especially thank Tom Taylor, who passed away close to the time of publication of this RFC. Tom did a careful review of the document and provided useful comments.
著者は特に、このRFCの発行時期近くに亡くなったTom Taylorに感謝します。トムはドキュメントを注意深くレビューし、役立つコメントを提供しました。
The authors would also like to thank Santiago Alvarez and Faisal Iqbal for discussions that motivated the creation of this document; Sam Aldrin, Curtis Villamizar, Ross Callon, Jeffrey Zhang, Jeremy Whittaker, Mustapha Alissaoui, Qin Wu, Jie Dong, and Adrian Farrel for providing valuable comments that influenced the content of the document; and Dan Frost, Victor Kuarsingh, and Deborah Brungard for reviewing the document and providing useful comments.
また、このドキュメントの作成に動機を与えた議論について、サンティアゴアルバレスとファイサルイクバルに感謝します。ドキュメントの内容に影響を与えた貴重なコメントを提供してくれたSam Aldrin、Curtis Villamizar、Ross Callon、Jeffrey Zhang、Jeremy Whittaker、Mustapha Alissaoui、Qin Wu、Jie Dong、Adrian Farrel。文書をレビューし、有用なコメントを提供してくれたDan Frost、Victor Kuarsingh、Deborah Brungard。
Contributors
貢献者
Shaleen Saxena Brocade
シャリーンサクセナブロケード
Email: ssaxena@brocade.com
Authors' Addresses
著者のアドレス
Nobo Akiya Big Switch Networks
Nobo Akiya Big Switch Networks
Email: nobo.akiya.dev@gmail.com
George Swallow Cisco Systems
ジョージスワローシスコシステムズ
Email: swallow@cisco.com
Carlos Pignataro Cisco Systems
Carlos Pignataro Cisco Systems
Email: cpignata@cisco.com
Loa Andersson Huawei
ロア・アンダーソン・ファーウェイ
Email: loa@mail01.huawei.com
Mach(Guoyi) Chen Huawei
マッハ（GUお一）陳湖Aは
Email: mach.chen@huawei.com