RFC 8786 - Updated Rules for Processing Stateful PCE Request Parameters Flags 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8786.html
タイトル : RFC 8786 - ステートフルPCE要求パラメーターフラグを処理するための更新されたルール
翻訳編集 : 自動生成

[要約] RFC 8786は、状態を持つPCEリクエストパラメータフラグの処理ルールを更新するためのものです。その目的は、状態を持つPCEリクエストのパラメータフラグの処理を改善し、ネットワークの効率と信頼性を向上させることです。

Internet Engineering Task Force (IETF)                         A. Farrel
Request for Comments: 8786                            Old Dog Consulting
Updates: 8231                                                   May 2020
Category: Standards Track
ISSN: 2070-1721

Updated Rules for Processing Stateful PCE Request Parameters Flags

ステートフルPCE要求パラメーターフラグを処理するための更新されたルール

Abstract

概要

Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.

ステートフルパス計算エレメント（PCE）をサポートするためのパス計算エレメント通信プロトコル（PCEP）の拡張は、RFC 8231で定義されています。拡張の1つは、ステートフルPCE要求パラメーター（SRP）オブジェクトです。そのオブジェクトには、32ビットフラグのセットであるFlagsフィールドが含まれており、RFC 8281は、割り当てられたフラグを追跡するためのIANAレジストリを定義しています。ただし、RFC 8231は、実装が送信メッセージの未割り当てフラグを設定する方法、または実装が受信メッセージの未割り当て、不明、またはサポートされていないフラグを処理する方法については説明していません。

This document updates RFC 8231 by defining the correct behaviors.

このドキュメントでは、正しい動作を定義することでRFC 8231を更新しています。

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/rfc8786.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8786で入手できます。

著作権表示

著作権（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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Requirements Language
   3.  Updated Procedures
     3.1.  Advice for Specification of New Flags
     3.2.  Flags Field of the SRP Object
   4.  Compatibility Considerations
   5.  Management Considerations
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

[RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.

[RFC5440]は、Path Computation Element Communication Protocol（PCEP）について説明しています。 PCEPは、パス計算クライアント（PCC）とパス計算エレメント（PCE）の間、またはPCE間の通信を定義し、トラフィックエンジニアリングラベルスイッチドパス（TE LSP）特性のマルチプロトコルラベルスイッチング（MPLS）の計算を可能にします。

[RFC8231] specifies a set of extensions to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect Label Switched Path (LSP) State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions.

[RFC8231]は、PCEPへの一連の拡張を指定して、[RFC4657]に準拠してPCEPセッション内およびPCEPセッション全体でLSPのステートフル制御を可能にします。これには、PCCとPCE間のラベルスイッチドパス（LSP）状態の同期、LSPからPCEへの制御の委任、PCEPセッション内およびPCEPセッション間でのパス計算のタイミングとシーケンスのPCE制御を行うメカニズムが含まれます。

One of the extensions defined in [RFC8231] is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned or unknown flags in received messages.

[RFC8231]で定義されている拡張機能の1つは、ステートフルPCEリクエストパラメータ（SRP）オブジェクトです。そのオブジェクトには、32ビットフラグのセットであるFlagsフィールドが含まれており、RFC 8281は、割り当てられたフラグを追跡するためのIANAレジストリを定義しています。ただし、RFC 8231は、実装が送信メッセージの未割り当てフラグを設定する方法、または実装が受信メッセージの未割り当てフラグまたは不明フラグを処理する方法については説明していません。

Furthermore, [RFC8231] gives no guidance to the authors of future specifications about how to describe the interaction between flags that have already been defined and flags being defined in the new specifications.

さらに、[RFC8231]は、すでに定義されているフラグと新しい仕様で定義されているフラグとの間の相互作用を記述する方法について、将来の仕様の作成者にガイダンスを提供していません。

This document updates RFC 8231 by defining the correct behaviors.

このドキュメントでは、正しい動作を定義することでRFC 8231を更新しています。

2. Requirements Language

2. 要件言語

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]で説明されているように解釈されます。

3. Updated Procedures

3. 更新された手順

3.1. Advice for Specification of New Flags

3.1. 新しいフラグの指定に関するアドバイス

Section 7 of [RFC8231] introduces changes to existing PCEP objects and defines new PCEP objects and TLVs in support of stateful PCE functionality. That text does not advise future specifications on how to describe the interaction between flags that may be defined.

