[要約] RFC 8287は、セグメントルーティング(SR)IGPプレフィックスおよびIGP隣接セグメント識別子(SIDs)を使用したMPLSデータプレーンにおけるラベルスイッチパス(LSP)のPing/Tracerouteに関する仕様です。このRFCの目的は、SRネットワークにおいてLSPのパスを確認するための効果的な手法を提供することです。

Internet Engineering Task Force (IETF)                     N. Kumar, Ed.
Request for Comments: 8287                             C. Pignataro, Ed.
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                               G. Swallow
                                               Southend Technical Center
                                                                N. Akiya
                                                     Big Switch Networks
                                                                 S. Kini
                                                              Individual
                                                                 M. Chen
                                                                  Huawei
                                                           December 2017
        

Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes

MPLSデータプレーンでのセグメントルーティング(SR)IGPプレフィックスおよびIGP隣接セグメント識別子(SID)のラベルスイッチドパス(LSP)Ping / Traceroute

Abstract

概要

A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

セグメントルーティング(SR)アーキテクチャは、ソースルーティングとトンネリングパラダイムを活用し、マルチプロトコルラベルスイッチング(MPLS)データプレーンの使用に直接適用できます。ノードは、パケットの先頭にSRヘッダーを付加することにより、「セグメント」と呼ばれる制御された一連の命令を通じてパケットを操作します。

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

SRのセグメント割り当てと転送のセマンティックの性質により、SRアーキテクチャ内のラベルスイッチドパス(LSP)の接続検証と障害分離に関する追加の考慮事項が発生します。このドキュメントは問題を説明し、MPLSデータプレーンでセグメントルーティングIGPプレフィックスとIGP隣接セグメント識別子(SID)のLSP PingとTracerouteを実行するための拡張機能を定義します。

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

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

Copyright Notice

著作権表示

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Coexistence of SR-Capable and Non-SR-Capable Node
           Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Challenges with Existing Mechanisms . . . . . . . . . . . . .   5
     4.1.  Path Validation in Segment Routing Networks . . . . . . .   5
   5.  Segment ID Sub-TLV  . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  IPv4 IGP-Prefix Segment ID  . . . . . . . . . . . . . . .   7
     5.2.  IPv6 IGP-Prefix Segment ID  . . . . . . . . . . . . . . .   8
     5.3.  IGP-Adjacency Segment ID  . . . . . . . . . . . . . . . .   9
   6.  Extension to Downstream Detailed Mapping TLV  . . . . . . . .  11
   7.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  FECs in Target FEC Stack TLV  . . . . . . . . . . . . . .  11
     7.2.  FEC Stack Change Sub-TLV  . . . . . . . . . . . . . . . .  12
     7.3.  Segment ID POP Operation  . . . . . . . . . . . . . . . .  13
     7.4.  Segment ID Check  . . . . . . . . . . . . . . . . . . . .  13
     7.5.  TTL Consideration for Traceroute  . . . . . . . . . . . .  19
   8.  Backward Compatibility with Non-SR Devices  . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     9.1.  New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . .  20
     9.2.  Protocol in the Segment ID Sub-TLV  . . . . . . . . . . .  20
     9.3.  Adjacency Type in the IGP-Adjacency Segment ID  . . . . .  20
     9.4.  Protocol in the Label Stack Sub-TLV of the Downstream
           Detailed Mapping TLV  . . . . . . . . . . . . . . . . . .  21
     9.5.  Return Code . . . . . . . . . . . . . . . . . . . . . . .  21
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
        
1. Introduction
1. はじめに

"Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures" [RFC8029] defines a simple and efficient mechanism to detect data-plane failures in Label Switched Paths (LSPs) by specifying information to be carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation. Mechanisms for reliably sending the echo reply are defined. The functionality defined in [RFC8029] is modeled after the Ping/Traceroute paradigm (ICMP echo request [RFC792]) and is typically referred to as "LSP Ping" and "LSP Traceroute". [RFC8029] supports hierarchical and stitching LSPs.

「マルチプロトコルラベルスイッチド(MPLS)データプレーンの障害の検出」[RFC8029]は、MPLSの「エコー要求」と「で送信される情報を指定することにより、ラベルスイッチドパス(LSP)のデータプレーンの障害を検出するシンプルで効率的なメカニズムを定義します。障害の検出と分離を目的とした「エコー応答」。エコー応答を確実に送信するメカニズムが定義されています。 [RFC8029]で定義されている機能は、Ping / Tracerouteパラダイム(ICMPエコー要求[RFC792])をモデルにしており、通常「LSP Ping」および「LSP Traceroute」と呼ばれています。 [RFC8029]は、LSPの階層化とステッチをサポートします。

[SR] introduces and describes an SR architecture that leverages the source routing and tunneling paradigms. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header. A detailed definition of the SR architecture is available in [SR].

[SR]は、ソースルーティングとトンネリングパラダイムを活用するSRアーキテクチャを紹介および説明しています。ノードは、パケットの先頭にSRヘッダーを付加することにより、「セグメント」と呼ばれる制御された一連の命令を通じてパケットを操作します。 SRアーキテクチャの詳細な定義は、[SR]にあります。

As described in [SR] and [SR-MPLS], the SR architecture can be directly applied to an MPLS data plane, the SID will be 20 bits, and the SR header is the label stack. Consequently, the mechanics of data-plane validation of [RFC8029] can be directly applied to SR MPLS.

[SR]と[SR-MPLS]で説明されているように、SRアーキテクチャはMPLSデータプレーンに直接適用でき、SIDは20ビットで、SRヘッダーはラベルスタックです。その結果、[RFC8029]のデータプレーン検証のメカニズムをSR MPLSに直接適用できます。

Unlike LDP or RSVP, which are the other well-known MPLS control plane protocols, the basis of Segment ID assignment in SR architecture is not always on a hop-by-hop basis. Depending on the type of Segment ID, the assignment can be unique to the node or within a domain.

他のよく知られたMPLSコントロールプレーンプロトコルであるLDPまたはRSVPとは異なり、SRアーキテクチャでのセグメントID割り当ての基礎は、必ずしもホップバイホップベースではありません。セグメントIDのタイプに応じて、割り当てはノードまたはドメイン内で一意にすることができます。

This nature of SR raises additional considerations for validation of fault detection and isolation in an SR network. This document illustrates the problem and describes a mechanism to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs within an MPLS data plane.

SRのこの性質により、SRネットワークでの障害検出と分離の検証に関する追加の考慮事項が発生します。このドキュメントでは、問題を説明し、MPLSデータプレーン内でセグメントルーティングIGPプレフィックスとIGP隣接SIDに対してLSP PingとTracerouteを実行するメカニズムについて説明します。

1.1. Coexistence of SR-Capable and Non-SR-Capable Node Scenarios
1.1. SR対応ノードシナリオとSR非対応ノードシナリオの共存

