Internet Engineering Task Force (IETF) S. Hegde
Request for Comments: 9703 M. Srivastava
Category: Standards Track Juniper Networks Inc.
ISSN: 2070-1721 K. Arora
Individual Contributor
S. Ninan
Ciena
X. Xu
China Mobile
December 2024
Egress Peer Engineering (EPE) is an application of Segment Routing (SR) that solves the problem of egress peer selection. The SR-based BGP-EPE solution allows a centralized controller, e.g., a Software-Defined Network (SDN) controller, to program any egress peer. The EPE solution requires the node or the SDN controller to program 1) the PeerNode Segment Identifier (SID) describing a session between two nodes, 2) the PeerAdj SID describing the link or links that are used by the sessions between peer nodes, and 3) the PeerSet SID describing any connected interface to any peer in the related group. This document provides new sub-TLVs for EPE-SIDs that are used in the Target FEC Stack TLV (Type 1) in MPLS Ping and Traceroute procedures.
Egress Peer Engineering（EPE）は、出力ピア選択の問題を解決するセグメントルーティング（SR）のアプリケーションです。SRベースのBGP-EPEソリューションにより、中央コントローラー（たとえば、ソフトウェア定義ネットワーク（SDN）コントローラーが任意の出力ピアをプログラムできます。EPEソリューションでは、ノードまたはSDNコントローラーがプログラムに必要です1）2つのノード間のセッションを説明するPeernodeセグメント識別子（SID）、2）PeerAdj SIDは、Peerノード間のセッションで使用されるリンクまたはリンク、および3つのリンクを説明します。）関連グループのピアへの接続されたインターフェイスを説明するピアセットSID。このドキュメントは、MPLS PingおよびTraceroute手順でターゲットFECスタックTLV（タイプ1）で使用されるEPE-SIDの新しいサブTLVを提供します。
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/rfc9703.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9703で取得できます。
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
2. Theory of Operation
3. Requirements Language
4. FEC Definitions
4.1. PeerNode SID Sub-TLV
4.2. PeerAdj SID Sub-TLV
4.3. PeerSet SID Sub-TLV
5. EPE-SID FEC Validation
5.1. EPE-SID FEC Validation Rules
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Examples of Programmed States
Acknowledgments
Authors' Addresses
Egress Peer Engineering (EPE), as defined in [RFC9087], is an effective mechanism that is used to select the egress peer link based on different criteria. In this scenario, egress peers may belong to a completely different ownership. The EPE-SIDs provide the means to represent egress peer nodes, links, sets of links, and sets of nodes. Many network deployments have built their networks consisting of multiple Autonomous Systems (ASes) either for the ease of operations or as a result of network mergers and acquisitions. The inter-AS links connecting any two ASes could be traffic-engineered using EPE-SIDs in this case, where there is single ownership but different AS numbers. It is important to validate the control plane to forwarding plane synchronization for these SIDs so that any anomaly can be easily detected by the network operator. EPE-SIDs may also be used in an ingress Segment Routing (SR) policy [RFC9256] to choose exit points where the remote AS has a completely different ownership. This scenario is out of scope for this document.
[RFC9087]で定義されている出力ピアエンジニアリング（EPE）は、異なる基準に基づいて出口ピアリンクを選択するために使用される効果的なメカニズムです。このシナリオでは、出口のピアはまったく異なる所有権に属している可能性があります。EPE-SIDは、出力ピアノード、リンク、リンクのセット、およびノードのセットを表す手段を提供します。多くのネットワーク展開は、運用の容易さまたはネットワーク合併と買収の結果として、複数の自律システム（ASE）で構成されるネットワークを構築しています。2つのASEを接続するAS Inter-ASリンクは、この場合にEPE-SIDSを使用してトラフィックエンジニアリングを行うことができます。これらのSIDの転送面の同期に制御面を検証して、ネットワーク演算子が異常を簡単に検出できるようにすることが重要です。EPE-SIDSは、Ingressセグメントルーティング（SR）ポリシー[RFC9256]で、リモートがまったく異なる所有権を持つ出口ポイントを選択することもできます。このシナリオは、このドキュメントの範囲外です。
+---------+ +------+
| | | |
| H B------D G
| | +---/| AS2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K
| | +===F AS3 |
+---------+ +------+
Figure 1: Reference Diagram
図1：参照図
In Figure 1, EPE-SIDs are configured on AS1 towards AS2 and AS3 and advertised in the Border Gateway Protocol - Link State (BGP-LS) [RFC9086]. In certain cases, the EPE-SIDs advertised by the control plane may not be in synchronization with the label programmed in the data plane. For example, on C, a PeerAdj SID could be advertised to indicate it is for the link C->D. Due to some software anomaly, the actual data forwarding on this PeerAdj SID could be happening over the C->E link. If E had relevant data paths for further forwarding the packet, this kind of anomaly would go unnoticed by the network operator. A detailed example of a correctly programmed state and an incorrectly programmed state along with a description of how the incorrect state can be detected is described in Appendix A. A Forwarding Equivalence Class (FEC) definition for the EPE-SIDs will detail the control plane association of the SID. The data plane validation of the SID will be done during the MPLS Traceroute procedure. When there is a multi-hop External BGP (EBGP) session between the ASBRs, a PeerNode SID is advertised, and the traffic MAY be load-balanced between the interfaces connecting the two nodes. In Figure 1, C and F could have a PeerNode SID advertised. When the Operations, Administration, and Maintenance (OAM) packet is received on F, it needs to be validated that the packet came from one of the two interfaces connected to C.
図1では、EPE-SIDはAS1でAS2およびAS3に向かって構成され、Border Gateway Protocol-Link State（BGP-LS）[RFC9086]で宣伝されています。特定の場合、コントロールプレーンによって宣伝されているEPE-SIDは、データプレーンでプログラムされたラベルと同期していない場合があります。たとえば、Cでは、リンクC-> D用であることを示すために、PeerAdj SIDを宣伝できます。一部のソフトウェアの異常により、このPeerAdj SIDの実際のデータ転送は、C-> eリンクを介して発生する可能性があります。Eがパケットをさらに転送するための関連するデータパスを持っていた場合、この種の異常はネットワーク演算子に気付かれなくなります。正しくプログラムされた状態と誤ったプログラムされた状態の詳細な例と、誤った状態を検出する方法の説明については、付録Aで説明します。EPE-SIDの転送等価クラス（FEC）定義では、コントロールプレーンの関連付けについて詳しく説明します。SIDの。SIDのデータプレーン検証は、MPLS Traceroute手順中に行われます。ASBRS間にマルチホップ外部BGP（EBGP）セッションがある場合、Peernode SIDが宣伝され、2つのノードを接続するインターフェイス間にトラフィックが負荷になります。図1では、CとFにPeernode SIDが宣伝される可能性があります。操作、管理、およびメンテナンス（OAM）パケットがFで受信される場合、パケットがCに接続された2つのインターフェイスのいずれかから来たことを検証する必要があります。
This document provides Target Forwarding Equivalence Class (FEC) Stack TLV definitions for EPE-SIDs. This solution requires the node constructing the Target FEC Stack TLV to determine the types of SIDs along the path of the LSP. Other procedures for MPLS Ping and Traceroute, as defined in Section 7 of [RFC8287] and clarified in [RFC8690], are applicable for EPE-SIDs as well.
このドキュメントは、EPE-SIDのターゲット転送等価クラス（FEC）スタックTLV定義を提供します。このソリューションでは、LSPの経路に沿ったSIDのタイプを決定するために、ターゲットFECスタックTLVを構築するノードが必要です。[RFC8287]のセクション7で定義され、[RFC8690]で明確にされているMPLS PingおよびTracerouteのその他の手順は、EPE-SIDにも適用できます。
[RFC9086] provides mechanisms to advertise the EPE-SIDs in BGP-LS. These EPE-SIDs may be used to build SR paths and may be communicated using extensions described in [SR-SEGTYPES] and [SR-BGP-POLICY] or Path Computation Element Protocol (PCEP) extensions as defined in [RFC8664]. Data plane monitoring for such paths that consist of EPE-SIDs will use extensions defined in this document to build the Target FEC Stack TLV. The MPLS Ping and Traceroute procedures MAY be initiated by the head-end of the SR path or a centralized topology-aware data plane monitoring system, as described in [RFC8403]. The extensions in [SR-SEGTYPES], [SR-BGP-POLICY], and [RFC8664] do not define how to acquire and carry the details of the SID that can be used to construct the FEC. Such extensions are out of scope for this document. The node initiating the data plane monitoring may acquire the details of EPE-SIDs through BGP-LS advertisements, as described in [RFC9086]. There may be other possible mechanisms that can be used to learn the definition of the SID from the controller. Details of such mechanisms are out of scope for this document.
[RFC9086]は、BGP-LSでEPE-SIDを宣伝するメカニズムを提供します。これらのEPE-SIDは、SRパスの構築に使用される場合があり、[sr-segtypes]および[sr-bgp-policy]またはパス計算要素プロトコル（PCEP）拡張で[RFC8664]で定義されている拡張機能を使用して通信できます。EPE-SIDで構成されるそのようなパスのデータプレーン監視は、このドキュメントで定義された拡張機能を使用して、ターゲットFECスタックTLVを構築します。[RFC8403]に記載されているように、MPLS PingおよびTraceroute手順は、SRパスのヘッドエンドまたは集中トポロジ認識データプレーン監視システムによって開始される場合があります。[sr-segtypes]、[sr-bgp-policy]、および[rfc8664]の拡張機能は、FECの構築に使用できるSIDの詳細を取得および運ぶ方法を定義しません。このような拡張機能は、このドキュメントの範囲外です。[RFC9086]で説明されているように、データプレーンの監視を開始するノードは、BGP-LS広告を介してEPE-SIDの詳細を取得する場合があります。コントローラーからSIDの定義を学習するために使用できる他の可能なメカニズムがあるかもしれません。このようなメカニズムの詳細は、このドキュメントの範囲外です。
The EPE-SIDs are advertised for inter-AS links that run EBGP sessions. [RFC9086] does not define the detailed procedures of how to operate EBGP sessions in a scenario with unnumbered interfaces. Therefore, these scenarios are out of scope for this document. Anycast and multicast addresses are not in the scope of this document. During the AS migration scenario, procedures described in [RFC7705] may be in force. In these scenarios, if the local and remote AS fields in the FEC (as described in Section 4) carry the globally configured AS Number and not the "local AS" (as defined in [RFC7705]), then the FEC validation procedures may fail.
EPE-SIDは、EBGPセッションを実行するリンクとして宣伝されています。[RFC9086]は、本格的なインターフェイスを備えたシナリオでEBGPセッションを操作する方法の詳細な手順を定義していません。したがって、これらのシナリオはこのドキュメントの範囲外です。Anycastおよびマルチキャストアドレスは、このドキュメントの範囲内ではありません。AS移行シナリオ中に、[RFC7705]で説明されている手順が有効になる可能性があります。これらのシナリオでは、FECのフィールドとしてのローカルおよびリモート（セクション4で説明）が「[RFC7705]で定義されているように）ではなく、グローバルに構成された数字として、「ローカル」ではなく数として構成されている場合、FEC検証手順が失敗する場合があります。。
As described in Section 1, this document defines Target FEC Stack TLVs for EPE-SIDs that can be used in detecting MPLS data plane failures [RFC8029]. This mechanism applies to paths created across ASes of cooperating administrations. If the ping or traceroute packet enters a non-cooperating AS domain, it might be dropped by the routers in the non-cooperating domain. Although a complete path validation cannot be done across non-cooperating domains, it still provides useful information that the ping or traceroute packet entered a non-cooperating domain.
セクション1で説明されているように、このドキュメントでは、MPLSデータプレーンの障害の検出に使用できるEPE-SIDのターゲットFECスタックTLVを定義します[RFC8029]。このメカニズムは、協力行政のASESを越えて作成されたパスに適用されます。pingまたはtracerouteパケットがドメインとして非協力的なドメインに入ると、非協力ドメインのルーターによってドロップされる可能性があります。完全なパス検証は、非協力ドメインで実行することはできませんが、PingまたはTracerouteパケットが非協力ドメインに入力したという有用な情報を提供します。
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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14、[RFC2119]、[RFC8174]で説明されているように解釈されます。
In this document, three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path TLV (Type 21); see Table 1.
このドキュメントでは、ターゲットFECスタックTLV（タイプ1）、リバースパスターゲットFECスタックTLV（タイプ16）、および応答パスTLV（タイプ21）に対して3つの新しいサブTLVが定義されています。表1を参照してください。
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 = 39 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PeerNode SID Sub-TLV
図2：Peernode Sid sub-tlv
Type:
タイプ：
2 octets
2オクテット
Value:
値：
39
39
Length:
長さ：
2 octets
2オクテット
Value:
値：
16
16
Local AS Number:
ローカルAS番号：
4 octets. The unsigned integer representing the AS number [RFC6793] of the AS to which the PeerNode SID advertising node belongs. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。Peernode SID Advertising Nodeが属するAS番号[RFC6793]を表す署名されていない整数。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Remote AS Number:
数字としてリモート：
4 octets. The unsigned integer representing the AS number [RFC6793] of the AS of the remote node for which the PeerNode SID is advertised. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。Peernode SIDが宣伝されているリモートノードのAS番号[RFC6793]を表す署名されていない整数。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Local BGP Router ID:
ローカルBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the PeerNode SID advertising node as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているPeernode SID広告ノードのBGP識別子を表す署名されていない整数。
Remote BGP Router ID:
リモートBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the remote node as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているリモートノードのBGP識別子を表す署名されていない整数。
When there is a multi-hop EBGP session between two ASBRs, a PeerNode SID is advertised for this session, and traffic can be load-balanced across these interfaces. An EPE controller that performs bandwidth management for these links should be aware of the links on which the traffic will be load-balanced. As per [RFC8029], the node advertising the EPE-SIDs will send a Downstream Detailed Mapping (DDMAP) TLV specifying the details of the next-hop interfaces. Based on this information, the controller MAY choose to verify the actual forwarding state with the topology information that the controller has. On the router, the validation procedures will include the received DDMAP validation, as specified in [RFC8029], to verify the control state and the forwarding state synchronization on the two routers. Any discrepancies between the controller's state and the forwarding state will not be detected by the procedures described in this document.
2つのASBRの間にマルチホップEBGPセッションがある場合、このセッションのためにPeernode SIDが宣伝され、これらのインターフェイス全体でトラフィックをロードバランスさせることができます。これらのリンクの帯域幅管理を実行するEPEコントローラーは、トラフィックが負荷バランスが取られるリンクを認識する必要があります。[RFC8029]によると、EPE-SIDSを宣伝するノードは、次のホップインターフェイスの詳細を指定する下流の詳細マッピング（DDMAP）TLVを送信します。この情報に基づいて、コントローラーは、コントローラーが持っているトポロジ情報を使用して実際の転送状態を検証することを選択できます。ルーターでは、検証手順には、[RFC8029]で指定された受信DDMAP検証が含まれ、2つのルーターのコントロール状態と転送状態の同期を検証します。コントローラーの状態と転送状態の間の矛盾は、このドキュメントで説明されている手順によって検出されません。
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 = 38 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PeerAdj SID Sub-TLV
図3：PeerAdj Sid Sub-TLV
Type:
タイプ：
2 octets
2オクテット
Value:
値：
38
38
Length:
長さ：
2 octets
2オクテット
Value:
値：
Variable based on the IPv4/IPv6 interface address. Length excludes the length of the Type and Length fields. For IPv4 interface addresses, the length will be 28 octets. In the case of an IPv6 address, the length will be 52 octets.
IPv4/IPv6インターフェイスアドレスに基づく変数。長さは、タイプフィールドと長さフィールドの長さを除外します。IPv4インターフェイスアドレスの場合、長さは28オクテットになります。IPv6アドレスの場合、長さは52オクテットになります。
Adj type:
adjタイプ：
1 octet
1オクテット
Value:
値：
Set to 1 when the Adjacency Segment is IPv4. Set to 2 when the Adjacency Segment is IPv6.
隣接セグメントがIPv4である場合、1に設定します。隣接セグメントがIPv6の場合、2に設定します。
RESERVED:
予約済み：
3 octets. MUST be zero when sending and ignored on receiving.
3オクテット。送信中はゼロでなければなりません。
Local AS Number:
ローカルAS番号：
4 octets. The unsigned integer representing the AS number [RFC6793] of the AS to which the PeerAdj SID advertising node belongs. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。PeerAdj SID広告ノードが属するAS番号[RFC6793]を表す署名されていない整数。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Remote AS Number:
数字としてリモート：
4 octets. The unsigned integer representing the AS number [RFC6793] of the remote node's AS for which the PeerAdj SID is advertised. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。PeerAdj SIDが宣伝されているリモートノードのAS番号[RFC6793]を表す署名されていない整数。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Local BGP Router ID:
ローカルBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the PeerAdj SID advertising node as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているPeerADJ SID広告ノードのBGP識別子を表す署名されていない整数。
Remote BGP Router ID:
リモートBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the remote node as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているリモートノードのBGP識別子を表す署名されていない整数。
Local Interface Address:
ローカルインターフェイスアドレス：
4 octets or 16 octets. In the case of PeerAdj SID, the local interface address corresponding to the PeerAdj SID should be specified in this field. For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. Link-local IPv6 addresses are not in the scope of this document.
4オクテットまたは16オクテット。PeerAdj SIDの場合、PeerADJ SIDに対応するローカルインターフェイスアドレスをこのフィールドで指定する必要があります。IPv4の場合、このフィールドは4オクテットです。IPv6の場合、このフィールドは16オクテットです。Link-Local IPv6アドレスは、このドキュメントの範囲内にありません。
Remote Interface Address:
リモートインターフェイスアドレス：
4 octets or 16 octets. In the case of PeerAdj SID, the remote interface address corresponding to the PeerAdj SID should be specified in this field. For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. Link-local IPv6 addresses are not in the scope of this document.
4オクテットまたは16オクテット。PeerAdj SIDの場合、PeerADJ SIDに対応するリモートインターフェイスアドレスをこのフィールドで指定する必要があります。IPv4の場合、このフィールドは4オクテットです。IPv6の場合、このフィールドは16オクテットです。Link-Local IPv6アドレスは、このドキュメントの範囲内にありません。
[RFC9086] mandates sending a local interface ID and remote interface ID in the link descriptors and allows a value of 0 in the remote descriptors. It is useful to validate the incoming interface for an OAM packet, but if the remote descriptor is 0, this validation is not possible. Optional link descriptors of local and remote interface addresses are allowed as described in Section 4.2 of [RFC9086]. In this document, it is RECOMMENDED to send these optional descriptors and use them to validate incoming interfaces. When these local and remote interface addresses are not available, an ingress node can send 0 in the local and/or remote interface address field. The receiver SHOULD skip the validation for the incoming interface if the address field contains 0.
[RFC9086]は、リンク記述子にローカルインターフェイスIDとリモートインターフェイスIDを送信することを義務付け、リモート記述子に0の値を許可します。OAMパケットの着信インターフェイスを検証すると便利ですが、リモート記述子が0の場合、この検証は不可能です。[RFC9086]のセクション4.2で説明されているように、ローカルおよびリモートインターフェイスアドレスのオプションのリンク記述子は許可されます。このドキュメントでは、これらのオプションの記述子を送信し、それらを使用して着信インターフェイスを検証することをお勧めします。これらのローカルおよびリモートインターフェイスアドレスが使用できない場合、イングレスノードはローカルおよび/またはリモートインターフェイスアドレスフィールドに0を送信できます。アドレスフィールドに0が含まれている場合、受信機は、着信インターフェイスの検証をスキップする必要があります。
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 = 40 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of elements in set | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
One element in set consists of the details below
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Figure 4: PeerSet SID Sub-TLV
図4：Peerset Sid Sub-TLV
Type:
タイプ：
2 octets
2オクテット
Value:
値：
40
40
Length:
長さ：
2 octets
2オクテット
Value:
値：
Expressed in octets and is a variable based on the number of elements in the set. The length field does not include the length of Type and Length fields.
オクテットで表現され、セット内の要素の数に基づいて変数です。長さフィールドには、型と長さのフィールドの長さは含まれません。
Local AS Number:
ローカルAS番号：
4 octets. The unsigned integer representing the AS number [RFC6793] of the AS to which the PeerSet SID advertising node belongs. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。Peerset SID Advertising Nodeが属するAS番号[RFC6793]を表す署名されていない整数。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Local BGP Router ID:
ローカルBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the PeerSet SID advertising node, as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているように、Peerset SID広告ノードのBGP識別子を表す署名されていない整数。
No. of elements in set:
セットの要素の数：
2 octets. The number of remote ASes over which the set SID performs load-balancing.
2オクテット。セットSIDがロードバランスを実行するリモートASの数。
Reserved:
予約済み：
2 octets. MUST be zero when sent and ignored when received.
2オクテット。送信されたときにゼロでなければなりません。
Remote AS Number:
数字としてリモート：
4 octets. The unsigned integer representing the AS number [RFC6793] of the remote node's AS for which the PeerSet SID is advertised. If Confederations [RFC5065] are in use, and if the remote node is a member of a different Member-AS within the local Confederation, this is the Member-AS Number inside the Confederation and not the Confederation Identifier.
4オクテット。リモートノードのAS番号[RFC6793]を表す署名されていない整数は、PeerSet SIDが宣伝されているASです。Confederations [RFC5065]が使用されている場合、リモートノードがローカル連合内の別のメンバーのメンバーである場合、これは連合識別子ではなく連合内のメンバーとしてのメンバーです。
Remote BGP Router ID:
リモートBGPルーターID：
4 octets. The unsigned integer representing the BGP Identifier of the remote node as defined in [RFC4271] and [RFC6286].
4オクテット。[RFC4271]および[RFC6286]で定義されているリモートノードのBGP識別子を表す署名されていない整数。
PeerSet SID may be associated with a number of PeerNode SIDs and PeerAdj SIDs. The remote AS number and the Router ID of each of these PeerNode SIDs and PeerAdj SIDs MUST be included in the FEC.
Peerset SIDは、多くのPeernode SIDSおよびPeerAdj SIDSに関連付けられている場合があります。これらのPeernode SIDとPeerAdj SIDのそれぞれの数とルーターIDをFECに含める必要があります。
When a remote ASBR of the EPE-SID advertisement receives the MPLS OAM packet with the top FEC being the EPE-SID, it MUST perform validity checks on the content of the EPE-SID FEC sub-TLV. The basic length check should be performed on the received FEC.
EPE-SID広告のリモートASBRがMPLS OAMパケットを受信し、上部FECがEPE-SIDである場合、EPE-SID FEC Sub-TLVのコンテンツの有効性チェックを実行する必要があります。基本的な長さチェックは、受信したFECで実行する必要があります。
PeerAdj SID sub-TLV
-----------
If Adj type = 1, Length should be 28 octets
If Adj type = 2, Length should be 52 octets
PeerNode SID sub-TLV
-------------
Length = (20 + No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets
PeerSet SID sub-TLV
-----------
Length = (9 + No. of elements in the set *
(8 + No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets
Figure 5: Length Validation
図5：長さの検証
If a malformed FEC sub-TLV is received, then a return code of 1, "Malformed echo request received", as defined in [RFC8029] MUST be sent. The section below is appended to the procedure given in step 4a of Section 7.4 of [RFC8287].
[RFC8029]で定義されているように、不正なFEC Sub-TLVを受信した場合、[RFC8029]で定義されている1の「不正なエコーリクエスト」を送信する必要があります。以下のセクションは、[RFC8287]のセクション7.4のステップ4Aに示されている手順に追加されます。
This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID, and EPE-SID validations. Note that the term "receiving node" in this section corresponds to the node that receives the OAM message with the Target FEC Stack TLV.
これは、セグメントルーティングIGP-Prefix、IGP-Adjacency SID、およびEPE-SID検証の例です。このセクションの「受信ノード」という用語は、ターゲットFECスタックTLVでOAMメッセージを受信するノードに対応することに注意してください。
Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
at FEC stack-depth is 38 (PeerAdj SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if
any below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerAdj SID
sub-TLV.
- Validate that the receiving node's BGP Router-ID
matches with the Remote Router ID field in the
received PeerAdj SID sub-TLV.
- Validate that there is an EBGP session with a peer
having a local AS number and BGP Router-ID as
specified in the local AS number and Local Router-ID
field in the received PeerAdj SID sub-TLV.
If the remote interface address is not zero, validate the
incoming interface. Set the Best-return-code to 35,
"Mapping for this FEC is not associated with the incoming
interface" [RFC8287]. Check if any below conditions fail:
- Validate that the incoming interface on which the
OAM packet was received matches with the remote
interface specified in the PeerAdj SID sub-TLV.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 39
(PeerNode SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if any
below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerNode SID
FEC sub-TLV.
- Validate that the receiving node's BGP Router-ID matches
with the Remote Router ID field in the received
PeerNode SID FEC.
- Validate that there is an EBGP session with a peer
having a local AS number and BGP Router-ID as
specified in the local AS number and Local Router-ID
field in the received PeerNode SID FEC sub-TLV.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 40
(PeerSet SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if any
below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with one of the remote AS fields in the received
PeerSet SID FEC sub-TLV.
- Validate that the receiving node's BGP Router-ID matches
with one of the Remote Router ID fields in the
received PeerSet SID FEC sub-TLV.
- Validate that there is an EBGP session with a peer having
a local AS number and BGP Router-ID as specified in the
local AS number and Local Router-ID fields in the received
PeerSet SID FEC sub-TLV.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
IANA has allocated three new Target FEC Stack sub-TLVs in the "Sub-TLVs for TLV Types 1, 16, and 21" registry [MPLS-LSP-PING] within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group.
IANAは、「マルチプロトコルラベルスイッチング（MPLS）の「TLVS」レジストリ内で「TLVタイプ1、16、および21」レジストリ[MPLS-LSP-PING]の「TLVタイプ1、16、および21」レジストリ[MPLS-LSP-PING]の「サブTLV」に3つの新しいターゲットFECスタックサブTLVを割り当てました。ラベルスイッチ付きパス（LSP）pingパラメーター "レジストリグループ。
+==========+==============+
| Sub-Type | Sub-TLV Name |
+==========+==============+
| 38 | PeerAdj SID |
+----------+--------------+
| 39 | PeerNode SID |
+----------+--------------+
| 40 | PeerSet SID |
+----------+--------------+
Table 1: Sub-TLVs for TLV Types 1, 16, and 21 Registry
表1：TLVタイプ1、16、および21レジストリのサブTLV
The EPE-SIDs are advertised for egress links for EPE purposes or for inter-AS links between cooperating ASes. When cooperating domains are involved, they can allow the packets arriving on trusted interfaces to reach the control plane and be processed.
EPE-SIDは、EPEの目的での出口リンク、または協力ASEの間のリンク間で宣伝されています。協力するドメインが関与する場合、信頼できるインターフェイスに到着するパケットが制御プレーンに到達し、処理できるようにすることができます。
When EPE-SIDs are created for egress TE links where the neighbor AS is an independent entity, it may not allow the packets arriving from the external world to reach the control plane. In such deployments, the MPLS OAM packets will be dropped by the neighboring AS that receives the MPLS OAM packet.
EPE-SIDは、隣人が独立したエンティティであるリンクの出力用に作成される場合、外部から到着するパケットがコントロールプレーンに到達することを許可しない場合があります。このような展開では、MPLS OAMパケットを受信するため、MPLS OAMパケットは隣接するものによってドロップされます。
In MPLS Traceroute applications, when the AS boundary is crossed with the EPE-SIDs, the Target FEC Stack TLV is changed. [RFC8287] does not mandate that the initiator, upon receiving an MPLS Echo Reply message that includes the Target FEC Stack Change TLV with one or more of the original segments being popped, remove the corresponding FEC(s) from the Target FEC Stack TLV in the next (TTL+1) traceroute request.
MPLS Tracerouteアプリケーションでは、AS境界がEPE-SIDと交差すると、ターゲットFECスタックTLVが変更されます。[RFC8287]は、ターゲットFECスタック変更TLVを含むMPLSエコー応答メッセージを受信すると、ターゲットFECスタックTLVから対応するFECスタックTLVから対応するFECを削除するMPLSエコー応答メッセージを受信すると、イニシエーターが義務付けられていません。次の（ttl+1）tracerouteリクエスト。
If an initiator does not remove the FECs belonging to the previous AS that has traversed, it may expose the internal AS information to the following AS being traversed in the traceroute.
イニシエーターが以前のASに属するFECを削除しない場合、それが移動したASは、Tracerouteで横断されているように内部として情報を以下に公開する可能性があります。
[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>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.
[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>.
[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>.
[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>.
[RFC8690] Nainar, N., Pignataro, C., Iqbal, F., and A. Vainshtein,
"Clarification of Segment ID Sub-TLV Length for RFC 8287",
RFC 8690, DOI 10.17487/RFC8690, December 2019,
<https://www.rfc-editor.org/info/rfc8690>.
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K.,
Ray, S., and J. Dong, "Border Gateway Protocol - Link
State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
2021, <https://www.rfc-editor.org/info/rfc9086>.
[MPLS-LSP-PING]
IANA, "Sub-TLVs for TLV Types 1, 16, and 21",
<https://www.iana.org/assignments/mpls-lsp-ping-
parameters>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065,
DOI 10.17487/RFC5065, August 2007,
<https://www.rfc-editor.org/info/rfc5065>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC7705] George, W. and S. Amante, "Autonomous System Migration
Mechanisms and Their Effects on the BGP AS_PATH
Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015,
<https://www.rfc-editor.org/info/rfc7705>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
[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>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[SR-BGP-POLICY]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-sr-
policy-safi-10, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-safi-10>.
[SR-SEGTYPES]
Talaulikar, K., Filsfils, C., Previdi, S., Mattes, P., and
D. Jain, "Segment Routing Segment Types Extensions for BGP
SR Policy", Work in Progress, Internet-Draft, draft-ietf-
idr-bgp-sr-segtypes-ext-06, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
sr-segtypes-ext-06>.
This section describes examples of both a correctly and an incorrectly programmed state and provides details on how the new sub-TLVs described in this document can be used to validate the correctness. Consider the diagram from Figure 1.
このセクションでは、正しくプログラムされた状態と誤った状態の両方の例について説明し、このドキュメントに記載されている新しいサブTLVを使用して正確性を検証する方法の詳細を説明します。図1の図を考えてみましょう。
Correctly programmed state:
正しくプログラムされた状態：
* C assigns label 16001 and binds it to adjacency C->E
* cラベル16001を割り当て、隣接するc-> eにバインドします
* C signals that label 16001 is bound to adjacency C->E (e.g., via BGP-LS)
* cラベル16001が隣接c-> eに拘束されるという信号（例：BGP-LSを介して）
* The controller/ingress programs an SR path that has SID/label 16001 to steer the packet on the exit point from C onto adjacency C->E
* コントローラー/イングレスプログラムSID/ラベル16001を備えたSRパスは、cから隣接するc-> eにcから出口ポイントのパケットを操縦します
* Using MPLS Traceroute procedures defined in this document, the PeerAdj SID sub-TLV is populated with entities to be validated by C when the OAM packet reaches it
* このドキュメントで定義されているMPLS Traceroute手順を使用して、PeerAdj Sid Sub-TLVには、OAMパケットが到達したときにCが検証するエンティティが入力されています
* C receives the OAM packet and validates that the top label (16001) is indeed corresponding to the entities populated in the PeerAdj SID sub-TLV
* c OAMパケットを受け取り、トップレーベル（16001）が実際にPeerAdj Sid Sub-TLVに存在するエンティティに対応していることを検証します
Incorrectly programmed state:
誤ってプログラムされた状態：
* C assigns label 16001 and binds it to adjacency C->D
* cラベル16001を割り当て、隣接するc-> dにバインドします
* The controller learns that PeerAdj SID label 16001 is bound to adjacency C->E (e.g., via BGP-LS) -- this could be a software bug on C or on the controller
* コントローラーは、PeerAdj SIDラベル16001が隣接c-> e（たとえば、BGP-LSを介して）にバインドされていることを知りました - これはCまたはコントローラーのソフトウェアバグになる可能性があります
* The controller/ingress programs an SR path that has SID/label 16001 to steer the packet on the exit point from C onto adjacency C->E
* コントローラー/イングレスプログラムSID/ラベル16001を備えたSRパスは、cから隣接するc-> eにcから出口ポイントのパケットを操縦します
* Using MPLS Traceroute procedures defined in this document, the PeerAdj SID sub-TLV is populated with entities to be validated by C (including a local/remote interface address of C->E) when the OAM packet reaches it
* このドキュメントで定義されたMPLSトレーサー手順を使用して、PeerAdj SID Sub-TLVには、OAMパケットが到達したときにC（C-> eのローカル/リモートインターフェイスアドレスを含む）によって検証されるエンティティが入力されています。
* C receives the OAM packet and validates that the top label (16001) is NOT bound to C->E as populated in the PeerAdj SID sub-TLV and then responds with the respective error code
* c OAMパケットを受信し、PeerAdj SID Sub-TLVに埋め込まれたトップレーベル（16001）がC-> eにバインドされていないことを検証し、それぞれのエラーコードで応答します
Thanks to Loa Andersson, Dhruv Dhody, Ketan Talaulikar, Italo Busi, Alexander Vainshtein, and Deepti Rathi for careful reviews and comments. Thanks to Tarek Saad for providing the example described in Appendix A.
Loa Andersson、Dhruv Dhody、Ketan Talaulikar、Italo Busi、Alexander Vainshtein、Deepti Rathiに感謝します。付録Aで説明した例を提供してくれたTarek Saadに感謝します
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore 560103
Karnataka
India
Email: shraddha@juniper.net
Mukul Srivastava
Juniper Networks Inc.
Email: msri@juniper.net
Kapil Arora
Individual Contributor
Email: kapil.it@gmail.com
Samson Ninan
Ciena
Email: samson.cse@gmail.com
Xiaohu Xu
China Mobile
Beijing
China
Email: xuxiaohu_ietf@hotmail.com