[要約] RFC 8918は、IS-ISプロトコルにおける無効なTLV（Type-Length-Value）の取り扱いに関するものです。この文書の目的は、無効なTLVが検出された場合の振る舞いを標準化し、ネットワークの安定性と互換性を向上させることにあります。主に、ルーティングプロトコルの実装者やネットワーク運用者が利用する場面が想定されます。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 8918 P. Wells
Updates: 5305, 6232 Cisco Systems
Category: Standards Track T. Li
ISSN: 2070-1721 Arista Networks
T. Przygienda
S. Hegde
Juniper Networks, Inc.
September 2020
Invalid TLV Handling in IS-IS
IS-ISでの無効なTLV処理
Abstract
概要
The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received.
中間システムへの中間システム（IS - IS）プロトコルへの伸張性への鍵は、サポートされていないおよび/または無効なタイプ長値（TLV）タプルの処理であった。既存の仕様に明示的なステートメントがありますが、展開エクスペリエンスは、特定のプロトコルデータユニット（PDU）で許可されていないTLVが受信されたときに動作に矛盾があることを示しました。
This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.
この文書ではそのような場合について説明し、相互運用性が最大化されるようにするために正しい動作を明示的にします。
This document updates RFCs 5305 and 6232.
この文書はRFCS 5305と6232を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8918.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/frfc8918で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. TLV Codepoints Registry
3. TLV Acceptance in PDUs
3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP
Purges
3.2. Special Handling of Disallowed TLVs in Received LSP Purges
3.3. Applicability to Sub-TLVs
3.4. Correction to POI "TLV Codepoints Registry" Entry
4. TLV Validation and LSP Acceptance
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The Intermediate System to Intermediate System (IS-IS) protocol [ISO10589] utilizes Type-Length-Value (TLV) encoding for all content in the body of Protocol Data Units (PDUs). New extensions to the protocol are supported by defining new TLVs. In order to allow protocol extensions to be deployed in a backwards compatible way, an implementation is required to ignore TLVs that it does not understand. This behavior is also applied to sub-TLVs [RFC5305], which are contained within TLVs.
中間システムへの中間システム（IS - IS）プロトコル[ISO10589]は、プロトコルデータユニット（PDU）の本体内のすべてのコンテンツに対してタイプ長値（TLV）を符号化する。プロトコルへの新しい拡張機能は、新しいTLVを定義することによってサポートされています。プロトコル拡張機能を後方互換性のある方法で展開できるようにするためには、理解できないTLVを無視するために実装が必要です。この動作は、TLVS内に含まれているSUB-TLVS [RFC5305]にも適用されます。
Also essential to the correct operation of the protocol is having the validation of PDUs be independent from the validation of the TLVs contained in the PDU. PDUs that are valid must be accepted [ISO10589] even if an individual TLV contained within that PDU is not understood or is invalid in some way (e.g., incorrect syntax, data value out of range, etc.).
プロトコルの正しい動作が不可欠であり、PDUの検証はPDUに含まれるTLVの検証とは独立していることである。そのPDU内に含まれる個々のTLVが理解されていない、または何らかの方法で無効であっても無効であっても（例えば、誤った構文、範囲外のデータ値、データ値）が無効であっても、有効なPDUを受け入れる必要があります[ISO10589]。
The set of TLVs (and sub-TLVs) that are allowed in each PDU type is documented in the "TLV Codepoints Registry" established by [RFC3563] and updated by [RFC6233] and [RFC7356].
各PDUタイプで許可されているTLV（およびサブTLV）のセットは、[RFC3563]が設定し、[RFC6233]と[RFC7356]によって確立された「TLV CodePointsレジストリ」に文書化されています。
This document is intended to clarify some aspects of existing specifications and, thereby, reduce the occurrence of non-conformant behavior seen in real-world deployments. Although behaviors specified in existing protocol specifications are not changed, the clarifications contained in this document serve as updates to [RFC5305] (see Section 3.3) and [RFC6232] (see Section 3.4).
この文書は、既存の仕様のいくつかの側面を明確にすることを目的としており、それによって、現実世界の展開で見られる不適合行動の発生を減らすことを目的としています。既存のプロトコル仕様で指定された動作は変更されていませんが、このドキュメントに含まれる明確化は[RFC5305]の更新として機能します（セクション3.3）、[RFC6232]（セクション3.4を参照）。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
[RFC3563] established the IANA-managed "IS-IS TLV Codepoints Registry" for recording assigned TLV codepoints [TLV_CODEPOINTS]. The initial contents of this registry were based on [RFC3359].
[RFC3563]割り当てられたTLV CodePoints [TLV_CODEPOINTS]を記録するためのIANA管理された「IS-IS TLV CEDEPOINTSレジストリ」を確立しました。このレジストリの初期内容は[RFC3359]に基づいていました。
The registry includes a set of columns indicating in which PDU types a given TLV is allowed:
レジストリには、与えられたTLVが許可されているPDUタイプを示す列のセットが含まれています。
IIH TLV is allowed in Intermediate System to Intermediate System Hello (IIH) PDUs (Point-to-point and LAN)
IIH TLVは中間システムで中間システムに使用できますHello（IIH）PDU（ポイントツーポイントとLAN）
LSP TLV is allowed in Link State PDUs (LSPs)
LSP TLVはリンク状態PDU（LSP）で許可されています
SNP TLV is allowed in Sequence Number PDUs (SNPs) (Partial Sequence Number PDUs (PSNPs) and Complete Sequence Number PDUs (CSNPs))
SNP TLVはシーケンス番号PDU（SNP）（部分シーケンス番号PDU（PSNP）および完全なシーケンス番号PDU（CSNP）で許可されています。
Purge TLV is allowed in LSP Purges [RFC6233]
PURGE TLVはLSPパージで許可されています[RFC6233]
If "Y" is entered in a column, it means the TLV is allowed in the corresponding PDU type.
列に "y"が入力された場合、それは対応するPDUタイプでTLVが許可されていることを意味します。
If "N" is entered in a column, it means the TLV is not allowed in the corresponding PDU type.
"n"が列に入力された場合、それは対応するPDUタイプでTLVが許可されていないことを意味します。
This section describes the correct behavior when a PDU that contains a TLV that is specified as disallowed in the "TLV Codepoints Registry" is received.
このセクションでは、 "TLV CodePointsレジストリ"で許可されていると指定されているTLVを含むPDUが受信された場合の正しい動作について説明します。
[ISO10589] defines the behavior required when a PDU is received containing a TLV that is "not recognised". It states (see Sections 9.5 - 9.13):
[ISO10589]「認識されていない」というTLVを含むPDUを受信したときに必要な動作を定義します。それは述べています（セクション9.5 - 9.13を参照）。
| Any codes in a received PDU that are not recognised shall be | ignored.
This is the model to be followed when a TLV that is disallowed is received. Therefore, TLVs in a PDU (other than LSP purges) that are disallowed MUST be ignored and MUST NOT cause the PDU itself to be rejected by the receiving IS.
これは、許可されていないTLVが受信されたときに続くモデルです。したがって、許可されていないPDU（LSPパージ以外の）のTLVは無視されなければならず、PDU自体を受信側で拒否させないでください。
When purging LSPs, [ISO10589] recommends (but does not require) the body of the LSP (i.e., all TLVs) be removed before generating the purge. LSP purges that have TLVs in the body are accepted, though any TLVs that are present are ignored.
LSPをパージすると、パージを発生させる前にLSPの本体（すなわち、すべてのTLV）を取り外すことをお勧めします（ただし必要としない）。存在するTLVは無視されますが、本体にTLVを持つLSPパージは受け入れられます。
When cryptographic authentication [RFC5304] was introduced, this looseness when processing received purges had to be addressed in order to prevent attackers from being able to initiate a purge without having access to the authentication key. Therefore, [RFC5304] imposed strict requirements on what TLVs were allowed in a purge (authentication only) and specified that:
暗号認証[RFC5304]が導入された場合、受信パージを処理するときのこのゆるみは、認証キーにアクセスすることなくパージを開始できるのを防ぐためにアドレス指定されなければならなかった。したがって、[RFC5304]は、PURGE（認証のみ）にTLVを許可されたものに関する厳密な要件を課し、次のように指定します。
| ISes MUST NOT accept purges that contain TLVs other than the | authentication TLV.
This behavior was extended by [RFC6232], which introduced the Purge Originator Identification (POI) TLV, and [RFC6233], which added the "Purge" column to the "TLV Codepoints Registry" to identify all the TLVs that are allowed in purges.
この現象は[RFC6232]によって拡張されました。これは、パージオリジネータID（POI）TLVを導入し、「PURGE」列を「TLV CodePointsレジストリ」に追加し、パージで許可されているすべてのTLVを識別しました。
The behavior specified in [RFC5304] is not backwards compatible with the behavior defined by [ISO10589]; therefore, it can only be safely enabled when all nodes support cryptographic authentication. Similarly, the extensions defined by [RFC6232] are not compatible with the behavior defined in [RFC5304]; therefore, they can only be safely enabled when all nodes support the extensions.
[RFC5304]で指定された動作は、[ISO10589]で定義されている動作と逆方向に互換性がありません。したがって、すべてのノードが暗号認証をサポートしている場合にのみ安全に有効にできます。同様に、[RFC6232]で定義されている拡張子は[RFC5304]で定義されている動作と互換性がありません。したがって、それらはすべてのノードが拡張機能をサポートしている場合にのみ安全に有効にすることができます。
When new protocol behaviors are specified that are not backwards compatible, it is RECOMMENDED that implementations provide controls for their enablement. This serves to prevent interoperability issues and allow for non-disruptive introduction of the new functionality into an existing network.
後方互換性がない新しいプロトコル動作が指定されている場合は、実装がそれらの有効化のためのコントロールを提供することをお勧めします。これは相互運用性の問題を防ぎ、既存のネットワークへの新しい機能を破壊することを可能にするのに役立ちます。
[RFC5305] introduced sub-TLVs, which are TLV tuples advertised within the body of a parent TLV. Registries associated with sub-TLVs are associated with the "TLV Codepoints Registry" and specify in which TLVs a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the following sentence:
[RFC5305]は、親TLVの本体内で広告されているTLVタプルであるSUB-TLVを導入しました。SUB-TLVに関連付けられているレジストリは、 "TLV CodePointsレジストリ"に関連付けられており、指定されたSUB-TLVが許可されているTLVSを指定します。[RFC5305]のセクション2は次の文によって更新されます。
| As with TLVs, it is required that sub-TLVs that are disallowed | MUST be ignored on receipt.
The existing sentence in Section 2 of [RFC5305]:
[RFC5305]のセクション2の既存の文：
| Unknown sub-TLVs are to be ignored and skipped upon receipt.
is replaced by:
に置き換えられます。
| Unknown sub-TLVs MUST be ignored and skipped upon receipt.
An error was introduced by [RFC6232] when specifying in which PDUs the POI TLV is allowed. Section 3 of [RFC6232] states:
POI TLVが許可されているPDUを指定する場合、[RFC6232]によってエラーが発生しました。[RFC6232]の第3章状態
| The POI TLV SHOULD be found in all purges and MUST NOT be found in | LSPs with a non-zero Remaining Lifetime.
However, the IANA section of the same document states:
ただし、同じ文書のIANAセクションは次のとおりです。
| The additional values for this TLV should be IIH:n, LSP:y, SNP:n, | and Purge:y.
The correct setting for "LSP" is "n". This document updates [RFC6232] by correcting that error.
"LSP"の正しい設定は "IN"です。この文書は、そのエラーを修正することによって[RFC 6232]を更新します。
This document also updates the previously quoted text from Section 3 of [RFC6232] to be:
このドキュメントでは、「RFC6232」のセクション3からの以前に引用されたテキストも更新されます。
| The POI TLV SHOULD be sent in all purges and MUST NOT be sent in | LSPs with a non-zero Remaining Lifetime.
The correct format of a TLV and its associated sub-TLVs, if applicable, is defined in the document(s) that introduces each codepoint. The definition MUST include what action to take when the format/content of the TLV does not conform to the specification (e.g., "MUST be ignored on receipt"). When making use of the information encoded in a given TLV (or sub-TLV), receiving nodes MUST verify that the TLV conforms to the standard definition. This includes cases where the length of a TLV/sub-TLV is incorrect and/or cases where the value field does not conform to the defined restrictions.
該当する場合、TLVとその関連するサブTLVの正しい形式は、各コードポイントを導入する文書で定義されています。定義には、TLVのフォーマット/コンテンツが仕様に準拠していないときにどのような処置を含める必要があります（例えば、受信時には無視する必要があります）。特定のTLV（またはSUB-TLV）でエンコードされた情報を使用する場合、受信ノードはTLVが標準定義に準拠していることを確認する必要があります。これには、TLV / SUB-TLVの長さが正しくない場合や、値フィールドが定義された制限に準拠していない場合が含まれます。
However, the unit of flooding for the IS-IS Update process is an LSP. The presence of a TLV (or sub-TLV) with content that does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected. Failure to follow this requirement will result in inconsistent LSP Databases on different nodes in the network that will compromise the correct operation of the protocol.
ただし、IS-IS更新プロセスのフラッディングの単位はLSPです。関連する仕様に準拠していないコンテンツを含むTLV（またはサブTLV）の存在は、LSP自体を拒否させてはいけません。この要件に従わないと、ネットワーク内の異なるノード上のLSPデータベースが正しい操作を損なうであろうLSPデータベースが矛盾します。
LSP Acceptance rules are specified in [ISO10589]. Acceptance rules for LSP purges are extended by [RFC5304] and [RFC5310] and are further extended by [RFC6233].
LSP受付規則は[ISO10589]に指定されています。LSPパージの受付規則は[RFC5304]と[RFC5310]によって拡張され、[RFC6233]によってさらに拡張されます。
[ISO10589] also specifies the behavior when an LSP is not accepted. This behavior is _not_ altered by extensions to the LSP Acceptance rules, i.e., regardless of the reason for the rejection of an LSP, the Update process on the receiving router takes the same action.
[ISO10589] LSPが受け入れられていないときの動作を指定します。この動作は、LSPの拒否の理由にかかわらず、LSPの拒否の理由にかかわらず、LSPの拒否の理由にかかわらず、_NOT_、すなわち受信ルータの更新処理が同じ動作をする。
IANA has added this document as a reference for the "TLV Codepoints Registry".
この文書を「TLV CodePoint Registry」の参照として追加しました。
IANA has also modified the entry for the Purge Originator Identification TLV in the "TLV Codepoints Registry" to be IIH:n, LSP:n, SNP:n, and Purge:y.
IANAは、「TLV CodePointsレジストリ」でパージ発信者識別情報TLVのエントリを変更して、N、LSP：N、SNP：N、およびPURGE：Y。
The reference field of the Purge Originator Identification TLV has been updated to point to this document.
パージ発信者識別の参照フィールドTLVはこの文書を指すように更新されました。
As this document makes no changes to the protocol, there are no new security issues introduced.
このドキュメントはプロトコルに変更を加えないように、新しいセキュリティ問題は発生しません。
The clarifications discussed in this document are intended to make it less likely that implementations will incorrectly process received LSPs, thereby also making it less likely that a bad actor could exploit a faulty implementation.
この文書で説明されている明確化は、実装が誤って受信されたLSPを処理する可能性が低くなることを意図しています。
Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], and [RFC5310].
IS-ISのセキュリティ上の懸念は[ISO10589]、[RFC5304]、[RFC5310]で説明しています。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]標準化のための国際機関 - システム間の電気通信および情報交換コネクションレスモードネットワークサービスを提供するためのプロトコルと組み合わせて使用するためのイントラドメイン内ルーティング情報交換プロトコル（ISO）8473）」、ISO / IEC 10589：2002年、第2版、2002年11月。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 3563, DOI 10.17487/RFC3563, July 2003, <https://www.rfc-editor.org/info/rfc3563>.
[RFC3563]ジニン、A。、「ISOC / IETFとISO / IEC共同技術委員会1 / SUB委員会6（JTC1 / SC6）は、RFC 3563、DOI 10.17487 / RFC3563との間の協調契約」、2003年7月、<https：//www.rfc-editor.org/info/rfc3563>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T.およびR.Atkinson、「IS-IS暗号認証」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<https：//www.rfc-editor.org/info/rfc5304>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T.およびH. SMIT、「IS-IS ASTINS Extensions」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https：//www.rfc-editor.org/info/rfc5305>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R.、およびM. Fanto、 "Is-Is Generic Cryptographic認証"、RFC 5310、DOI 10.17487 / RFC5310、2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, <https://www.rfc-editor.org/info/rfc6232>.
[RFC6232] Wei、F.、Qin、Y。、Li、Z.、Li、T.、およびJ.Dong、「IS-IS」、RFC 6232、DOI 10.17487 / RFC6232、2011年5月、<https://www.rfc-editor.org/info/rfc6232>。
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, <https://www.rfc-editor.org/info/rfc6233>.
[RFC6233] Li、T.およびL. Ginsberg、 "Is-Is Purges"、RFC 6233、DOI 10.17487 / RFC6233、2011年5月、<https：//www.rfc-editor.org/info/rfc6233>。
[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>。
[TLV_CODEPOINTS] IANA, "IS-IS TLV Codepoints", <https://www.iana.org/assignments/isis-tlv-codepoints/>.
[TLV_CODEPOINTS] IANA、 "IS-IS TLV CEDEPOINTS"、<https://www.iana.org/ashignments/iis-tlv-codepoints/>。
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, DOI 10.17487/RFC3359, August 2002, <https://www.rfc-editor.org/info/rfc3359>.
[RFC3359] Przygienda、T.、中間システムへの予約タイプ、長さ、および値（TLV）コードポイント、RFC 3359、DOI 10.17487 / RFC3359、2002年8月、<https://www.rfc-editor.org/ INFO / RFC3359>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S.、Y。Yang、 "IS-IS洪水スコープリンクステートPDUS（LSP）"、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<https：// www。rfc-editor.org/info/rfc7356>。
Acknowledgements
謝辞
The authors would like to thank Alvaro Retana.
著者らはAlvaro retanaに感謝したいです。
Authors' Addresses
著者の住所
Les Ginsberg Cisco Systems
Lesberg Cisco Systems.
Email: ginsberg@cisco.com
Paul Wells Cisco Systems
Paul Wellsシスコシステムズ
Email: pauwells@cisco.com
Tony Li Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 United States of America
Tony Li Arista Networks 5453 Great America Parkwayサンタクララ、CA 95054アメリカ合衆国
Email: tony.li@tony.li
Tony Przygienda Juniper Networks, Inc. 1194 N. Matilda Ave Sunnyvale, CA 94089 United States of America
Tony Przygienda Juniper Networks、Inc。1194 N. Matilda Ave Sunnyvale、CA 94089アメリカ合衆国
Email: prz@juniper.net
Shraddha Hegde Juniper Networks, Inc. Embassy Business Park Bangalore 560093 KA India
Shraddha Hegde Juniper Networks、Inc. Envassy Business Park Bangalore 560093 Ka India
Email: shraddha@juniper.net