[INTEROP] describes how SR operates in a network where SR-capable and non-SR-capable nodes coexist. In such a network, one or more SR-based LSPs and non-SR-based LSPs are stitched together to achieve an end-to-end LSP. This is similar to a network where LDP and RSVP nodes coexist and the mechanism defined in Section 4.5.2 of [RFC8029] is applicable for LSP Ping and Trace.

[INTEROP]は、SR対応ノードと非SR対応ノードが共存するネットワークでSRがどのように動作するかを説明します。このようなネットワークでは、1つ以上のSRベースのLSPと非SRベースのLSPがつなぎ合わされて、エンドツーエンドのLSPが実現されます。これは、LDPノードとRSVPノードが共存するネットワークに似ており、[RFC8029]のセクション4.5.2で定義されたメカニズムがLSP PingおよびTraceに適用されます。

Section 8 of this document explains one of the potential gaps that is specific to SR-Capable and non-SR-capable node scenarios and explains how the existing mechanism defined in [RFC8029] handles it.

このドキュメントのセクション8では、SR対応およびSR非対応のノードシナリオに固有の潜在的なギャップの1つについて説明し、[RFC8029]で定義されている既存のメカニズムがそれを処理する方法について説明します。

2. Requirements Notation
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. Terminology
3. 用語

This document uses the terminology defined in [SR] and [RFC8029]; readers are expected to be familiar with those terms.

このドキュメントでは、[SR]および[RFC8029]で定義されている用語を使用しています。読者はこれらの用語に精通していることが求められます。

4. Challenges with Existing Mechanisms
4. 既存のメカニズムの課題

The following example describes the challenges with using the current MPLS Operations, Administration, and Maintenance (OAM) mechanisms on an SR network.

次の例では、SRネットワークで現在のMPLS運用、管理、および保守(OAM)メカニズムを使用する場合の課題について説明します。

4.1. Path Validation in Segment Routing Networks
4.1. セグメントルーティングネットワークのパス検証

[RFC8029] defines the MPLS OAM mechanisms that help with fault detection and isolation for an MPLS data-plane path by the use of various Target Forwarding Equivalence Class (FEC) Stack sub-TLVs that are carried in MPLS echo request packets and used by the responder for FEC validation. While it is obvious that new sub-TLVs need to be assigned for SR, the unique nature of the SR architecture raises the need for additional operational considerations for path validation. This section discusses the challenges.

[RFC8029]は、MPLSエコー要求パケットで運ばれて使用されるさまざまなターゲット転送等価クラス(FEC)スタックサブTLVを使用することにより、MPLSデータプレーンパスの障害検出と分離に役立つMPLS OAMメカニズムを定義しますFEC検証の応答者。新しいサブTLVをSRに割り当てる必要があることは明らかですが、SRアーキテクチャの固有の性質により、パス検証のための追加の運用上の考慮事項が必要になります。このセクションでは、課題について説明します。

                        L1
                    +--------+
                    |   L2   |
                    R3-------R6
                   /           \
                  /             \
          R1----R2               R7----R8
                  \             /
                   \           /
                    R4-------R5
        

Figure 1: Segment Routing Network

図1:セグメントルーティングネットワーク

The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7, and R8 are 5001, 5002, 5003, 5004, 5005, 5006, 5007, and 5008, respectively.

R1、R2、R3、R4、R5、R6、R7、およびR8のノードセグメントIDは、それぞれ5001、5002、5003、5004、5005、5006、5007、および5008です。

9136 --> Adjacency Segment ID from R3 to R6 over link L1. 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 9124 --> Adjacency segment ID from R2 to R4. 9123 --> Adjacency Segment ID from R2 to R3.

9136->リンクL1を介したR3からR6への隣接セグメントID。 9236->リンクL2を介したR3からR6への隣接セグメントID。 9124-> R2からR4への隣接セグメントID。 9123-> R2からR3への隣接セグメントID。

The forwarding semantic of the Adjacency Segment ID is to pop the Segment ID and send the packet to a specific neighbor over a specific link. A malfunctioning node may forward packets using the Adjacency Segment ID to an incorrect neighbor or over an incorrect link. The exposed Segment ID (of an incorrectly forwarded Adjacency Segment ID) might still allow such a packet to reach the intended destination, even though the intended strict traversal was broken.

隣接セグメントIDの転送セマンティクスは、セグメントIDをポップし、特定のリンクを介して特定のネイバーにパケットを送信することです。誤動作しているノードは、隣接セグメントIDを使用してパケットを不正なネイバーに、または不正なリンクを介して転送する場合があります。 (誤って転送された隣接セグメントIDの)公開されたセグメントIDは、意図された厳密なトラバーサルが破られた場合でも、そのようなパケットが意図された宛先に到達することを許可する可能性があります。

In the topology above, assume that R1 sends traffic with a segment stack as {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If the Adjacency Segment ID 9124 is misprogrammed in R2 to send the packet to R1 or R3, the packet may still be delivered to R8 (if the nodes are configured with the same SR Global Block (SRGB)) [SR] but not via the expected path.

上記のトポロジでは、R1が{9124、5008}のセグメントスタックでトラフィックを送信し、経路がR1-R2-R4-R5-R7-R8になると想定しています。隣接セグメントID 9124がR2で誤ってプログラムされてパケットがR1またはR3に送信される場合、パケットは引き続きR8に配信される可能性があります(ノードが同じSRグローバルブロック(SRGB)で構成されている場合)[SR]予想されるパス。

MPLS traceroute may help with detecting such a deviation in the above-mentioned scenario. However, in a different example, it may not be helpful, for example, if R3 forwards a packet with Adjacency Segment ID 9236 via link L1 (due to misprogramming) when it was expected to be forwarded over link L2.

MPLS tracerouteは、上記のシナリオでこのような逸脱を検出するのに役立ちます。ただし、別の例では、たとえば、リンクL2を介して転送されることが予期されていたときに、R3が隣接セグメントID 9236のパケットをリンクL1を介して(誤プログラミングにより)転送した場合、役に立たない場合があります。

5. Segment ID Sub-TLV
5. セグメントIDサブTLV

The format of the following Segment ID sub-TLVs follows the philosophy of the Target FEC Stack TLV carrying FECs corresponding to each label in the label stack. When operated with the procedures defined in [RFC8029], this allows LSP Ping/Traceroute operations to function when the Target FEC Stack TLV contains more FECs than received label stacks at the responder nodes.

次のセグメントIDサブTLVのフォーマットは、ラベルスタック内の各ラベルに対応するFECを運ぶターゲットFECスタックTLVの哲学に従います。 [RFC8029]で定義された手順で操作すると、ターゲットFECスタックTLVに応答ノードで受信したラベルスタックよりも多くのFECが含まれている場合、LSP Ping / Traceroute操作が機能します。

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).

ターゲットFECスタックTLV(タイプ1)、リバースパスターゲットFECスタックTLV(タイプ16)、および応答パスTLV(タイプ21)に対して、3つの新しいサブTLVが定義されています。

           Sub-Type    Sub-TLV Name
           --------  ---------------
             34      IPv4 IGP-Prefix Segment ID
             35      IPv6 IGP-Prefix Segment ID
             36      IGP-Adjacency Segment ID
        

