[要約] 要約：RFC 8690は、RFC 8287のセグメントIDサブTLVの長さに関する明確化を提供しています。 目的：このRFCの目的は、RFC 8287のセグメントIDサブTLVの長さに関する混乱を解消し、正確な仕様を提供することです。
Internet Engineering Task Force (IETF) N. Nainar
Request for Comments: 8690 C. Pignataro
Updates: 8287 Cisco Systems, Inc.
Category: Standards Track F. Iqbal
ISSN: 2070-1721 Individual
A. Vainshtein
ECI Telecom
December 2019
Clarification of Segment ID Sub-TLV Length for RFC 8287
RFC 8287のセグメントIDサブTLV長の明確化
Abstract
概要
RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.
RFC 8287は、MPLSデータプレーンでセグメントルーティングIGPプレフィックスとIGP隣接セグメント識別子（SID）のLSP PingとTracerouteを実行する拡張機能を定義しています。 RFC 8287は、3つのターゲット転送等価クラス（FEC）スタックサブTLVを提案しています。 RFC 8287はこれらのサブTLVを処理するための形式と手順を定義していますが、セグメントIDサブTLVの長さを計算してサブTLVの長さフィールドに含める方法を十分に明確にしていません。このあいまいさにより、相互運用性の問題が発生しています。
This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.
このドキュメントは、RFC 8287で定義されている各セグメントIDサブTLVの長さを明確にすることにより、RFC 8287を更新します。
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/rfc8690.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8690で入手できます。
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
2. Terminology
3. Requirements Notation
4. Length Field Clarification for Segment ID Sub-TLVs
4.1. IPv4 IGP-Prefix Segment ID Sub-TLV
4.2. IPv6 IGP-Prefix Segment ID Sub-TLV
4.3. IGP-Adjacency Segment ID Sub-TLV
5. IANA Considerations
6. Security Considerations
7. Normative References
Acknowledgements
Contributors
Authors' Addresses
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. [RFC8287] proposes three Target FEC Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs, which may result in interoperability issues.
[RFC8287]は、MPLSデータプレーンでのセグメントルーティングIGPプレフィックスおよびIGP隣接セグメント識別子（SID）のMPLS LSP pingおよびTracerouteの拡張を定義します。 [RFC8287]は、3つのターゲットFECスタックサブTLVを提案します。 RFC 8287は、これらのサブTLVを処理するための形式と手順を定義していますが、セグメントIDサブTLVの長さを計算してサブTLVの長さフィールドに含める方法を十分に明確にしていないため、相互運用性の問題。
This document updates [RFC8287] by clarifying the length of each Segment ID sub-TLVs defined in [RFC8287].
このドキュメントは、[RFC8287]で定義されている各セグメントIDサブTLVの長さを明確にすることにより、[RFC8287]を更新します。
This document uses the terminology defined in [RFC8402], [RFC8029], and [RFC8287]; readers are expected to be familiar with the terms as used in those documents.
このドキュメントでは、[RFC8402]、[RFC8029]、および[RFC8287]で定義されている用語を使用しています。読者は、これらのドキュメントで使用されている用語に精通している必要があります。
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]で説明されているように解釈されます。
Section 5 of [RFC8287] defines three different Segment ID sub-TLVs that can be included in the Target FEC Stack TLV defined in [RFC8029]. The length of each sub-TLV MUST be calculated as defined in this section.
[RFC8287]のセクション5は、[RFC8029]で定義されているターゲットFECスタックTLVに含めることができる3つの異なるセグメントIDサブTLVを定義しています。各サブTLVの長さは、このセクションで定義されているように計算する必要があります。
The TLV representations defined in Sections 5.1, 5.2, and 5.3 of [RFC8287] are updated to clarify the length calculations, as shown in Sections 4.1, 4.2, and 4.3, respectively. The updated TLV representations contain explicitly defined lengths.
[RFC8287]のセクション5.1、5.2、および5.3で定義されているTLV表現は、セクション4.1、4.2、および4.3にそれぞれ示されているように、長さの計算を明確にするために更新されています。更新されたTLV表現には、明示的に定義された長さが含まれています。
The sub-TLV length for the IPv4 IGP-Prefix Segment ID MUST be set to 8, as shown in the TLV format below:
IPv4 IGPプレフィックスセグメントIDのサブTLV長は、以下のTLV形式に示すように、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 = 34 (IPv4 IGP-Prefix SID)| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-TLV length for the IPv6 IGP-Prefix Segment ID MUST be set to 20, as shown in the TLV format below:
IPv6 IGPプレフィックスセグメントIDのサブTLVの長さは、以下のTLV形式に示すように、20に設定する必要があります。
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 = 35 (IPv6 IGP-Prefix SID)| Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IPv6 Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-TLV length for the IGP-Adjacency Segment ID varies depending on the Adjacency Type and Protocol. In any of the allowed combinations of Adjacency Type and Protocol, the sub-TLV length MUST be calculated by including 2 octets of the Reserved field. Table 1 lists the length for different combinations of Adj. Type and Protocol.
IGP隣接セグメントIDのサブTLVの長さは、隣接タイプとプロトコルによって異なります。隣接タイプとプロトコルの許可された組み合わせのいずれかで、サブTLVの長さは、予約フィールドの2オクテットを含めることによって計算する必要があります。表1は、調整のさまざまな組み合わせの長さを示しています。タイプとプロトコル。
+----------+-------------------------------------+
| Protocol | Length for Adj. Type |
| +----------+------+------+------------+
| | Parallel | IPv4 | IPv6 | Unnumbered |
+==========+==========+======+======+============+
| OSPF | 20 | 20 | 44 | 20 |
+----------+----------+------+------+------------+
| ISIS | 24 | 24 | 48 | 24 |
+----------+----------+------+------+------------+
| Any | 20 | 20 | 44 | 20 |
+----------+----------+------+------+------------+
Table 1: IGP-Adjacency SID Length Computation
表1：IGP隣接SIDの長さの計算
For example, when the Adj. Type is set to Parallel Adjacency and the Protocol is set to 0, the sub-TLV will be as below:
たとえば、調整時。タイプはParallel Adjacencyに設定され、プロトコルは0に設定されます。サブ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 = 36 (IGP-Adjacency SID) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type = 1 | Protocol = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IANA has listed this document as an additional reference for the following entries in the "Sub-TLVs for TLV Types 1, 16, and 21" registry:
IANAは、「TLVタイプ1、16、および21のサブTLV」レジストリの次のエントリの追加参照としてこのドキュメントをリストしています。
+----------+----------------------------+---------------------+
| Sub-Type | Sub-TLV Name | Reference |
+==========+============================+=====================+
| 34 | IPv4 IGP-Prefix Segment ID | Section 5.1 of |
| | | [RFC8287]; RFC 8690 |
+----------+----------------------------+---------------------+
| 35 | IPv6 IGP-Prefix Segment ID | Section 5.2 of |
| | | [RFC8287]; RFC 8690 |
+----------+----------------------------+---------------------+
| 36 | IGP-Adjacency Segment ID | Section 5.3 of |
| | | [RFC8287]; RFC 8690 |
+----------+----------------------------+---------------------+
Table 2: Sub-TLVs for TLV Types 1, 16, and 21 (Updated Entries)
表2：TLVタイプ1、16、および21のサブTLV（更新されたエントリ）
This document updates [RFC8287] and does not introduce any additional security considerations.
このドキュメントは[RFC8287]を更新し、セキュリティに関する追加の考慮事項を紹介していません。
[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>。
[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>。
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>.
[RFC8287] Kumar、N.、Ed。、Pignataro、C.、Ed。、Swallow、G.、Akiya、N.、Kini、S.、and M. Chen、 "Label Switched Path（LSP）Ping / Traceroute for Segment Routing（SR）IGP-Prefix and IGP-Adjacency Segment Identifiers（SIDs with MPLS Data Planes）」、RFC 8287、DOI 10.17487 / RFC8287、2017年12月、<https://www.rfc-editor.org/info/rfc8287 >。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
Acknowledgements
謝辞
The authors would like to thank Michael Gorokhovsky and Manohar Doppalapudi for investigating the interoperability issue during European Advanced Network Test Center (EANTC) testing.
著者は、European Advanced Network Test Center（EANTC）テスト中の相互運用性の問題を調査してくれたMichael GorokhovskyとManohar Doppalapudiに感謝します。
Contributors
貢献者
The following individual contributed to this document: Zafar Ali, Cisco Systems, Inc.
このドキュメントに貢献した個人：Zafar Ali、Cisco Systems、Inc.
Authors' Addresses
著者のアドレス
Nagendra Kumar Nainar Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Nagendra Kumar Nainar Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: naikumar@cisco.com
Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Carlos Pignataro Cisco Systems、Inc. 7200-11 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: cpignata@cisco.com
Faisal Iqbal Individual Canada
ファイサルイクバル個人カナダ
Email: faisal.ietf@gmail.com
Alexander Vainshtein ECI Telecom Israel
Alexander Vainshtein ECI Telecomイスラエル
Email: vainshtein.alex@gmail.com