[要約] RFC 9488 は、PCEP で使用される Local Protection Desired ビットの使用方法を明確にし、保護強制をシグナリングするための新しいフラグを導入することを目的としています。
Internet Engineering Task Force (IETF) A. Stone
Request for Comments: 9488 M. Aissaoui
Updates: 5440 Nokia
Category: Standards Track S. Sidor
ISSN: 2070-1721 Cisco Systems, Inc.
S. Sivabalan
Ciena Corporation
October 2023
This document updates RFC 5440 to clarify usage of the Local Protection Desired bit signaled in the Path Computation Element Communication Protocol (PCEP). This document also introduces a new flag for signaling protection enforcement in PCEP.
このドキュメントは、RFC 5440を更新して、PATH計算要素通信プロトコル（PCEP）でシグナルが示すローカル保護ビットの使用を明確にします。このドキュメントでは、PCEPのシグナリング保護施行のための新しいフラグも紹介します。
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/rfc9488.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9488で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Terminology
4. Motivation
4.1. Implementation Differences
4.2. SLA Enforcement
5. Protection Enforcement Flag (E Flag)
5.1. Backwards Compatibility
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The Path Computation Element Communication Protocol (PCEP) [RFC5440] enables the communication between a Path Computation Client (PCC) and a PCE or between two PCEs based on the PCE architecture [RFC4655].
PATH計算要素通信プロトコル（PCEP）[RFC5440]は、PATH計算クライアント（PCC）とPCEまたはPCEアーキテクチャに基づいて2つのPCE間の通信を可能にします[RFC4655]。
PCEP [RFC5440] utilizes flags, values, and concepts previously defined in RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP-TE [RFC4090]. One such concept in PCEP is the Local Protection Desired (L) flag in the LSP Attributes (LSPA) object in [RFC5440], which was originally defined in the Session Attribute object in [RFC3209]. In RSVP, this flag signals to downstream routers that they may use a local repair mechanism. The headend router calculating the path does not know if a downstream router will or will not protect a hop during its calculation. Therefore, the L flag does not require the transit router to satisfy protection in order to establish the RSVP-signaled path. This flag is signaled in PCEP as an attribute of the Label Switched Path (LSP) via the LSPA object.
PCEP [RFC5440]は、RSVP-TEエクステンション[RFC3209]で以前に定義されていたフラグ、値、および概念を使用し、RSVP-TE [RFC4090]に拡張機能を高速に再表示します。PCEPのそのような概念の1つは、[RFC5440]のLSP属性（LSPA）オブジェクトの希望の局所保護（L）フラグです。これは、[RFC3209]のセッション属性オブジェクトで元々定義されました。RSVPでは、このフラグは、ローカルな修復メカニズムを使用する可能性があることを下流ルーターに信号します。パスを計算するヘッドエンドルーターは、下流のルーターが計算中にホップを保護するかどうかを知りません。したがって、Lフラグは、RSVP署名パスを確立するために保護を満たすためにトランジットルーターを必要としません。このフラグは、LSPAオブジェクトを介してラベルスイッチされたパス（LSP）の属性としてPCEPで信号されています。
PCEP Extensions for Segment Routing [RFC8664] extends support in PCEP for Segment Routing paths. The path list is encoded with Segment Identifiers (SIDs), each of which might offer local protection. The PCE may discover the protection eligibility for a SID via the Border Gateway Protocol - Link State (BGP-LS) [RFC9085] and take the protection into consideration as a path constraint.
セグメントルーティングのPCEP拡張[RFC8664]は、セグメントルーティングパスのPCEPでサポートを拡張します。パスリストはセグメント識別子（SIDS）でエンコードされており、それぞれがローカル保護を提供する可能性があります。PCEは、Border Gateway Protocol -Link State（BGP -LS）[RFC9085]を介してSIDの保護適格性を発見し、パスの制約として保護を考慮に入れることができます。
It is desirable for an operator to be able to define the enforcement of the protection requirement.
オペレーターが保護要件の施行を定義できることが望ましいです。
This document updates [RFC5440] by further describing the behavior of the Local Protection Desired (L) flag and extends on it with the introduction of the Protection Enforcement (E) flag.
このドキュメントは、[RFC5440]を更新し、希望する（l）フラグの動作をさらに説明し、保護施行（e）フラグの導入とともに拡張します。
The document contains descriptions in the context of Segment Routing; however, the content described is agnostic in regard to path setup type and data plane technology.
ドキュメントには、セグメントルーティングのコンテキストでの説明が含まれています。ただし、説明されているコンテンツは、パスセットアップタイプとデータプレーンテクノロジーに関して不可知論者です。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following terminology:
このドキュメントでは、次の用語を使用しています。
PROTECTION MANDATORY:
必須の保護：
The path MUST have protection eligibility on all links.
パスには、すべてのリンクに保護の適格性が必要です。
UNPROTECTED MANDATORY:
保護されていない必須：
The path MUST NOT have protection eligibility on all links.
パスは、すべてのリンクに保護の適格性を持たないようにしてはなりません。
PROTECTION PREFERRED:
保護が望ましい：
The path should have protection eligibility on all links but might contain links that do not have protection eligibility.
パスには、すべてのリンクに保護の適格性が必要ですが、保護の適格性がないリンクが含まれている場合があります。
UNPROTECTED PREFERRED:
保護されていない優先：
The path should not have protection eligibility on all links but might contain links that have protection eligibility.
パスには、すべてのリンクに保護の適格性があるべきではありませんが、保護の適格性を持つリンクが含まれている可能性があります。
PCC:
PCC：
Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
パス計算クライアント。パス計算要素によって実行されるパス計算を要求するクライアントアプリケーション。
PCE:
PCE：
Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
PCEP:
PCEP：
Path Computation Element Communication Protocol
パス計算要素通信プロトコル
LSPA:
LSPA：
LSP Attributes object [RFC5440]
LSP属性オブジェクト[RFC5440]
As defined in [RFC5440], the mechanism to signal protection enforcement in PCEP is the previously mentioned L flag defined in the LSPA object. The name of the flag uses the term "Desired", which by definition means "strongly wished for or intended". The use case for this flag originated in RSVP. For RSVP-signaled paths, local protection is not within control of the PCE. However, [RFC5440] does state that "[w]hen set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]." Implementations that use PCEP [RFC5440] have interpreted the L flag as either PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational differences.
[RFC5440]で定義されているように、PCEPで保護施行を信号するメカニズムは、LSPAオブジェクトで定義された前述のLフラグです。フラグの名前は「望ましい」という用語を使用します。これは、定義上、「強く意図した、または意図した」ことを意味します。このフラグのユースケースは、RSVPから発生しました。RSVPシグナル付きパスの場合、局所保護はPCEの制御内ではありません。ただし、[rfc5440]は、「[w] henセット、これは[RFC4090]で定義されているように、計算されたパスに高速再ルートで保護されたリンクを含める必要があることを意味する」と述べています。PCEP [RFC5440]を使用する実装は、Lフラグを必須または保護のいずれかのいずれかのいずれかと解釈し、運用上の違いをもたらしました。
The L flag is a boolean bit and thus unable to distinguish between the different options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION PREFERRED, and UNPROTECTED PREFERRED. Selecting one of these options is typically dependent on the Service Level Agreement (SLA) the operator wishes to impose on the LSP. A network may be providing transit to multiple SLA definitions against the same base topology network, whose behavior could vary, such as wanting local protection to be invoked on some LSPs and not wanting local protection on others. When enforcement is used, the resulting shortest path calculation is impacted.
Lフラグはブールビットであるため、必須、保護されていない必須、保護が好まれ、保護されていないさまざまな保護オプションを区別することができません。これらのオプションのいずれかを選択することは、通常、サービスレベル契約（SLA）に依存します。オペレーターはLSPに課したいと考えています。ネットワークは、同じ基本トポロジネットワークに対して複数のSLA定義にトランジットを提供している可能性があり、その動作は、一部のLSPで局所保護を呼び出したい、他のLSPでローカル保護を望まないなど、動作が異なる可能性があります。執行が使用されると、結果として生じる最短経路計算が影響を受けます。
For example, PROTECTION MANDATORY is for use cases in which an operator may need the LSP to follow a path that has local protection provided along the full path, ensuring that traffic will be fast rerouted at the point if there is a failure anywhere along the path.
たとえば、必須の保護とは、オペレーターがLSPがフルパスに沿って提供されるパスに従うためにLSPを必要とする場合、パスに沿ってどこにでも障害がある場合にトラフィックが急速に再ルーティングされるようにすることができます。。
As another example, UNPROTECTED MANDATORY is for use cases in which an operator may intentionally prefer an LSP to not be locally protected and thus would rather local failures cause the LSP to go down. An example scenario is one where an LSP is protected via a secondary diverse LSP. Each LSP is traffic engineered to follow specific traffic-engineered criteria computed by the PCE to satisfy the SLA. Upon a failure, if local protection is invoked on the active LSP traffic, the traffic may temporarily traverse links that violate the TE requirements and could negatively impact the resources being traversed (e.g., insufficient bandwidth). In addition, depending on the network topological scenario, it may not be feasible for the PCE to reroute the LSP while respecting the TE requirements, which include path diversity; this results in the LSP being torn down and switched to the protected path anyways. In such scenarios, it is desirable for the LSP to be simply torn down immediately and not rerouted through local protection, so that traffic may be forwarded through an already-established traffic-engineered secondary path.
別の例として、保護されていない必須の必須は、オペレーターがLSPを局所的に保護しないことを意図的に好む可能性があるため、局所的な障害をむしろLSPがダウンさせるユースケースです。例のシナリオは、LSPが二次多様なLSPを介して保護されているシナリオです。各LSPは、SLAを満たすためにPCEによって計算された特定のトラフィックエンジニアリング基準に従うように設計されています。障害時に、アクティブなLSPトラフィックでローカル保護が呼び出された場合、トラフィックはTE要件に違反するリンクを一時的に通過し、移動するリソースに悪影響を与える可能性があります（例えば、帯域幅が不十分です）。さらに、ネットワークのトポロジシナリオに応じて、PATHの多様性を含むTE要件を尊重しながら、PCEがLSPを再ルーティングすることは実行不可能な場合があります。これにより、LSPが取り壊され、とにかく保護されたパスに切り替えられます。このようなシナリオでは、LSPがすぐに取り壊され、ローカル保護を通じて再ルーティングされないことが望ましいため、既に確立された交通機関で設計されたセカンダリパスを介してトラフィックが転送される可能性があります。
Both the UNPROTECTED PREFERRED and PROTECTED PREFERRED options provide a relaxation of the protection constraint. These options can be used when an operator does not require protection enforcement. Regardless of the option selected, the protection status of a resource does not influence whether the link must be pruned during a path calculation. Furthermore, the selection of either option indicates a priority selection to the PCE when there is an option to choose a protected or unprotected instruction associated with a resource, ensuring consistent PCE behavior across different implementations.
保護されていない優先および保護された優先オプションの両方が、保護制約の緩和を提供します。これらのオプションは、オペレーターが保護施行を必要としない場合に使用できます。選択されたオプションに関係なく、リソースの保護ステータスは、パス計算中にリンクを剪定する必要があるかどうかに影響しません。さらに、いずれかのオプションを選択すると、リソースに関連付けられた保護または保護されていない命令を選択するオプションがある場合、PCEの優先度選択が示され、異なる実装間で一貫したPCE動作が確保されます。
When used with Segment Routing, an adjacency may have both a protected SID and an unprotected SID. If the UNPROTECTED PREFERRED option is selected, the PCE chooses the unprotected SID. Alternatively, if the PROTECTED PREFERRED option is selected, the PCE chooses the protected SID.
セグメントルーティングで使用する場合、隣接すると保護されていないSIDの両方が保護されていない場合があります。保護されていない優先オプションが選択されている場合、PCEは保護されていないSIDを選択します。または、保護された優先オプションが選択されている場合、PCEは保護されたSIDを選択します。
Section 7.11 of [RFC5440] describes the encoding of the Local Protection Desired (L) flag. The Protection Enforcement (E) flag, which extends the L flag, is specified below.
[RFC5440]のセクション7.11は、希望する（L）フラグのエンコードについて説明します。Lフラグを拡張する保護施行（E）フラグを以下に指定します。
+=====+==========================+===========+
| Bit | Description | Reference |
+=====+==========================+===========+
| 6 | Protection Enforcement | RFC 9488 |
+-----+--------------------------+-----------+
| 7 | Local Protection Desired | RFC 5440 |
+-----+--------------------------+-----------+
Table 1: Codespace of the Flag Field (LSPA Object)
表1：フラグフィールドのコードスペース（LSPAオブジェクト）
The following shows the format of the LSPA object as defined in [RFC5440] with the addition of the E flag defined in this document:
以下は、[RFC5440]で定義されているLSPAオブジェクトの形式を示しています。このドキュメントで定義されているEフラグの追加を示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |E|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits):
フラグ（8ビット）：
L (Local Protection Desired):
l（希望するローカル保護）：
This flag is defined in [RFC5440] and further updated by this document. When set to 1, protection is desired. When set to 0, protection is not desired. The enforcement of the protection is identified via the E flag.
このフラグは[RFC5440]で定義されており、このドキュメントでさらに更新されます。1に設定すると、保護が必要です。0に設定すると、保護は望ましくありません。保護の施行は、Eフラグを介して特定されます。
E (Protection Enforcement):
E（保護施行）：
This flag controls the strictness with which the PCE must apply the L flag. When set to 1, the value of the L flag needs to be respected during resource selection by the PCE. When the E flag is set to 0, an attempt to respect the value of the L flag is made; however, the PCE could relax or ignore the L flag when computing a path. The statements below indicate preference when the E flag is set to 0 in combination with the L flag value.
このフラグは、PCEがLフラグを適用する必要がある厳格さを制御します。1に設定すると、PCEによるリソース選択中にLフラグの値を尊重する必要があります。Eフラグが0に設定されている場合、Lフラグの値を尊重する試みが作成されます。ただし、PCEはパスを計算するときにLフラグをリラックスまたは無視する可能性があります。以下のステートメントは、Lフラグ値と組み合わせてEフラグが0に設定されている場合の好みを示します。
L (Local Protection Desired): This flag is defined in [RFC5440] and further updated by this document. When set to 1, protection is desired. When set to 0, protection is not desired. The enforcement of the protection is identified via the E flag. E (Protection Enforcement): This flag controls the strictness with which the PCE must apply the L flag. When set to 1, the value of the L flag needs to be respected during resource selection by the PCE. When the E flag is set to 0, an attempt to respect the value of the L flag is made; however, the PCE could relax or ignore the L flag when computing a path. The statements below indicate preference when the E flag is set to 0 in combination with the L flag value.
L（希望のローカル保護）：このフラグは[RFC5440]で定義され、このドキュメントでさらに更新されます。1に設定すると、保護が必要です。0に設定すると、保護は望ましくありません。保護の施行は、Eフラグを介して特定されます。E（保護施行）：このフラグは、PCEがLフラグを適用しなければならない厳格さを制御します。1に設定すると、PCEによるリソース選択中にLフラグの値を尊重する必要があります。Eフラグが0に設定されている場合、Lフラグの値を尊重する試みが作成されます。ただし、PCEはパスを計算するときにLフラグをリラックスまたは無視する可能性があります。以下のステートメントは、Lフラグ値と組み合わせてEフラグが0に設定されている場合の好みを示します。
When both the L flag and E flag are set to 1, then the PCE MUST consider the protection eligibility as a PROTECTION MANDATORY constraint.
LフラグとEフラグの両方が1に設定されている場合、PCEは保護の適格性を必須の制約として保護の適格性を考慮する必要があります。
When the L flag is set to 1 and the E flag is set to 0, then the PCE MUST consider the protection eligibility as a PROTECTION PREFERRED constraint.
Lフラグが1に設定され、Eフラグが0に設定されている場合、PCEは保護の適格性を保護優先制約として考慮する必要があります。
When both the L flag and E flag are set to 0, then the PCE SHOULD consider the protection eligibility as an UNPROTECTED PREFERRED constraint but MAY consider the protection eligibility as an UNPROTECTED MANDATORY constraint. An example of when the latter behavior might be chosen is if the PCE has some means (outside the scope of this document) to detect that it is interacting with a legacy PCC that expects the legacy behavior.
LフラグとEフラグの両方が0に設定されている場合、PCEは保護の適格性を保護されていない優先制約として考慮する必要がありますが、保護の適格性を保護されていない必須の制約と見なす場合があります。後者の動作が選択される場合の例は、PCEに（このドキュメントの範囲外）何らかの手段がある場合、レガシーの動作を期待するレガシーPCCと相互作用していることを検出することです。
When the L flag is set to 0 and the E flag is set to 1, then the PCE MUST consider the protection eligibility as an UNPROTECTED MANDATORY constraint.
Lフラグが0に設定され、Eフラグが1に設定されている場合、PCEは保護の適格性を保護されていない必須の制約として考慮する必要があります。
If a PCE is unable to infer the protection status of a resource, the PCE MAY use local policy to define protected status assumptions. When computing a Segment Routing path, it is RECOMMENDED that a PCE assume a Node SID is protected. It is also RECOMMENDED that a PCE assume an Adjacency SID is protected if the backup flag advertised with the Adjacency SID is set.
PCEがリソースの保護ステータスを推測できない場合、PCEはローカルポリシーを使用して保護されたステータスの仮定を定義することができます。セグメントルーティングパスを計算する場合、PCEがノードSIDが保護されていると仮定することをお勧めします。また、隣接SIDで宣伝されているバックアップフラグが設定されている場合、PCEは隣接SIDが保護されると仮定することをお勧めします。
This section outlines considerations for the E flag bit in the message passing between the PCC and the PCE that are not supported by the entity. The requirements for the PCE and the PCC implementing this document are described at the end.
このセクションでは、PCCとエンティティによってサポートされていないPCCとPCEの間を通過するメッセージのEフラグビットの考慮事項の概要を説明します。このドキュメントを実装するPCEとPCCの要件については、最後に説明します。
For a PCC or PCE that does not yet support this document, the E flag is ignored and set to 0 in PCRpt and/or PCUpd messages as per [RFC5440] for PCC-initiated LSPs or as per [RFC8281] for PCE-initiated LSPs. It is important to note that [RFC8231] and [RFC8281] permit the LSPA object [RFC5440] to be included in PCUpd messages for PCC-initiated and PCE-initiated LSPs.
このドキュメントをまだサポートしていないPCCまたはPCEの場合、Eフラグは無視され、PCC開始LSPの場合、またはPCE開始LSPSの[RFC8281]に従って[RFC5440]に従ってPCRPTおよび/またはPCUPDメッセージで0に設定されます。。[RFC8231]と[RFC8281]は、LSPAオブジェクト[RFC5440]をPCC開始およびPCE開始LSPのPCUPDメッセージに含めることを許可することに注意することが重要です。
For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message is an echo from the previous PCRpt message; however, the bit value is ignored on the PCE from the previous PCRpt message, so the E flag value set in the PCUpd message is 0. A PCE that does not support this document sends PCUpd messages with the E flag set to 0 for PCC-initiated LSPs even if set to 1 in the prior PCReq or PCRpt message.
PCC開始LSPの場合、PCUPDメッセージのEフラグ（およびLフラグ）は、以前のPCRPTメッセージからのエコーです。ただし、前のPCRPTメッセージのPCEでビット値は無視されるため、PCUPDメッセージに設定されたEフラグ値は0です。以前のPCREQまたはPCRPTメッセージで1に設定されていても、LSPを開始しました。
A PCC that does not support this document sends PCRpt messages with the E flag set to 0 for PCE-initiated LSPs even if set to 1 in the prior PCInitiate or PCUpd message.
このドキュメントをサポートしていないPCCは、以前のPCInitiateまたはPCUPDメッセージで1に設定されていても、PCEフラグがPCE開始LSPで0に設定されたPCRPTメッセージを送信します。
For a PCC that does support this document, the E flag MAY be set to 1 depending on local configuration. If communicating with a PCE that does not yet support this document, the PCE follows the behavior specified in [RFC5440] and ignores the E flag. Thus, a computed path might not respect the enforcement constraint.
このドキュメントをサポートするPCCの場合、eフラグはローカル構成に応じて1に設定できます。このドキュメントをまだサポートしていないPCEと通信する場合、PCEは[RFC5440]で指定された動作に従い、Eフラグを無視します。したがって、計算されたパスは、施行の制約を尊重しない場合があります。
For PCC-initiated LSPs, the PCC SHOULD ignore the E flag value received from the PCE in a PCUpd message as it may be communicating with a PCE that does not support this document.
PCC開始LSPの場合、PCCは、このドキュメントをサポートしていないPCEと通信している可能性があるため、PCUPDメッセージでPCEから受信したEフラグ値を無視する必要があります。
For PCE-initiated LSPs, the PCC MAY process the E flag value received from the PCE in a PCUpd message. The PCE SHOULD ignore the E flag value received from the PCC in a PCRpt message as it may be communicating with a PCC that does not support this document.
PCE開始LSPの場合、PCCはPCUPDメッセージでPCEから受信したEフラグ値を処理する場合があります。PCHは、PCCPTメッセージでPCCから受信されたEフラグ値を無視する必要があります。これは、このドキュメントをサポートしていないPCCと通信している可能性があるためです。
This document clarifies the behavior of an existing flag and introduces a new flag to provide further control of that existing behavior. The introduction of this new flag and the behavior clarification do not create any new sensitive information. No additional security measure is required.
この文書は、既存のフラグの動作を明確にし、その既存の動作をさらに制御するために新しいフラグを導入します。この新しいフラグの導入と動作の明確化は、新しい機密情報を作成しません。追加のセキュリティ測定は必要ありません。
Securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC9325], is RECOMMENDED.
[RFC9325]の推奨事項と最良の慣行に従って、輸送層セキュリティ（TLS）[RFC8253]を使用してPCEPセッションを保護することをお勧めします。
This document defines a new bit value in the subregistry "LSPA Object Flag Field" in the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following codepoint allocation.
このドキュメントは、「PATH COMPUTATION ELEMENT PROTOCOL（PCEP）番号」のサブレジストリ「LSPAオブジェクトフラグフィールド」の新しいビット値を定義します。IANAは次のコードポイント割り当てを行いました。
+=====+========================+===========+
| Bit | Description | Reference |
+=====+========================+===========+
| 6 | Protection Enforcement | RFC 9488 |
+-----+------------------------+-----------+
Table 2: Addition to LSPA Object Flag Field Registry
表2：LSPAオブジェクトフラグフィールドレジストリへの追加
[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>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[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>.
[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>.
[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>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[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>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler,
H., and M. Chen, "Border Gateway Protocol - Link State
(BGP-LS) Extensions for Segment Routing", RFC 9085,
DOI 10.17487/RFC9085, August 2021,
<https://www.rfc-editor.org/info/rfc9085>.
Thanks to Dhruv Dhody, Mike Koldychev, and John Scudder for reviewing and providing very valuable feedback and discussions on this document.
Dhruv Dhody、Mike Koldychev、およびJohn Scudderに、この文書に関する非常に貴重なフィードバックと議論をレビューして提供してくれたことに感謝します。
Thanks to Julien Meuric for shepherding this document.
この文書を羊飼いしてくれたJulien Meuricに感謝します。
Andrew Stone
Nokia
600 March Road
Kanata Ontario K2K 2T6
Canada
Email: andrew.stone@nokia.com
Mustapha Aissaoui
Nokia
600 March Road
Kanata Ontario K2K 2T6
Canada
Email: mustapha.aissaoui@nokia.com
Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3
Pribinova 10
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com
Siva Sivabalan
Ciena Corporation
385 Terry Fox Drive
Kanata Ontario K2K 0L1
Canada
Email: ssivabal@ciena.com