See Section 9.2 for the registry for the Protocol field specified within these sub-TLVs.

これらのサブTLV内で指定されたプロトコルフィールドのレジストリについては、セクション9.2を参照してください。

5.1. IPv4 IGP-Prefix Segment ID
5.1. IPv4 IGPプレフィックスセグメントID

The IPv4 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:

IPv4 IGP-PrefixセグメントIDは[SR]で定義されています。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IPv4 Prefix                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

IPv4 Prefix

IPv4プレフィックス

This field carries the IPv4 Prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 32 bits, trailing bits SHOULD be set to zero.

このフィールドには、セグメントIDが割り当てられているIPv4プレフィックスが含まれます。エニーキャストセグメントIDの場合、このフィールドにはIPv4エニーキャストアドレスが含まれます。プレフィックスが32ビットより短い場合、後続ビットはゼロに設定する必要があります(SHOULD)。

Prefix Length

プレフィックス長

The Prefix Length field is one octet. It gives the length of the prefix in bits (values can be 1-32).

Prefix Lengthフィールドは1オクテットです。プレフィックスの長さをビット単位で示します(値は1〜32にすることができます)。

Protocol

プロトコル

This field is set to 1, if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2, if the responder MUST perform Egress FEC validation using the Intermediate System to Intermediate System (IS-IS) as the IGP protocol. Set to 0, if the responder can use any IGP protocol for Egress FEC validation.

応答側がIGPプロトコルとしてOSPFを使用してFEC検証を実行する必要がある場合、このフィールドは1に設定されます。レスポンダーがIGPプロトコルとして中間システム間(IS-IS)を使用して出力FEC検証を実行する必要がある場合は、2に設定します。レスポンダが出力FEC検証に任意のIGPプロトコルを使用できる場合は、0に設定します。

Reserved

予約済み

The Reserved field MUST be set to 0 when sent and MUST be ignored on receipt.

予約フィールドは送信時に0に設定する必要があり、受信時には無視する必要があります。

5.2. IPv6 IGP-Prefix Segment ID
5.2. IPv6 IGPプレフィックスセグメントID

The IPv6 IGP-Prefix Segment ID is defined in [SR]. The format is as specified below:

IPv6 IGP-PrefixセグメントIDは[SR]で定義されています。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 Prefix                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Prefix Length  |    Protocol   |              Reserved         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

IPv6 Prefix

IPv6プレフィックス

This field carries the IPv6 prefix to which the Segment ID is assigned. In case of an Anycast Segment ID, this field will carry the IPv4 Anycast address. If the prefix is shorter than 128 bits, trailing bits SHOULD be set to zero.

このフィールドには、セグメントIDが割り当てられているIPv6プレフィックスが含まれます。エニーキャストセグメントIDの場合、このフィールドにはIPv4エニーキャストアドレスが含まれます。プレフィックスが128ビットより短い場合、後続ビットはゼロに設定する必要があります(SHOULD)。

Prefix Length

プレフィックス長

The Prefix Length field is one octet, it gives the length of the prefix in bits (values can be 1-128).

プレフィックス長フィールドは1オクテットで、プレフィックスの長さをビット単位で示します(値は1〜128です)。

Protocol

プロトコル

Set to 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP protocol for Egress FEC validation.

レスポンダがIGPプロトコルとしてOSPFを使用してFEC検証を実行する必要がある場合は、1に設定します。レスポンダがIGPプロトコルとしてIS-ISを使用して出力FEC検証を実行する必要がある場合は、2に設定します。レスポンダが出力FEC検証に任意のIGPプロトコルを使用できる場合は、0に設定します。

Reserved

予約済み

MUST be set to 0 on send and MUST be ignored on receipt.

送信時には0に設定する必要があり、受信時には無視する必要があります。

5.3. IGP-Adjacency Segment ID
5.3. IGP隣接セグメントID

This sub-TLV is applicable for any IGP-Adjacency defined in [SR]. The format is as specified below:

このサブTLVは、[SR]で定義されているすべてのIGP隣接に適用できます。形式は次のとおりです。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Adj. Type   |    Protocol   |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |               Local Interface ID (4 or 16 octets)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |              Remote Interface ID (4 or 16 octets)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |          Advertising Node Identifier (4 or 6 octets)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     |           Receiving Node Identifier (4 or 6 octets)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Adj. Type (Adjacency Type)

調整。タイプ(隣接タイプ)

Set to 1 when the Adjacency Segment is a Parallel Adjacency as defined in [SR]. Set to 4 when the Adjacency Segment is IPv4 based and is not a Parallel Adjacency. Set to 6 when the Adjacency Segment is IPv6 based and is not a Parallel Adjacency. Set to 0 when the Adjacency Segment is over an unnumbered interface.

隣接セグメントが[SR]で定義されている並列隣接である場合、1に設定されます。隣接セグメントがIPv4ベースで、並列隣接ではない場合は、4に設定します。隣接セグメントがIPv6ベースであり、並列隣接ではない場合は、6に設定します。隣接セグメントが番号なしインターフェース上にある場合は0に設定します。

Protocol

プロトコル

Set to 1 if the responder MUST perform FEC validation using OSPF as the IGP protocol. Set to 2 if the responder MUST perform Egress FEC validation using IS-IS as the IGP protocol. Set to 0 if the responder can use any IGP protocol for Egress FEC validation.

レスポンダがIGPプロトコルとしてOSPFを使用してFEC検証を実行する必要がある場合は、1に設定します。レスポンダがIGPプロトコルとしてIS-ISを使用して出力FEC検証を実行する必要がある場合は、2に設定します。レスポンダが出力FEC検証に任意のIGPプロトコルを使用できる場合は、0に設定します。

Reserved

予約済み

MUST be set to 0 on send and MUST be ignored on receipt.

送信時には0に設定する必要があり、受信時には無視する必要があります。

Local Interface ID

ローカルインターフェイスID

An identifier that is assigned by the local Label Switching Router (LSR) for a link to which the Adjacency Segment ID is bound. This field is set to a local link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.

隣接セグメントIDがバインドされているリンクのローカルラベルスイッチングルーター(LSR)によって割り当てられる識別子。このフィールドは、ローカルリンクアドレス(IPv4またはIPv6)に設定されます。 IPv4の場合、このフィールドは4オクテットです。 IPv6の場合、このフィールドは16オクテットです。番号なしの場合、このフィールドは4オクテットであり、[RFC4203]および[RFC5307]で定義されている32ビットのリンク識別子が含まれます。隣接セグメントIDが並列隣接[SR]を表す場合、このフィールドは4オクテットであり、ゼロの4オクテットに設定する必要があります。

Remote Interface ID

リモートインターフェイスID

An identifier that is assigned by the remote LSR for a link on which the Adjacency Segment ID is bound. This field is set to the remote (downstream neighbor) link address (IPv4 or IPv6). For IPv4, this field is 4 octets; for IPv6, this field is 16 octets. If unnumbered, this field is 4 octets and includes a 32-bit link identifier as defined in [RFC4203] and [RFC5307]. If the Adjacency Segment ID represents Parallel Adjacencies [SR], this field is 4 octets and MUST be set to 4 octets of zeroes.