[RFC8231]のセクション7は、既存のPCEPオブジェクトへの変更を紹介し、ステートフルPCE機能をサポートする新しいPCEPオブジェクトとTLVを定義します。そのテキストは、定義される可能性のあるフラグ間の相互作用を説明する方法に関する将来の仕様を助言しません。

The text in Section 7 of [RFC8231] is updated to read as follows:

[RFC8231]のセクション7のテキストは、次のように更新されます。

The PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440]. The P and I flags of the PCEP objects defined in the current document MUST be set to 0 on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests.

このドキュメントで定義されているPCEPオブジェクトは、[RFC5440]で定義されているPCEPオブジェクト形式に準拠しています。現在のドキュメントで定義されているPCEPオブジェクトのPフラグとIフラグは、送信時に0に設定する必要があり、パス計算要求にのみ関連しているため、受信時に無視する必要があります。

The sections that follow define PCEP objects and TLVs that contain Flags fields, and some flag values are defined. Future specifications may define further flags, and each new specification that defines additional flags is expected to describe the interaction between these new flags and any existing flags. In particular, new specifications are expected to explain how to handle the cases when both new and pre-existing flags are set.

以下のセクションでは、フラグフィールドを含むPCEPオブジェクトとTLVを定義し、いくつかのフラグ値が定義されています。将来の仕様ではさらにフラグを定義する可能性があり、追加のフラグを定義する新しい仕様はそれぞれ、これらの新しいフラグと既存のフラグとの間の相互作用を記述することが期待されています。特に、新しい仕様では、新しいフラグと既存のフラグの両方が設定されている場合の処理方法を説明することが期待されています。

3.2. Flags Field of the SRP Object

3.2. SRPオブジェクトのフラグフィールド

Section 7.2 of [RFC8231] defines the PCEP SRP object. It describes the Flags field as:

[RFC8231]のセクション7.2は、PCEP SRPオブジェクトを定義しています。 Flagsフィールドは次のように記述されています。

Flags (32 bits): None defined yet.

フラグ（32ビット）：まだ定義されていません。

This document updates that text as follows:

このドキュメントは、そのテキストを次のように更新します。

Flags (32 bits): This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag.

フラグ（32ビット）：このドキュメントではフラグを定義していません。割り当てられていないフラグは、送信時にゼロに設定する必要があり、受信時に無視する必要があります。特定のフラグを理解しない実装では、フラグを無視する必要があります。

4. Compatibility Considerations

4. 互換性に関する考慮事項

While one of the main objectives of the changes made by this document is to enable backward compatibility, there remains an issue of compatibility between existing implementations of RFC 8231 and implementations that are consistent with this document.

このドキュメントによって加えられた変更の主な目的の1つは下位互換性を有効にすることですが、RFC 8231の既存の実装とこのドキュメントと一致する実装との間の互換性の問題が残っています。

It should be noted that common behavior for Flags fields is as described by the updated text presented in Section 3. Thus, many implementations, lacking guidance from RFC 8231, will still have implemented a consistent and future-proof approach. However, for completeness, it is worth noting how behaviors might interact between implementations.

フラグフィールドの一般的な動作は、セクション3で提示される更新されたテキストで説明されているとおりであることに注意してください。ただし、完全を期すために、振る舞いが実装間でどのように相互作用するかについては注目に値します。

SRP objects generated by an implementation of this document will set all unknown flag bits to zero and will therefore cause no issues to an older implementation even if it inspects those bits. Similarly, an implementation of this document will not inspect any unknown flag bits and will therefore be unaffected by older implementations no matter how they set the flags.

このドキュメントの実装によって生成されたSRPオブジェクトは、すべての不明なフラグビットをゼロに設定するため、それらのビットを検査しても、古い実装に問題を引き起こしません。同様に、このドキュメントの実装は不明なフラグビットを検査しないため、フラグの設定方法に関係なく、古い実装の影響を受けません。

There will remain an issue with compatibility between implementations and how they set the flags. An implementation of RFC 8231 might set any of the unassigned flags, but an implementation of a future or current specification (such as [RFC8281] or [RFC8741]) assigns specific meanings to a flag if set. That problem cannot be fixed in old implementations by any amount of documentation and can only be handled for future specifications by obsoleting the Flags field and using a new technique. Fortunately, however, most implementations will have been constructed to set unused flags to zero, which is consistent with the behavior described in this document, and so the risk of bad interactions is sufficiently small that there is no need to obsolete the existing Flags field.

