Internet Engineering Task Force (IETF) W. Cheng, Ed.
Request for Comments: 9545 H. Li
Category: Standards Track China Mobile
ISSN: 2070-1721 C. Li, Ed.
Huawei Technologies
R. Gandhi
Cisco Systems, Inc.
R. Zigler
Broadcom
February 2024
A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.
セグメントルーティング（SR）パスは、SRセグメントリストで識別されます。セグメントリストのセグメントのサブセットをレバレッジして、あるSRパスが部分的に一致する可能性があるため、別のパスを区別することはできません。SRパス識別は、パフォーマンス測定やエンドツーエンド1 1パス保護など、さまざまなユースケースの前提条件です。
In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.
MPLS（SR-MPLS）データプレーンを介したSRでは、出力ノードは、パケットがネットワークを通過するとセグメント識別子がラベルスタックから削除されるため、ラベルスタックからネットワークを移動したSRパスを決定できません。
This document defines a Path Segment Identifier (PSID) to identify an SR path on the egress node of the path.
このドキュメントでは、パスの出口ノード上のSRパスを識別するパスセグメント識別子（PSID）を定義します。
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/rfc9545.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9545で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
1.1. Requirements Language
1.2. Abbreviations and Terms
2. Path Segment
2.1. Equal-Cost Multipath (ECMP) Considerations
3. Use Cases
3.1. PSID for Performance Measurement
3.2. PSID for Bidirectional SR Paths
3.3. PSID for End-to-End Path Protection
3.4. Nesting of PSIDs
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Segment Routing (SR) [RFC8402] leverages the source-routing paradigm to steer packets from a source node through a controlled set of instructions, called "segments", by prepending the packet with an SR header. In SR with the MPLS data plane [RFC8660], the SR header is instantiated through a label stack.
セグメントルーティング（SR）[RFC8402]は、ソースルーティングパラダイムを活用して、SRヘッダーでパケットを準備することにより、「セグメント」と呼ばれる制御された一連の命令セットを介してソースノードからパケットを操作します。MPLSデータプレーン[RFC8660]を使用したSRでは、SRヘッダーがラベルスタックを介してインスタンス化されます。
In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. The result of this is that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot use the SR label stack to determine along which SR path the packet came.
SR-MPLSネットワークでは、パケットがSRパスに沿って送信されると、MPLSラベルスタックのラベルが交換またはポップされます。この結果、パケットが出口ノードに到達したときに、ラベルまたは最後のラベルのみがMPLSラベルスタックに残されている可能性があります。したがって、出力ノードはSRラベルスタックを使用して、パケットがどのSRパスが来たかを決定することはできません。
However, identifying a path on the egress node is a prerequisite for various use cases in SR-MPLS networks, such as performance measurement (Section 3.1), bidirectional paths (Section 3.2), and end-to-end 1+1 path protection (a Live-Live case) (Section 3.3).
ただし、出力ノードのパスを識別することは、パフォーマンス測定（セクション3.1）、双方向パス（セクション3.2）、およびエンドツーエンド1 1パス保護など、SR-MPLSネットワークのさまざまなユースケースの前提条件です。ライブケース）（セクション3.3）。
Therefore, this document defines a new segment type, referred to herein as a "Path Segment". A Path Segment is defined to uniquely identify an SR path on the egress node of the path. It MAY be used by the egress node for path identification. Note that per-path state will be maintained in the egress node due to the requirements in the aforementioned use cases, though in normal cases, the per-path state will be maintained in the ingress node only.
したがって、このドキュメントは、本書で「パスセグメント」と呼ばれる新しいセグメントタイプを定義します。パスセグメントは、パスの出口ノード上のSRパスを一意に識別するために定義されます。パス識別のために出力ノードで使用できます。前述のユースケースの要件により、出力ノードでは1パスの状態が維持されることに注意してください。ただし、通常の場合、パスごとの状態はイングレスノードのみで維持されます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
MPLS:
MPLS：
Multiprotocol Label Switching
マルチプロトコルラベルスイッチング
PSID:
PSID：
Path Segment Identifier
パスセグメント識別子
SID:
シド：
Segment Identifier
セグメント識別子
SR:
SR：
Segment Routing
セグメントルーティング
SR-MPLS:
sr-mpls：
SR over MPLS
MPLS上のSR
SR path:
SRパス：
A path described by a segment list.
セグメントリストで説明されているパス。
Sub-Path:
サブパス：
A part of a path, which contains a subset of the nodes and links of the path.
パスの一部には、ノードのサブセットとパスのリンクが含まれています。
A Path Segment is a local segment [RFC8402] that uniquely identifies an SR path on the egress node. A Path Segment Identifier (PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) [RFC8402] of the egress node of an SR path.
パスセグメントは、出口ノードのSRパスを独自に識別するローカルセグメント[RFC8402]です。パスセグメント識別子（PSID）は、SRパスの出口ノードのローカルブロック（SRLB）[RFC8402]をルーティングするセグメントから割り当てられた単一のラベルです。
A PSID is used to identify a segment list. However, one PSID can be used to identify multiple segment lists in some use cases if needed. For example, one single PSID MAY be used to identify some or all segment lists in a candidate path or an SR policy if an operator would like to aggregate these segment lists in operation.
PSIDは、セグメントリストを識別するために使用されます。ただし、1つのPSIDを使用して、必要に応じて一部のユースケースで複数のセグメントリストを識別できます。たとえば、1つの単一のPSIDを使用して、オペレーターがこれらのセグメントリストを動作している場合、候補パスまたはSRポリシーの一部またはすべてのセグメントリストを識別することができます。
When a PSID is used, the PSID can be inserted at the ingress node and MUST immediately follow the last label of the SR path; in other words, it must be inserted after the routing segment (adjacency, node, or prefix segment) that is pointing to the egress node of the SR path. Therefore, a PSID will not be the top label in the label stack when received on an intermediate node of the associated path, but it can be the top label in the label stack on the penultimate node.
PSIDを使用すると、PSIDをイングレスノードに挿入し、SRパスの最後のラベルをすぐに追跡する必要があります。言い換えれば、SRパスの出口ノードを指しているルーティングセグメント（隣接、ノード、またはプレフィックスセグメント）の後に挿入する必要があります。したがって、PSIDは、関連するパスの中間ノードで受信した場合、ラベルスタックのトップレーベルではありませんが、最後から2番目のノードのラベルスタックのトップラベルになります。
The value of the TTL field in the MPLS label stack entry containing a PSID can be set to any value except 0. If a PSID is the bottom label, the S bit MUST be set, and if the PSID is NOT the bottom label, the S bit MUST be 0.
PSIDを含むMPLSラベルスタックエントリのTTLフィールドの値は、0以外の任意の値に設定できます。PSIDがボトムラベルである場合、Sビットを設定する必要があります。sビットは0でなければなりません。
The egress node MUST pop the PSID. The egress node MAY use the PSID for further processing. For example, when performance measurement is enabled on the SR path, it can trigger packet counting or timestamping.
出力ノードはPSIDをポップする必要があります。出力ノードは、さらに処理するためにPSIDを使用する場合があります。たとえば、SRパスでパフォーマンス測定が有効になっている場合、パケットカウントまたはタイムスタンプをトリガーできます。
The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing. This additional processing may have an impact on forwarding performance. Behavior relating to the use of explicit null directly preceding the PSID is undefined in this document.
PSIDを追加するには、通常の処理に加えてPSIDラベルを読み取り、処理するために出口が必要です。この追加の処理は、転送パフォーマンスに影響を与える可能性があります。このドキュメントでは、PSIDの直前の明示的なヌルの使用に関する動作は未定義です。
A Generic Associated Channel Label (GAL) MAY be used for Operations, Administration, and Maintenance (OAM) in MPLS networks. As per [RFC5586], when a GAL is used, the Associated Channel Header (ACH) appears immediately after the bottom of the label stack.
Generic Associated Channel Label（GAL）は、MPLSネットワークの運用、管理、およびメンテナンス（OAM）に使用できます。[RFC5586]に従って、GALを使用すると、関連するチャネルヘッダー（ACH）がラベルスタックの下部の直後に表示されます。
The SR path computation needs to know the Maximum SID Depth (MSD) that can be imposed at the ingress node of a given SR path [RFC8664]. This ensures that the SID stack depth of a computed path does not exceed the number of SIDs the node is capable of imposing. As per [RFC8491], the MSD signals the total number of MPLS labels that can be imposed, where the total number of MPLS labels includes the PSID.
SRパス計算では、特定のSRパス[RFC8664]の侵入ノードに課すことができる最大SID深度（MSD）を知る必要があります。これにより、計算されたパスのSIDスタックの深さが、ノードが課すことができるSIDSの数を超えないようにします。[RFC8491]によると、MSDは、MPLSラベルの総数にPSIDが含まれる場合、課すことができるMPLSラベルの総数を信号します。
An example label stack with a PSID is shown in Figure 1:
PSIDを使用したラベルスタックの例を図1に示します。
+--------------------+
| ... |
+--------------------+
| Label 1 |
+--------------------+
| Label 2 |
+--------------------+
| ... |
+--------------------+
| Label n |
+--------------------+
| PSID |
+--------------------+
~ Payload ~
+--------------------+
Figure 1: Label Stack with a PSID
図1：PSIDでスタックをラベル付けします
Where:
ただし：
* The Labels 1 to n are the segment label stack used to direct how to steer the packets along the SR path.
* ラベル1からNは、SRパスに沿ってパケットを操縦する方法を指示するために使用されるセグメントラベルスタックです。
* The PSID identifies the SR path in the context of the egress node of the SR path.
* PSIDは、SRパスの出口ノードのコンテキストでSRパスを識別します。
The signaling of the PSID between the egress node, the ingress node, and possibly a centralized controller is out of the scope of this document.
出口ノード、イングレスノード、場合によっては集中コントローラー間のPSIDの信号は、このドキュメントの範囲外です。
If an Entropy Label (EL) is also used on the egress node, as per [RFC6790], the EL and Entropy Label Indicator (ELI) would be placed before the tunnel label; hence, they do not interfere with the PSID, which is placed below.
[RFC6790]に従って、Egressノードでもエントロピーラベル（EL）が使用されている場合、ELおよびエントロピーラベルインジケーター（EL）がトンネルラベルの前に配置されます。したがって、それらは下に配置されているPSIDを妨害しません。
It is worthy to note that in the case of ECMP, with or without the use of an EL, the SR packets may be forwarded over multiple paths. In this case, the SID list cannot directly reflect the actual forwarding path and the PSID can only identify the SID list rather than the actual forwarding path.
ECMPの場合、ELの使用の有無にかかわらず、SRパケットは複数のパスに転送される可能性があることに注意する価値があります。この場合、SIDリストは実際の転送パスを直接反映することができず、PSIDは実際の転送パスではなくSIDリストのみを識別できます。
Also, similar to a Synonymous Flow Label (SFL) [RFC8957], the introduction of a PSID to an existing flow may cause that flow to take a different path through the network under the conditions of ECMP. In turn, this may invalidate certain uses of the PSID, such as performance measurement applications. Therefore, the considerations of SFLs as per Section 5 of [RFC8957] also apply to PSIDs in implementation.
また、同義のフローラベル（SFL）[RFC8957]と同様に、既存のフローにPSIDを導入すると、ECMPの条件下でその流れがネットワークを介して異なる経路をとることがあります。次に、パフォーマンス測定アプリケーションなど、PSIDの特定の使用を無効にする可能性があります。したがって、[RFC8957]のセクション5に従ってSFLSの考慮事項も、実装中のPSIDにも適用されます。
This section describes use cases that can leverage the PSID. The content is for informative purposes, and the detailed solutions might be defined in other documents in the future.
このセクションでは、PSIDを活用できるユースケースについて説明します。コンテンツは有益な目的であり、詳細なソリューションは将来の他のドキュメントで定義される可能性があります。
As defined in [RFC7799], performance measurement can be classified into Passive, Active, and Hybrid measurements. Since a PSID is encoded in the SR-MPLS label stack, as shown in Figure 1, existing implementations on the egress node can leverage a PSID for measuring packet counts.
[RFC7799]で定義されているように、パフォーマンス測定はパッシブ、アクティブ、およびハイブリッド測定に分類できます。図1に示すように、PSIDはSR-MPLSラベルスタックにエンコードされているため、Egressノードの既存の実装は、パケット数を測定するためにPSIDを活用できます。
For Passive performance measurement, path identification at the measuring points is the prerequisite. A PSID can be used by the measuring points (e.g., the ingress and egress nodes of the SR path or a centralized controller) to correlate the packet counts and timestamps from the ingress and egress nodes for a specific SR path; then, packet loss and delay can be calculated for the end-to-end path, respectively.
パッシブパフォーマンス測定の場合、測定点でのパス識別が前提条件です。PSIDは、特定のSRパスのイングレスノードと出口ノードからのパケット数とタイムスタンプを相関させるために、測定ポイント（たとえば、SRパスまたは集中コントローラーのイングレスノードと出力ノードなど）で使用できます。次に、パケットの損失と遅延をそれぞれエンドツーエンドパスで計算できます。
Furthermore, a PSID can also be used for:
さらに、PSIDは以下にも使用できます。
* Active performance measurement for an SR path in SR-MPLS networks for collecting packet counters and timestamps from the egress node using probe messages.
* プローブメッセージを使用して、出力ノードからパケットカウンターとタイムスタンプを収集するためのSR-MPLSネットワークのSRパスのアクティブパフォーマンス測定。
* In situ OAM [RFC9197] for SR-MPLS to identify the SR path associated with the in situ data fields in the data packets on the egress node.
* SR-MPLS用のin situ OAM [RFC9197]は、出口ノードのデータパケットのIN in situデータフィールドに関連付けられたSRパスを識別します。
* In-band performance measurement for SR-MPLS to identify the SR path associated with the collected performance metrics.
* 収集されたパフォーマンスメトリックに関連付けられたSRパスを識別するためのSR-MPLSのインバンドパフォーマンス測定。
In some scenarios (e.g., mobile backhaul transport networks), there are requirements to support bidirectional paths [RFC6965], and the path is normally treated as a single entity. Forward and reverse directions of the path have the same fate; for example, failure in one direction will result in switching traffic at both directions. MPLS supports this by introducing the concepts of a co-routed bidirectional Label Switched Path (LSP) and an associated bidirectional LSP [RFC5654].
一部のシナリオ（モバイルバックホール輸送ネットワークなど）では、双方向パス[RFC6965]をサポートする要件があり、パスは通常単一のエンティティとして扱われます。パスの前方と逆方向は同じ運命を持っています。たとえば、一方向に故障すると、両方方向にトラフィックが切り替わります。MPLSは、共同双方向ラベルスイッチドパス（LSP）と関連する双方向LSP [RFC5654]の概念を導入することにより、これをサポートします。
In the current SR architecture, an SR path is a unidirectional path [RFC8402]. In order to support bidirectional SR paths, a straightforward way is to bind two unidirectional SR paths to a single bidirectional SR path. PSIDs can be used to identify and correlate the traffic for the two unidirectional SR paths at both ends of the bidirectional path.
現在のSRアーキテクチャでは、SRパスは単方向パスです[RFC8402]。双方向SRパスをサポートするために、簡単な方法は、2つの単方向SRパスを単一の双方向SRパスに結合することです。PSIDを使用して、双方向パスの両端にある2つの単方向SRパスのトラフィックを識別および相関させることができます。
The mechanism of constructing bidirectional paths using a PSID is out of the scope of this document and has been described in several documents, such as [BIDIR-PATH] and [SR-EXTENSIONS].
PSIDを使用して双方向経路を構築するメカニズムは、このドキュメントの範囲外であり、[Bidir-Path]や[SR-Extensions]などのいくつかのドキュメントで説明されています。
For end-to-end 1+1 path protection (i.e., a Live-Live case), the egress node of the path needs to know the set of paths that constitute the primary and the secondaries in order to select the primary path packets for onward transmission and to discard the packets from the secondaries [RFC4426].
エンドツーエンドの1 1パス保護（つまり、ライブケース）の場合、パスの出口ノードは、プライマリとセカンテリーを構成するパスのセットを知るために、以降のプライマリパスパケットを選択する必要があります。送信および第二次[RFC4426]からパケットを廃棄する。
To do this in SR, each SR path needs a path identifier that is unique at the egress node. For SR-MPLS, this can be the Path Segment label allocated by the egress node.
これをSRで行うには、各SRパスには出口ノードで一意のパス識別子が必要です。SR-MPLSの場合、これは出力ノードによって割り当てられたパスセグメントラベルにすることができます。
The detailed solution of using a PSID in end-to-end 1+1 path protection is out of the scope of this document.
エンドツーエンド1 1パス保護でPSIDを使用する詳細なソリューションは、このドキュメントの範囲外です。
A Binding SID (BSID) [RFC8402] can be used for SID list compression. With a BSID, an end-to-end SR path in a trusted domain can be split into several sub-paths, where each sub-path is identified by a BSID. Then, an end-to-end SR path can be identified by a list of BSIDs; therefore, it can provide better scalability.
結合SID（BSID）[RFC8402]は、SIDリスト圧縮に使用できます。BSIDを使用すると、信頼できるドメイン内のエンドツーエンドのSRパスをいくつかのサブパスに分割でき、各サブパスはBSIDによって識別されます。次に、BSIDSのリストでエンドツーエンドのSRパスを識別できます。したがって、より良いスケーラビリティを提供できます。
A BSID and a PSID can be combined to achieve both sub-path and end-to-end path monitoring. A reference model for such a combination (Figure 2) shows an end-to-end path (A->D) in a trusted domain that spans three subdomains (the Access, Aggregation, and Core domains) and consists of three sub-paths, one in each subdomain (sub-path (A->B), sub-path (B->C), and sub-path (C->D)).
BSIDとPSIDを組み合わせて、サブパスとエンドツーエンドのパスモニタリングの両方を実現できます。このような組み合わせの参照モデル（図2）は、3つのサブドメイン（アクセス、集約、およびコアドメイン）に及ぶ信頼できるドメインのエンドツーエンドパス（a-> d）を示し、3つのサブパスで構成されています。、各サブドメイン（サブパス（a-> b）、サブパス（b-> c）、およびサブパス（c-> d））に1つ。
The SID list of a sub-path can be expressed as <SID1, SID2, ..., SIDn, s-PSID>, where the s-PSID is the PSID of the sub-path. Each sub-path is associated with a BSID and an s-PSID.
サブパスのSIDリストは、<SID1、SID2、...、SIDN、S-PSID>として表現できます。ここで、S-PSIDはサブパスのPSIDです。各サブパスは、BSIDとS-PSIDに関連付けられています。
The SID list of the end-to-end path can be expressed as <BSID1, BSID2, ..., BSIDn, e-PSID>, where the e-PSID is the PSID of the end-to-end path.
エンドツーエンドパスのSIDリストは、<bsid1、bsid2、...、bsidn、e-psid>として表現できます。ここで、e-psidはエンドツーエンドパスのpsidです。
Figure 2 shows the details of the label stacks when a PSID and a BSID are used to support both sub-path and end-to-end path monitoring in a multi-domain scenario.
図2は、PSIDとBSIDがマルチドメインシナリオでサブパスとエンドツーエンドのパスモニタリングの両方をサポートするために使用される場合のラベルスタックの詳細を示しています。
/--------\ /--------\ /--------\
/ \ / \ / \
A{ Access }B{ Aggregation }C{ Core }D
\ / \ / \ /
\--------/ \--------/ \--------/
sub-path(A->B) sub-path(B->C) sub-path(C->D)
|<--------------->|<-------------->|<-------------->|
E2E Path(A->D)
|<------------------------------------------------->|
+-------------+
~A->B sub-path~
+-------------+ +-------------+
|s-PSID(A->B) | ~B->C sub-path~
+-------------+ +-------------+ +-------------+
| BSID(B->C) | |s-PSID(B->C) | ~C->D sub-path~
+-------------+ +-------------+ +-------------+
| BSID(C->D) | | BSID(C->D) | |s-PSID(C->D) |
+-------------+ +-------------+ +-------------+ +------------+
|e-PSID(A->D) | |e-PSID(A->D) | |e-PSID(A->D) | |e-PSID(A->D)|
+-------------+ +-------------+ +-------------+ +------------+
Figure 2: Nesting of PSIDs
図2：PSIDのネスト
A PSID in SR-MPLS is a local label similar to other labels and segments, such as a VPN label, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node or an egress node, which follows the same logic of an existing MPLS data plane. As per the definition of a PSID, only the egress node and the ingress node of the associated path will learn the information of a PSID. The intermediate nodes of this path will not learn it.
SR-MPLSのPSIDは、MPLSおよびSR-MPLSで定義されているVPNラベルなど、他のラベルやセグメントに似たローカルラベルです。PSIDのデータプレーン処理は、既存のMPLSデータプレーンの同じロジックに従う侵入ノードまたは出力ノードのローカル実装です。PSIDの定義に従って、関連するパスの出口ノードとイングレスノードのみがPSIDの情報を学習します。このパスの中間ノードはそれを学習しません。
A PSID may be used on an ingress node that is not the ingress of the associated path if the associated label stack with the PSID is part of a deeper label stack that represents a longer path. For example, the case described in Section 3.4 and the related BSID are not used while the original label stack of a sub-path is inserted as a part of the whole label stack. In this case, the PSID must be distributed in a trusted domain under the considerations defined in Section 8.1 of [RFC8402].
PSIDは、関連するラベルスタックがPSIDにある場合、関連するパスの侵入ではない侵入ノードで使用できます。たとえば、セクション3.4と関連するBSIDで説明されているケースは使用されませんが、サブパスの元のラベルスタックはラベルスタック全体の一部として挿入されます。この場合、[RFC8402]のセクション8.1で定義されている考慮事項の下で、PSIDは信頼できるドメインに分布する必要があります。
A PSID is used within an SR-MPLS trusted domain [RFC8402] and must not leak outside the domain; therefore, no new security threats are introduced compared to current SR-MPLS. As per [RFC8402], SR domain boundary routers MUST filter any external traffic destined to a label associated with a segment within the trusted domain; this applies to a PSID as well. Other security considerations of SR-MPLS described in Section 8.1 of [RFC8402] apply to this document.
PSIDは、SR-MPLS信頼できるドメイン[RFC8402]内で使用され、ドメインの外側に漏れてはなりません。したがって、現在のSR-MPLと比較して、新しいセキュリティの脅威は導入されていません。[RFC8402]によると、SRドメイン境界ルーターは、信頼できるドメイン内のセグメントに関連付けられたラベルに運命づけられている外部トラフィックをフィルタリングする必要があります。これはPSIDにも当てはまります。[RFC8402]のセクション8.1で説明されているSR-MPLのその他のセキュリティ上の考慮事項は、このドキュメントに適用されます。
The distribution of a PSID from an egress node to an ingress node is performed within an SR-trusted domain, and it is out of the scope of this document. The details of the mechanism and related security considerations will be described in other documents.
出口ノードからイングレスノードへのPSIDの分布は、SRに信頼されたドメイン内で実行され、このドキュメントの範囲外です。メカニズムと関連するセキュリティ上の考慮事項の詳細については、他のドキュメントで説明されています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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>.
[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>.
[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>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[BIDIR-PATH]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing
(SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
pce-sr-bidir-path-13, 13 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
bidir-path-13>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426,
DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/info/rfc4426>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC6965] Fang, L., Ed., Bitar, N., Zhang, R., Daikoku, M., and P.
Pan, "MPLS Transport Profile (MPLS-TP) Applicability: Use
Cases and Design", RFC 6965, DOI 10.17487/RFC6965, August
2013, <https://www.rfc-editor.org/info/rfc6965>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[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>.
[RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G.
Mirsky, "Synonymous Flow Label Framework", RFC 8957,
DOI 10.17487/RFC8957, January 2021,
<https://www.rfc-editor.org/info/rfc8957>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[SR-EXTENSIONS]
Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR
Policy Extensions for Path Segment and Bidirectional
Path", Work in Progress, Internet-Draft, draft-ietf-idr-
sr-policy-path-segment-09, 19 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-path-segment-09>.
The authors would like to thank Adrian Farrel, Stewart Bryant, Shuangping Zhan, Alexander Vainshtein, Andrew G. Malis, Ketan Talaulikar, Shraddha Hegde, Xinyue Zhang, Loa Andersson, and Bruno Decraene for their review, suggestions, comments, and contributions to this document.
著者は、エイドリアン・ファレル、スチュワート・ブライアント、シュアンピン・ザン、アレクサンダー・ヴァインシュタイン、アンドリュー・G・マリス、ケタン・タラウリカル、シュラダ・ヘグデ、XINYUE ZHANG、ロア・アンダーソン、ブルーノ・デクラエン、レビュー、提案、コメント、コメント、このコメント、これに貢献することに感謝したいと思います。書類。
The authors would like to acknowledge the contribution from Alexander Vainshtein on "Nesting of PSIDs" (Section 3.4).
著者は、「PSIDのネスト」に関するアレクサンダー・ヴァインシュタインからの貢献を認めたいと考えています（セクション3.4）。
The following people have substantially contributed to this document.
次の人々がこの文書に実質的に貢献しています。
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd.
Email: mach.chen@huawei.com
Lei Wang
China Mobile
Email: wangleiyj@chinamobile.com
Aihua Liu
ZTE Corp.
Email: liu.aihua@zte.com.cn
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Gyan S. Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Weiqiang Cheng (editor)
China Mobile
Email: chengweiqiang@chinamobile.com
Han Li
China Mobile
Email: lihan@chinamobile.com
Cheng Li (editor)
Huawei Technologies
China
Email: c.l@huawei.com
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Royi Zigler
Broadcom
Email: royi.zigler@broadcom.com