隣接セグメントIDがバインドされているリンクに対してリモートLSRによって割り当てられる識別子。このフィールドは、リモート(ダウンストリームネイバー)リンクアドレス(IPv4またはIPv6)に設定されます。 IPv4の場合、このフィールドは4オクテットです。 IPv6の場合、このフィールドは16オクテットです。番号なしの場合、このフィールドは4オクテットであり、[RFC4203]および[RFC5307]で定義されている32ビットのリンク識別子が含まれます。隣接セグメントIDが並列隣接[SR]を表す場合、このフィールドは4オクテットであり、ゼロの4オクテットに設定する必要があります。

Advertising Node Identifier

広告ノード識別子

This specifies the Advertising Node Identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.

これは、広告ノード識別子を指定します。 Protocolフィールドが1に設定されている場合、このフィールドは4オクテットであり、32ビットのOSPFルーターIDを伝達します。プロトコルフィールドが2に設定されている場合、このフィールドは6オクテットであり、48ビットのIS-ISシステムIDを伝達します。プロトコルフィールドが0に設定されている場合、このフィールドは4オクテットであり、ゼロに設定する必要があります。

Receiving Node Identifier

受信ノード識別子

This specifies the downstream node identifier. When the Protocol field is set to 1, then this field is 4 octets and carries the 32-bit OSPF Router ID. If the Protocol field is set to 2, then this field is 6 octets and carries the 48-bit IS-IS System ID. If the Protocol field is set to 0, then this field is 4 octets and MUST be set to zero.

ダウンストリームノード識別子を指定します。 Protocolフィールドが1に設定されている場合、このフィールドは4オクテットであり、32ビットのOSPFルーターIDを伝達します。プロトコルフィールドが2に設定されている場合、このフィールドは6オクテットであり、48ビットのIS-ISシステムIDを伝達します。プロトコルフィールドが0に設定されている場合、このフィールドは4オクテットであり、ゼロに設定する必要があります。

6. Extension to Downstream Detailed Mapping TLV
6. ダウンストリーム詳細マッピングTLVの拡張

In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is used to report for each interface over which a FEC could be forwarded. For a FEC, there are multiple protocols that may be used to distribute label mapping. The Protocol field of the Downstream Detailed Mapping TLV is used to return the protocol that is used to distribute the label carried in the Downstream Label field. The following protocols are defined in [RFC8029]:

エコー応答では、ダウンストリーム詳細マッピングTLV [RFC8029]を使用して、FECを転送できる各インターフェイスについて報告します。 FECの場合、ラベルマッピングの配布に使用できる複数のプロトコルがあります。ダウンストリーム詳細マッピングTLVのプロトコルフィールドは、ダウンストリームラベルフィールドで運ばれるラベルを配布するために使用されるプロトコルを返すために使用されます。以下のプロトコルは[RFC8029]で定義されています:

      Protocol #        Signaling Protocol
      ----------        ------------------
        0               Unknown
        1               Static
        2               BGP
        3               LDP
        4               RSVP-TE
        

With SR, OSPF or IS-IS can be used for label distribution. This document adds two new protocols as follows:

SRでは、OSPFまたはIS-ISをラベル配布に使用できます。このドキュメントでは、次の2つの新しいプロトコルを追加しています。

      Protocol #        Signaling Protocol
      ----------        ------------------
        5               OSPF
        6               IS-IS
        

See Section 9.4.

セクション9.4を参照してください。

7. Procedures
7. 手続き

This section describes aspects of LSP Ping and Traceroute operations that require further considerations beyond [RFC8029].

このセクションでは、[RFC8029]を超えてさらに検討する必要があるLSP PingおよびTraceroute操作の側面について説明します。

7.1. FECs in Target FEC Stack TLV
7.1. ターゲットFECスタックTLVのFEC

When LSP echo request packets are generated by an initiator, FECs carried in the Target FEC Stack TLV may need to differ to support an SR architecture. The following defines the Target FEC Stack TLV construction mechanics by an initiator for SR scenarios.

LSPエコー要求パケットがイニシエーターによって生成される場合、ターゲットFECスタックTLVで伝送されるFECは、SRアーキテクチャをサポートするために異なる必要がある場合があります。以下は、SRシナリオのイニシエーターによるターゲットFECスタックTLV構築メカニズムを定義しています。

Ping

ping

The initiator MUST include FEC(s) corresponding to the destination segment.

イニシエーターは、宛先セグメントに対応するFECを含める必要があります。

The initiator MAY include FECs corresponding to some or all of the segments imposed in the label stack by the initiator to communicate the segments traversed.

イニシエーターは、トラバースされたセグメントを通信するために、イニシエーターによってラベルスタックに課されたセグメントの一部またはすべてに対応するFECを含めることができます。

Traceroute

トレースルート

The initiator MUST initially include FECs corresponding to all segments imposed in the label stack.

イニシエーターは、最初にラベルスタックに課されたすべてのセグメントに対応するFECを含める必要があります。

When a received echo reply contains the FEC Stack Change TLV with one or more of the original segments being popped, the initiator MAY remove a corresponding FEC(s) from the Target FEC Stack TLV in the next (TTL+1) traceroute request, as defined in Section 4.6 of [RFC8029].

受信したエコー応答に、1つ以上の元のセグメントがポップされたFECスタック変更TLVが含まれている場合、イニシエーターは、次の(TTL + 1)traceroute要求で、対応するFECをターゲットFECスタックTLVから削除できます(MAY)。 [RFC8029]のセクション4.6で定義されています。

When a received echo reply does not contain the FEC Stack Change TLV, the initiator MUST NOT attempt to remove any FECs from the Target FEC Stack TLV in the next (TTL+1) traceroute request.

受信したエコー応答にFECスタック変更TLVが含まれていない場合、イニシエーターは次の(TTL + 1)traceroute要求でターゲットFECスタックTLVからFECを削除してはなりません(MUST NOT)。

As defined in [SR-OSPF] and [SR-IS-IS], the Prefix SID can be advertised as an absolute value, an index, or as a range. In any of these cases, the initiator MUST derive the Prefix mapped to the Prefix SID and use it in the IGP-Prefix Segment ID defined in Sections 5.1 and 5.2. How the responder uses the details in the SR-FEC sub-TLV to perform the validation is a local implementation matter.

[SR-OSPF]および[SR-IS-IS]で定義されているように、プレフィックスSIDは、絶対値、インデックス、または範囲としてアドバタイズできます。これらのいずれの場合でも、イニシエーターは、プレフィックスSIDにマップされたプレフィックスを導出し、セクション5.1および5.2で定義されたIGPプレフィックスセグメントIDで使用する必要があります。レスポンダがSR-FECサブTLVの詳細を使用して検証を実行する方法は、ローカル実装の問題です。

7.2. FEC Stack Change Sub-TLV
7.2. FECスタック変更サブTLV