実装間の互換性、およびフラグの設定方法には引き続き問題があります。 RFC 8231の実装は、未割り当てのフラグのいずれかを設定する可能性がありますが、将来または現在の仕様（[RFC8281]または[RFC8741]など）の実装は、設定されている場合、フラグに特定の意味を割り当てます。この問題は、古い実装では修正できず、フラグフィールドを廃止し、新しい手法を使用することで、将来の仕様でのみ対処できます。ただし、幸いにも、ほとんどの実装は未使用のフラグをゼロに設定するように構築されています。これは、このドキュメントで説明されている動作と一致しているため、悪い相互作用のリスクは十分に小さいため、既存のフラグフィールドを廃止する必要はありません。

5. Management Considerations

5. 管理上の考慮事項

Implementations receiving set SRP flags that they do not recognize MAY log this. That could be helpful for diagnosing backward compatibility issues with future features that utilize those flags.

認識しない設定のSRPフラグを受信する実装は、これをログに記録できます。これは、これらのフラグを利用する将来の機能との下位互換性の問題を診断するのに役立ちます。

6. Security Considerations

6. セキュリティに関する考慮事項

[RFC8231] sets out security considerations for PCEP when used for communication with a stateful PCE. This document does not change those considerations.

[RFC8231]は、ステートフルPCEとの通信に使用される場合のPCEPのセキュリティに関する考慮事項を示します。このドキュメントはそれらの考慮事項を変更しません。

However, by defining the expected behavior of implementations, this document may improve the stability of networks and thus reduce the attack surface. That is, by reminding implementations to ignore unset bits, it is less possible to attack them by randomly tweaking bits. Furthermore, by reminding implementations to leave undefined bits unset, the network is future-proofed against new definitions of previously undefined bits.

ただし、実装の予想される動作を定義することにより、このドキュメントはネットワークの安定性を向上させ、攻撃面を減らす可能性があります。つまり、設定されていないビットを無視するように実装に通知することにより、ビットをランダムに微調整することでそれらを攻撃する可能性が低くなります。さらに、未定義のビットを未設定のままにするように実装に通知することで、ネットワークは、以前に未定義のビットの新しい定義に対して将来的に保証されます。

7. IANA Considerations

7. IANAに関する考慮事項

IANA maintains a registry called the "Path Computation Element Protocol (PCEP) Numbers" registry with a subregistry called "SRP Object Flag Field". IANA has updated the reference for that subregistry to list this document in addition to [RFC8281].

IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリと呼ばれるレジストリを、「SRP Object Flag Field」と呼ばれるサブレジストリとともに維持しています。 IANAは、[RFC8281]に加えてこのドキュメントをリストするように、そのサブレジストリのリファレンスを更新しました。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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>。

[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>。

[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>.

[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。

[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>.

[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<https://www.rfc-editor.org/info/rfc8281>。

8.2. Informative References

8.2. 参考引用

[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.

[RFC4657] Ash、J.、Ed。およびJ.L. Le Roux、Ed。、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、DOI 10.17487 / RFC4657、2006年9月、<https://www.rfc-editor.org/info/rfc4657>。

[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.

[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、DOI 10.17487 / RFC5440、March 2009、<https://www.rfc-editor.org/info/rfc5440>

[RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and M. Negi, "Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, <https://www.rfc-editor.org/info/rfc8741>.

[RFC8741] Raghuram、A.、Goddard、A.、Karthik、J.、Sivabalan、S.、and M. Negi、 "Ability for a Stateful Path Computation Element（PCE）to Request and Control of a Label Switched Path（ LSP）」、RFC 8741、DOI 10.17487 / RFC8741、2020年3月、<https://www.rfc-editor.org/info/rfc8741>。

Acknowledgements

謝辞

Thanks to the authors of [RFC8741] for exposing the need for this work. Thanks to Dhruv Dhody and Julien Meuric for discussing the solution. Additional thanks to Hariharan Ananthakrishnan for his Shepherd's review. Thanks to Benjamin Kaduk and Alvaro Retana for helpful comments during IESG review.

[RFC8741]の作者にこの作業の必要性を明らかにしてくれてありがとう。解決策について議論してくれたDhruv DhodyとJulien Meuricに感謝します。彼の羊飼いのレビューをしてくれたHariharan Ananthakrishnanにさらに感謝します。 IESGレビューの際に役立つコメントを提供してくれたBenjamin KadukとAlvaro Retanaに感謝します。

Author's Address

著者のアドレス

Adrian Farrel Old Dog Consulting

エイドリアンファレルオールドドッグコンサルティング

   Email: adrian@olddog.co.uk