[RFC8029] defines a FEC Stack Change sub-TLV that a router must include when the FEC stack changes.

[RFC8029]は、FECスタックが変更されたときにルーターに含める必要があるFECスタック変更サブTLVを定義します。

The network node that advertised the Node Segment ID is responsible for generating a FEC Stack Change sub-TLV with the Post Office Protocol (POP) operation type for the Node Segment ID, regardless of whether or not Penultimate Hop Popping (PHP) is enabled.

ノードセグメントIDをアドバタイズしたネットワークノードは、Penultimate Hop Popping(PHP)が有効かどうかに関係なく、ノードセグメントIDのPOP(Post Office Protocol)オペレーションタイプでFECスタック変更サブTLVを生成します。

The network node that is immediately downstream of the node that advertised the Adjacency Segment ID is responsible for generating the FEC Stack Change sub-TLV for POP operation for the Adjacency Segment ID.

隣接セグメントIDをアドバタイズしたノードのすぐ下流にあるネットワークノードは、隣接セグメントIDのPOP操作用のFECスタック変更サブTLVを生成する責任があります。

7.3. Segment ID POP Operation
7.3. セグメントID POP操作

The forwarding semantic of the Node Segment ID with the PHP flag is equivalent to usage of Implicit Null in MPLS protocols. The Adjacency Segment ID is also similar in a sense that it can be thought of as a locally allocated segment that has PHP enabled when destined for the next-hop IGP Adjacency Node. Procedures described in Section 4.4 of [RFC8029] rely on the Stack-D and Stack-R explicitly having the Implicit Null value. Implementations SHOULD use the Implicit Null for the Node Segment ID PHP and Adjacency Segment ID PHP cases.

PHPフラグを使用したノードセグメントIDの転送セマンティクスは、MPLSプロトコルでの暗黙的ヌルの使用と同等です。隣接セグメントIDも、ネクストホップIGP隣接ノードを宛先とする場合にPHPが有効になっているローカルに割り当てられたセグメントと考えることができるという意味で似ています。 [RFC8029]のセクション4.4で説明されている手順は、Stack-DおよびStack-Rが明示的にImplicit Null値を持つことに依存しています。実装では、ノードセグメントIDのPHPおよび隣接セグメントIDのPHPの場合に暗黙的ヌルを使用する必要があります(SHOULD)。

7.4. Segment ID Check
7.4. セグメントIDチェック

This section modifies the procedure defined in Section 4.4.1 of [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is modified as below:

このセクションでは、[RFC8029]のセクション4.4.1で定義されている手順を変更します。 [RFC8029]のセクション4.4.1で定義されているステップ4は、次のように変更されています。

4. If the label mapping for FEC is Implicit Null, set the FEC-status to 2 and proceed to step 4a. Otherwise, if the label mapping for FEC is Label-L, proceed to step 4a. Otherwise, set the FEC-return-code to 10 ("Mapping for this FEC is not the given label at stack-depth"), set the FEC-status to 1, and return.

4. FECのラベルマッピングがImplicit Nullの場合、FECステータスを2に設定して、ステップ4aに進みます。それ以外の場合、FECのラベルマッピングがLabel-Lの場合は、ステップ4aに進みます。それ以外の場合は、FEC-return-codeを10に設定し(「このFECのマッピングはスタック深度で指定されたラベルではありません」)、FECステータスを1に設定して戻ります。

4a. Segment Routing IGP-Prefix and IGP-Adjacency SID Validation:

4a。セグメントルーティングIGPプレフィックスとIGP隣接SIDの検証:

If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {

Label-stack-depthが0で、FEC-stack-depthのターゲットFECスタックサブTLVが34(IPv4 IGP-PrefixセグメントID)の場合、{

Set the Best-return-code to 10, "Mapping for this FEC is not the given label at stack-depth <RSC>" if any below conditions fail:

以下のいずれかの条件が満たされない場合、Best-return-codeを10に設定します。「このFECのマッピングは、スタック深度<RSC>で指定されたラベルではありません」

            /* The responder LSR is to check if it is the egress of the
            IPv4 IGP-Prefix Segment ID described in the Target FEC Stack
            sub-TLV, and if the FEC was advertised with the PHP bit
            set.*/
        

- Validate that the Node Segment ID is advertised for the IPv4 Prefix by IGP Protocol {

- ノードセグメントIDがIGPプロトコルによってIPv4プレフィックスにアドバタイズされていることを確認します{

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、プロトコル値0として扱われる必要があります。

}

- Validate that the Node Segment ID is advertised with the No-PHP flag. {

- ノードセグメントIDがNo-PHPフラグでアドバタイズされていることを確認します。 {

o When the Protocol is OSPF, the NP-Flag defined in Section 5 of [SR-OSPF] MUST be set to 0.

o プロトコルがOSPFの場合、[SR-OSPF]のセクション5で定義されたNP-Flagを0に設定する必要があります。

o When the Protocol is IS-IS, the P-Flag defined in Section 6.1 of [SR-IS-IS] MUST be set to 0.

o プロトコルがIS-ISの場合、[SR-IS-IS]のセクション6.1で定義されているPフラグを0に設定する必要があります。

}

If it can be determined that no protocol associated with the Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC-stack-depth" and return.

Interface-Iに関連付けられているプロトコルがFEC-stack-depthでFEC-Typeをアドバタイズしていないと判断できる場合は、Best-return-codeを12に設定します。「プロトコルはFEC-stack-depthのインターフェイスに関連付けられていません" そして戻る。

Set FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

Else, if the Label-stack-depth is greater than 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {

それ以外の場合、Label-stack-depthが0より大きく、FEC-stack-depthでのターゲットFEC Stack sub-TLVが34(IPv4 IGP-Prefix Segment ID)の場合、{

Set the Best-return-code to 10 if any below conditions fail:

以下のいずれかの条件が満たされない場合は、Best-return-codeを10に設定します。

- Validate that the Node Segment ID is advertised for the IPv4 Prefix by the IGP protocol {

- ノードセグメントIDがIGPプロトコルによってIPv4プレフィックスにアドバタイズされていることを検証します{

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

o 受信したIPv4 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

o When the Protocol field in the received IPv4 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

o 受信したIPv4 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、プロトコル値0として扱われる必要があります。

}

If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.

Interface-Iに関連付けられているプロトコルがFEC-stack-depthでFEC-Typeをアドバタイズしなかったと判断できる場合は、Best-return-codeを12に設定します。「プロトコルはFEC stack-depthのインターフェイスに関連付けられていません」戻ります。

Set FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

Else, if the Label-stack-depth is 0 and the Target FEC sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), {

それ以外の場合、Label-stack-depthが0で、FEC-stack-depthのターゲットFECサブTLVが35(IPv6 IGP-Prefix Segment ID)の場合、{

Set the Best-return-code to 10 if any of the below conditions fail:

以下のいずれかの条件が満たされない場合は、Best-return-codeを10に設定します。

            /* The LSR needs to check if it is being a tail-end for the
            LSP and have the prefix advertised with the PHP bit set*/
        

- Validate that the Node Segment ID is advertised for the IPv6 Prefix by the IGP protocol {

- ノードセグメントIDがIGPプロトコルによってIPv6プレフィックスにアドバタイズされていることを確認します{

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

o 受信したIPv6 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、0のプロトコル値として処理する必要があります。

}

- Validate that the Node Segment ID is advertised with the No-PHP flag. {

- ノードセグメントIDがNo-PHPフラグでアドバタイズされていることを確認します。 {

o When the Protocol is OSPF, the NP-flag defined in Section 5 of [SR-OSPFV3] MUST be set to 0.

o プロトコルがOSPFの場合、[SR-OSPFV3]のセクション5で定義されたNPフラグを0に設定する必要があります。

o When the Protocol is IS-IS, the P-Flag defined in Section 6.1 of [SR-IS-IS] MUST be set to 0.

o プロトコルがIS-ISの場合、[SR-IS-IS]のセクション6.1で定義されているPフラグを0に設定する必要があります。

}

If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.

Interface-Iに関連付けられているプロトコルがFEC-stack-depthでFEC-Typeをアドバタイズしなかったと判断できる場合は、Best-return-codeを12に設定します。「プロトコルはFEC stack-depthのインターフェイスに関連付けられていません」戻ります。

Set the FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

Else, if the Label-stack-depth is greater than 0 and the Target FEC sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), {

それ以外の場合、Label-stack-depthが0より大きく、FEC-stack-depthのターゲットFECサブTLVが35(IPv6 IGP-Prefix Segment ID)の場合、{

Set the Best-return-code to 10 if any below conditions fail:

以下のいずれかの条件が満たされない場合は、Best-return-codeを10に設定します。

- Validate that the Node Segment ID is advertised for the IPv4 Prefix by the IGP protocol {

- ノードセグメントIDがIGPプロトコルによってIPv4プレフィックスにアドバタイズされていることを検証します{

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

o 受信したIPv6 IGPプレフィックスセグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

o When the Protocol field in the received IPv6 IGP-Prefix Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

o 受信したIPv6 IGP-PrefixセグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、0のプロトコル値として処理する必要があります。

}

If it can be determined that no protocol associated with Interface-I would have advertised the FEC-Type at FEC-stack-depth, set the Best-return-code to 12, "Protocol not associated with interface at FEC stack-depth" and return.

Interface-Iに関連付けられているプロトコルがFEC-stack-depthでFEC-Typeをアドバタイズしなかったと判断できる場合は、Best-return-codeを12に設定します。「プロトコルはFEC stack-depthのインターフェイスに関連付けられていません」戻ります。

Set the FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

Else, if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP-Adjacency Segment ID), {

それ以外の場合、FECスタック深度のターゲットFECサブTLVが36(IGP隣接セグメントID)の場合、{

Set the Best-return-code to 35 (Section 9.5) if any below conditions fail:

以下のいずれかの条件が満たされない場合は、Best-return-codeを35(セクション9.5)に設定します。

When the Adj. Type is 1 (Parallel Adjacency):

ときに調整。タイプは1(並列隣接)です。

o Validate that the Receiving Node Identifier is the local IGP identifier.

o 受信ノード識別子がローカルIGP識別子であることを確認します。

o Validate that the IGP-Adjacency Segment ID is advertised by the Advertising Node Identifier of the Protocol in the local IGP database {

o IGP隣接セグメントIDがローカルIGPデータベースのプロトコルのアドバタイジングノード識別子によってアドバタイズされていることを検証します{

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、プロトコル値0として処理する必要があります。

}

When the Adj. Type is 4 or 6 (IGP Adjacency or LAN Adjacency):

ときに調整。タイプは4または6(IGP隣接またはLAN隣接)です。

o Validate that the Remote Interface ID matches the local identifier of the interface (Interface-I) on which the packet was received.

o リモートインターフェイスIDが、パケットを受信したインターフェイス(インターフェイスI)のローカル識別子と一致することを確認します。

o Validate that the Receiving Node Identifier is the local IGP identifier.

o 受信ノード識別子がローカルIGP識別子であることを確認します。

o Validate that the IGP-Adjacency Segment ID is advertised by the Advertising Node Identifier of Protocol in the local IGP database {

o IGP隣接セグメントIDがローカルIGPデータベースのプロトコルのアドバタイジングノード識別子によってアドバタイズされていることを検証します{

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 0, use any locally enabled IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが0の場合、ローカルで有効になっているIGPプロトコルを使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 1, use OSPF as the IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが1の場合、IGPプロトコルとしてOSPFを使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is 2, use IS-IS as the IGP protocol.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが2の場合、IS-ISをIGPプロトコルとして使用します。

* When the Protocol field in the received IGP-Adjacency Segment ID sub-TLV is an unrecognized value, it MUST be treated as a Protocol value of 0.

* 受信したIGP隣接セグメントIDサブTLVのプロトコルフィールドが認識されない値である場合、プロトコル値0として処理する必要があります。

}

Set the FEC-Status to 1 and return.

FEC-Statusを1に設定して戻ります。

}

7.5. TTL Consideration for Traceroute
7.5. TracerouteのTTLに関する考慮事項

The LSP Traceroute operation can properly traverse every hop of the SR network for the Uniform Model as described in [RFC3443]. If one or more LSRs employ a Short Pipe Model, as described in [RFC3443], then the LSP Traceroute may not be able to properly traverse every hop of the SR network due to the absence of TTL copy operation when the outer label is popped. The Short Pipe is one of the most commonly used models. The following TTL manipulation technique MAY be used when the Short Pipe Model is used.

[RFC3443]で説明されているように、LSP Traceroute操作は、均一モデルのSRネットワークのすべてのホップを適切に通過できます。 [RFC3443]で説明されているように、1つ以上のLSRがショートパイプモデルを採用している場合、外側のラベルがポップされたときにTTLコピー操作がないため、LSP TracerouteはSRネットワークのすべてのホップを正しく通過できない場合があります。ショートパイプは、最もよく使用されるモデルの1つです。ショートパイプモデルを使用する場合は、次のTTL操作テクニックを使用できます。

When tracing an LSP according to the procedures in [RFC8029], the TTL is incremented by one in order to trace the path sequentially along the LSP. However, when a source-routed LSP has to be traced, there are as many TTLs as there are labels in the stack. The LSR that initiates the traceroute SHOULD start by setting the TTL to 1 for the tunnel in the LSP's label stack it wants to start the tracing from, the TTL of all outer labels in the stack to the max value, and the TTL of all the inner labels in the stack to zero. Thus, a typical start to the traceroute would have a TTL of 1 for the outermost label and all the inner labels would have a TTL of 0. If the FEC Stack TLV is included, it should contain only those for the inner-stacked tunnels. The Return Code/Subcode and FEC Stack Change TLV should be used to diagnose the tunnel as described in [RFC8029]. When the tracing of a tunnel in the stack is complete, then the next tunnel in the stack should be traced. The end of a tunnel can be detected from the Return Code when it indicates that the responding LSR is an egress for the stack at depth 1. Thus, the traceroute procedures in [RFC8029] can be recursively applied to traceroute a source-routed LSP.

[RFC8029]の手順に従ってLSPをトレースする場合、LSPに沿ってパスを順次トレースするために、TTLが1ずつ増加します。ただし、ソースルートLSPをトレースする必要がある場合、スタック内のラベルと同じ数のTTLがあります。 tracerouteを開始するLSRは、トレースを開始するLSPのラベルスタック内のトンネルのTTLを1に設定することで開始する必要があります(SHOULD)、スタック内のすべての外部ラベルのTTL、最大値、およびすべてのTTLスタックの内部ラベルをゼロにします。したがって、tracerouteの一般的な開始では、最外部ラベルのTTLが1になり、すべての内部ラベルのTTLが0になります。FECスタックTLVが含まれている場合は、内部スタックトンネルのTTLのみが含まれている必要があります。 [RFC8029]で説明されているように、リターンコード/サブコードとFECスタック変更TLVを使用してトンネルを診断する必要があります。スタック内のトンネルのトレースが完了したら、スタック内の次のトンネルをトレースする必要があります。トンネルの終わりは、応答LSRが深さ1のスタックの出口であることを示す場合、リターンコードから検出できます。したがって、[RFC8029]のtraceroute手順を再帰的に適用して、ソースルートLSPをtracerouteできます。

8. Backward Compatibility with Non-SR Devices
8. 非SRデバイスとの下位互換性

[INTEROP] describes how SR operates in a network where SR-capable and non-SR-capable nodes coexist. In such networks, there may not be any FEC mapping in the responder when the initiator is SR-capable, while the responder is not (or vice-versa). But this is not different from RSVP and LDP interoperation scenarios. When LSP Ping is triggered, the responder will set the FEC-return-code to Return 4, "Replying router has no mapping for the FEC at stack-depth".

[INTEROP]は、SR対応ノードと非SR対応ノードが共存するネットワークでSRがどのように動作するかを説明します。このようなネットワークでは、イニシエーターがSR対応であるときにレスポンダーにFECマッピングがない可能性がありますが、レスポンダーはそうではありません(またはその逆)。ただし、これはRSVPとLDPの相互運用シナリオと同じです。 LSP Pingがトリガーされると、レスポンダはFEC-return-codeをReturn 4に設定します。「返信ルータには、スタック深度でのFECのマッピングがありません」。

Similarly, when an SR-capable node assigns Adj-SID for a non-SR-capable node, the LSP traceroute may fail as the non-SR-capable node is not aware of the "IGP Adjacency Segment ID" sub-TLV and may not reply with the FEC Stack Change sub-TLVs. This may result in any further downstream nodes replying back with a Return Code of 4, "Replying router has no mapping for the FEC at stack-depth".

同様に、SR対応ノードが非SR対応ノードにAdj-SIDを割り当てると、非SR対応ノードが「IGP隣接セグメントID」サブTLVを認識せず、LSP tracerouteが失敗する場合があります。 FECスタック変更サブTLVで応答しない。これにより、さらに下流のノードが戻りコード4で応答する可能性があります。「応答するルーターには、スタック深度でのFECのマッピングがありません」。

9. IANA Considerations
9. IANAに関する考慮事項
9.1. New Target FEC Stack Sub-TLVs
9.1. 新しいターゲットFECスタックサブTLV

IANA has assigned three new sub-TLVs from the "sub-TLVs for TLV Types 1, 16, and 21" subregistry of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA].

IANAは、「マルチプロトコルラベルスイッチング(MPLS)ラベルスイッチドパス(LSP)Pingパラメータ」レジストリ[IANA]の「TLVタイプ1、16、および21のサブTLV」から3つの新しいサブTLVを割り当てました。

   Sub-Type    Sub-TLV Name                 Reference
   --------    -----------------            ------------
     34        IPv4 IGP-Prefix Segment ID   Section 5.1
     35        IPv6 IGP-Prefix Segment ID   Section 5.2
     36        IGP-Adjacency Segment ID     Section 5.3
        
9.2. Protocol in the Segment ID Sub-TLV
9.2. セグメントIDサブTLVのプロトコル

IANA has created a new "Protocol in the Segment ID sub-TLV" (see Section 5) registry under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action [RFC8126]. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:

IANAは、「Multi-Protocol Label Switching(MPLS)Label Switched Paths(LSPs)Ping Parameters」レジストリの下に、新しい「Segment ID sub-TLVのプロトコル」(セクション5を参照)レジストリを作成しました。 0〜250の範囲のコードポイントは、標準アクション[RFC8126]によって割り当てられます。 251〜254の範囲は実験用に予約されており、割り当てられません。 255の値は「予約済み」とマークされています。レジストリへの最初のエントリは次のとおりです。

     Value           Meaning              Reference
   ----------        ----------------     ------------
     0               Any IGP protocol     This document
     1               OSPF                 This document
     2               IS-IS                This document
        
9.3. Adjacency Type in the IGP-Adjacency Segment ID
9.3. IGP隣接セグメントIDの隣接タイプ

IANA has created a new "Adjacency Type in the IGP-Adjacency Segment ID" registry (see Section 5.3) under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:

IANAは、「Multi-Protocol Label Switching(MPLS)Label Switched Paths(LSPs)Ping Parameters」レジストリの下に、「IGP-Adjacency Segment IDの隣接タイプ」レジストリ(セクション5.3を参照)を作成しました。 0-250の範囲のコードポイントは、標準化アクションによって割り当てられます。 251〜254の範囲は実験用に予約されており、割り当てられません。 255の値は「予約済み」とマークされています。レジストリへの最初のエントリは次のとおりです。

     Value           Meaning
   ----------        ----------------
     0               Unnumbered Interface Adjacency
     1               Parallel Adjacency
     4               IPv4, Non-parallel Adjacency
     6               IPv6, Non-parallel Adjacency
        

9.4. Protocol in the Label Stack Sub-TLV of the Downstream Detailed Mapping TLV

9.4. ダウンストリーム詳細マッピングTLVのラベルスタックサブTLVのプロトコル

IANA has created a new "Protocol in the Label Stack sub-TLV of the Downstream Detailed Mapping TLV" registry under the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry. Code points in the range of 0-250 will be assigned by Standards Action. The range of 251-254 is reserved for experimental use and will not be assigned. The value of 255 is marked "Reserved". The initial entries into the registry are:

IANAは、「Multi-Protocol Label Switching(MPLS)Label Switched Paths(LSPs)Ping Parameters」レジストリの下に、新しい「Protocol in the Label Stack sub-TLV of the Downstream Detailed Mapping TLV」レジストリを作成しました。 0-250の範囲のコードポイントは、標準化アクションによって割り当てられます。 251〜254の範囲は実験用に予約されており、割り当てられません。 255の値は「予約済み」とマークされています。レジストリへの最初のエントリは次のとおりです。

     Value        Meaning              Reference
   ----------     ----------------     ------------
     0            Unknown              Section 3.4.1.2 of RFC 8029
     1            Static               Section 3.4.1.2 of RFC 8029
     2            BGP                  Section 3.4.1.2 of RFC 8029
     3            LDP                  Section 3.4.1.2 of RFC 8029
     4            RSVP-TE              Section 3.4.1.2 of RFC 8029
     5            OSPF                 Section 6 of this document
     6            IS-IS                Section 6 of this document
     7-250        Unassigned
     251-254      Reserved for
                  Experimental Use     This document
     255          Reserved             This document
        
9.5. Return Code
9.5. 戻りコード

IANA has assigned a new Return Code from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the 0-191 (Standards Action) range from the "Return Codes" subregistry.

IANAは、「マルチプロトコルラベルスイッチング(MPLS)ラベルスイッチドパス(LSP)Pingパラメーター」からの新しい戻りコードを、「戻りコード」サブレジストリの0〜191(標準アクション)の範囲で割り当てました。

     Value     Meaning                                  Reference
   ----------  -----------------                        ------------
     35        Mapping for this FEC is not associated   Section 7.4 of
               with the incoming interface              this document
        
10. Security Considerations
10. セキュリティに関する考慮事項

This document defines additional MPLS LSP Ping sub-TLVs and follows the mechanisms defined in [RFC8029]. All the security considerations defined in [RFC8029] will be applicable for this document and, in addition, they do not impose any additional security challenges to be considered.

このドキュメントは、追加のMPLS LSP PingサブTLVを定義し、[RFC8029]で定義されたメカニズムに従います。 [RFC8029]で定義されているすべてのセキュリティの考慮事項は、このドキュメントに適用可能であり、さらに、考慮すべき追加のセキュリティの課題を課すことはありません。

11. References
11. 参考文献
11.1. Normative References
11.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>。

[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.

[RFC3443] Agarwal、P。およびB. Akyol、「マルチプロトコルラベルスイッチング(MPLS)ネットワークでの存続時間(TTL)処理」、RFC 3443、DOI 10.17487 / RFC3443、2003年1月、<https:// www。 rfc-editor.org/info/rfc3443>。

[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.

[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング(GMPLS)をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。

[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.

[RFC5307] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング(GMPLS)をサポートするIS-IS拡張機能」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、<https://www.rfc-editor.org / info / rfc5307>。

[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.

[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、and M. Chen、 "Detecting Multiprotocol Label Switched(MPLS)Data-Plane Failures、" RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https://www.rfc-editor.org/info/rfc8029>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

11.2. Informative References
11.2. 参考引用

[IANA] IANA, "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <http://www.iana.org/assignments/ mpls-lsp-ping-parameters>.

[IANA] IANA、「Multi-Protocol Label Switching(MPLS)Label Switched Paths(LSPs)Ping Parameters」、<http://www.iana.org/assignments/ mpls-lsp-ping-parameters>。

[INTEROP] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", Work in Progress, draft-ietf-spring-segment-routing-ldp-interop-09, September 2017.

[INTEROP] Filsfils、C.、Previdi、S.、Bashandy、A.、Decraene、B。、およびS. Litkowski、「Segment Routing interworking with LDP」、Work in Progress、draft-ietf-spring-segment-routing- ldp-interop-09、2017年9月。

[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https:// www .rfc-editor.org / info / rfc8126>。

[SR] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-14, December 2017.

[SR] Filsfils、C.、Previdi、S.、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、Work in Progress、draft-ietf-spring-segment -routing-14、2017年12月。

[SR-IS-IS] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-15, December 2017.

[SR-IS-IS] Previdi、S.、Ginsberg、L.、Filsfils、C.、Bashandy、A.、Gredler、H.、Litkowski、S.、Decraene、B.、and J. Tantsura、 "IS- IS Extensions for Segment Routing」、作業中、draft-ietf-isis-segment-routing-extensions-15、2017年12月。

[SR-MPLS] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-11, October 2017.

[SR-MPLS] Filsfils、C.、Previdi、S.、Bashandy、A.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、作業中、ドラフト- ietf-spring-segment-routing-mpls-11、2017年10月。

[SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-24, December 2017.

[SR-OSPF] Psenak、P.、Previdi、S.、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W.、J。Tantsura、「OSPF Extensions for Segment Routing」、Work in進捗、draft-ietf-ospf-segment-routing-extensions-24、2017年12月。

[SR-OSPFV3] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-10, September 2017.

[SR-OSPFV3] Psenak、P.、Previdi、S.、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W.、J。Tantsura、「セグメントルーティング用のOSPFv3拡張機能」、作業進捗、draft-ietf-ospf-ospfv3-segment-routing-extensions-10、2017年9月。

Acknowledgements

謝辞

The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, Lizhong Jin, Tom Petch, Victor Ji, Mustapha Aissaoui, Tony Przygienda, Alexander Vainshtein, and Deborah Brungard for their review and comments.

著者は、Stefano Previdi、Les Ginsberg、Balaji Rajagopalan、Harish Sitaraman、Curtis Villamizar、Pranjal Dutta、Lizhong Jin、Tom Petch、Victor Ji、Mustapha Aissaoui、Tony Przygienda、Alexander Vainshtein、およびDeborah Brungardのコメントに感謝します。 。

The authors would like to thank Loa Andersson for his comments and recommendation to merge documents.

著者は、ドキュメントをマージするためのコメントと推奨事項を提供してくれたLoa Anderssonに感謝します。

Contributors

貢献者

The following are key contributors to this document:

このドキュメントの主な貢献者は次のとおりです。

Hannes Gredler, RtBrick, Inc. Tarek Saad, Cisco Systems, Inc. Siva Sivabalan, Cisco Systems, Inc. Balaji Rajagopalan, Juniper Networks Faisal Iqbal, Cisco Systems, Inc.

Hannes Gredler、RtBrick、Inc. Tarek Saad、Cisco Systems、Inc. Siva Sivabalan、Cisco Systems、Inc. Balaji Rajagopalan、Juniper Networks Faisal Iqbal、Cisco Systems、Inc.

Authors' Addresses

著者のアドレス

Nagendra Kumar (editor) Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America

Nagendra Kumar(編集者)Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709-4987アメリカ合衆国

   Email: naikumar@cisco.com
        

Carlos Pignataro (editor) Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709-4987 United States of America

Carlos Pignataro(編集者)Cisco Systems、Inc. 7200-11 Kit Creek Road Research Triangle Park、NC 27709-4987アメリカ合衆国

   Email: cpignata@cisco.com
        

George Swallow Southend Technical Center

ジョージスワローサウスエンドテクニカルセンター

   Email: swallow.ietf@gmail.com
        

Nobo Akiya Big Switch Networks

Nobo Akiya Big Switch Networks

   Email: nobo.akiya.dev@gmail.com
        

Sriganesh Kini Individual

Sriganesh Kini個人

   Email: sriganeshkini@gmail.com
        

Mach(Guoyi) Chen Huawei

マッハ(GUお一)陳湖Aは

   Email: mach.chen@huawei.com