[要約] RFC 8667は、セグメントルーティングのためのIS-IS拡張に関する規格であり、セグメントルーティングをサポートするためのIS-ISプロトコルの機能を拡張することを目的としています。
Internet Engineering Task Force (IETF) S. Previdi, Ed.
Request for Comments: 8667 Huawei Technologies
Category: Standards Track L. Ginsberg, Ed.
ISSN: 2070-1721 C. Filsfils
Cisco Systems, Inc.
A. Bashandy
Arrcus
H. Gredler
RtBrick Inc.
B. Decraene
Orange
December 2019
IS-IS Extensions for Segment Routing
セグメントルーティングのIS-IS拡張
Abstract
概要
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
セグメントルーティング（SR）では、パスを「セグメント」と呼ばれるトポロジサブパスのシーケンスとしてエンコードすることにより、IGPトポロジ内のエンドツーエンドパスを柔軟に定義できます。これらのセグメントは、リンクステートルーティングプロトコル（IS-ISおよびOSPF）によって通知されます。
This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.
このドキュメントでは、MPLSデータプレーンで動作するセグメントルーティングに導入する必要があるIS-IS拡張について説明します。
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/rfc8667.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8667で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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
1.1. Requirements Language
2. Segment Routing Identifiers
2.1. Prefix Segment Identifier (Prefix-SID) Sub-TLV
2.1.1. Flags
2.1.2. Prefix-SID Propagation
2.2. Adjacency Segment Identifier
2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV
2.2.2. Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV
2.3. SID/Label Sub-TLV
2.4. SID/Label Binding TLV
2.4.1. Flags
2.4.2. Range
2.4.3. Prefix Length, Prefix
2.4.4. Mapping Server Prefix-SID
2.4.5. SID/Label Sub-TLV
2.4.6. Example Encodings
2.5. Multi-Topology SID/Label Binding TLV
3. Router Capabilities
3.1. SR-Capabilities Sub-TLV
3.2. SR-Algorithm Sub-TLV
3.3. SR Local Block Sub-TLV
3.4. SRMS Preference Sub-TLV
4. IANA Considerations
4.1. Sub-TLVs for Types 22, 23, 25, 141, 222, and 223
4.2. Sub-TLVs for Types 135, 235, 236, and 237
4.3. Sub-TLVs for Type 242
4.4. New TLV Codepoint and Sub-TLV Registry
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-aware shortest path to a prefix (or a node), as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. SR's control plane can be applied to both IPv6 and MPLS data planes and does not require any additional signaling (other than the regular IGP). For example, when used in MPLS networks, SR paths do not require any LDP or RSVP-TE signaling. Still, SR can interoperate in the presence of Label Switched Paths (LSPs) established with RSVP or LDP.
セグメントルーティング（SR）では、パスを「セグメント」と呼ばれるトポロジサブパスのシーケンスとしてエンコードすることにより、IGPトポロジ内のエンドツーエンドパスを柔軟に定義できます。これらのセグメントは、リンクステートルーティングプロトコル（IS-ISおよびOSPF）によって通知されます。プレフィックスセグメントは、IGPトポロジの状態に従って、プレフィックス（またはノード）へのECMP対応の最短パスを表します。隣接セグメントは、IGP内の2つのノード間の特定の隣接上のホップを表します。プレフィックスセグメントは通常マルチホップパスですが、隣接セグメントはほとんどの場合、1ホップパスです。 SRのコントロールプレーンは、IPv6とMPLSの両方のデータプレーンに適用でき、追加のシグナリングを必要としません（通常のIGP以外）。たとえば、MPLSネットワークで使用する場合、SRパスはLDPまたはRSVP-TEシグナリングを必要としません。それでも、SRVPまたはLDPで確立されたラベルスイッチドパス（LSP）が存在する場合、SRは相互運用できます。
There are additional segment types, e.g., the Binding SID as defined in [RFC8402]. This document also defines an advertisement for one type of Binding SID: the Mirror Context segment.
[RFC8402]で定義されているバインディングSIDなど、追加のセグメントタイプがあります。このドキュメントでは、バインディングSIDの1種類であるミラーコンテキストセグメントの提供情報も定義しています。
This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.
このドキュメントでは、MPLSデータプレーンで動作するセグメントルーティングに導入する必要があるIS-IS拡張について説明します。
The Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855].
セグメントルーティングアーキテクチャは、[RFC8402]で説明されています。セグメントルーティングの使用例は、[RFC7855]で説明されています。
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]で説明されているように解釈されます。
The Segment Routing architecture [RFC8402] defines different types of Segment Identifiers (SIDs). This document defines the IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency Segment, the IGP-LAN-Adjacency Segment, and the Binding Segment.
セグメントルーティングアーキテクチャ[RFC8402]は、さまざまなタイプのセグメント識別子（SID）を定義しています。このドキュメントでは、IGPプレフィックスセグメント、IGP隣接セグメント、IGP-LAN隣接セグメント、およびバインディングセグメントのIS-ISエンコーディングを定義します。
A new IS-IS sub-TLV is defined: the Prefix Segment Identifier (Prefix-SID) sub-TLV.
新しいIS-ISサブTLVが定義されています。プレフィックスセグメント識別子（Prefix-SID）サブTLV。
The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [RFC8402]. The 'Prefix-SID' MUST be unique within a given IGP domain (when the L-Flag is not set).
[RFC8402]で定義されているように、Prefix-SIDサブTLVはセグメントルーティングIGP-Prefix-SIDを伝送します。 「プレフィックスSID」は、特定のIGPドメイン内で一意である必要があります（Lフラグが設定されていない場合）。
A Prefix-SID sub-TLV is associated to a prefix advertised by a node and MAY be present in any of the following TLVs:
Prefix-SIDサブTLVは、ノードによってアドバタイズされるプレフィックスに関連付けられており、次のTLVのいずれかに存在する場合があります。
TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
[RFC5305]で定義されているTLV-135（拡張IPv4到達可能性）。
TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120].
[RFC5120]で定義されているTLV-235（マルチトポロジIPv4到達可能性）。
TLV-236 (IPv6 IP Reachability) defined in [RFC5308].
[RFC5308]で定義されているTLV-236（IPv6 IP到達可能性）。
TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120].
[RFC5120]で定義されているTLV-237（マルチトポロジIPv6 IP到達可能性）。
The Binding TLV and Multi-Topology Binding TLV are defined in Sections 2.4 and 2.5, respectively.
Binding TLVおよびMulti-Topology Binding TLVは、それぞれセクション2.4および2.5で定義されています。
The Prefix-SID sub-TLV has the following format:
Prefix-SIDサブTLVの形式は次のとおりです。
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 | Length | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 3
タイプ：3
Length: 5 or 6 depending on the size of the SID (described below)
長さ：SIDのサイズに応じて5または6（以下で説明）
Flags: 1-octet field of the following flags:
フラグ：次のフラグの1オクテットフィールド：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|N|P|E|V|L| |
+-+-+-+-+-+-+-+-+
where:
ただし：
R-Flag: Re-advertisement Flag. If set, then the prefix to which this Prefix-SID is attached has been propagated by the router from either another level (i.e., from Level-1 to Level-2 or the opposite) or redistribution (e.g., from another protocol).
Rフラグ：再広告フラグ。設定されている場合、このPrefix-SIDがアタッチされているプレフィックスは、別のレベル（つまり、レベル1からレベル2またはその逆）または再配布（たとえば、別のプロトコル）からルーターによって伝達されています。
N-Flag: Node-SID Flag. If set, then the Prefix-SID refers to the router identified by the prefix. Typically, the N-Flag is set on Prefix-SIDs that are attached to a router loopback address. The N-Flag is set when the Prefix-SID is a Node-SID as described in [RFC8402].
Nフラグ：ノードSIDフラグ。設定されている場合、Prefix-SIDはプレフィックスで識別されるルーターを参照します。通常、N-Flagは、ルーターのループバックアドレスに接続されているPrefix-SIDに設定されます。 [RFC8402]で説明されているように、NフラグはPrefix-SIDがNode-SIDである場合に設定されます。
P-Flag: No-PHP (No Penultimate Hop-Popping) Flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering the packet to the node that advertised the Prefix-SID.
Pフラグ：PHPなし（最後から2番目のホップ飛びなし）フラグ。設定されている場合、最後から2番目のホップは、Prefix-SIDをアドバタイズしたノードにパケットを配信する前にPrefix-SIDをポップしてはなりません（MUST NOT）。
E-Flag: Explicit NULL Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID that has an Explicit NULL value (0 for IPv4 and 2 for IPv6) before forwarding the packet.
Eフラグ：明示的なNULLフラグ。設定されている場合、Prefix-SIDオリジネーターの上流ネイバーは、パケットを転送する前に、Prefix-SIDを明示的なNULL値（IPv4の場合は0、IPv6の場合は2）を持つPrefix-SIDに置き換える必要があります。
V-Flag: Value Flag. If set, then the Prefix-SID carries a value (instead of an index). By default, the flag is UNSET.
Vフラグ：値フラグ。設定されている場合、Prefix-SIDには（インデックスの代わりに）値が含まれます。デフォルトでは、フラグはUNSETです。
L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default, the flag is UNSET.
Lフラグ：ローカルフラグ。設定されている場合、Prefix-SIDによって運ばれる値/インデックスはローカルで重要です。デフォルトでは、フラグはUNSETです。
Other bits: MUST be zero when originated and ignored when received.
その他のビット：発生時はゼロで、受信時は無視する必要があります。
Algorithm: the router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Algorithm identifiers are defined in Section 3.2. Examples of these algorithms are metric-based Shortest Path First (SPF), various sorts of Constrained SPF, etc. The Algorithm field of the Prefix-SID contains the identifier of the algorithm the router uses to compute the reachability of the prefix to which the Prefix-SID is associated.
アルゴリズム：他のノードまたはこれらのノードに接続されているプレフィックスへの到達可能性を計算するときに、ルーターはさまざまなアルゴリズムを使用できます。アルゴリズム識別子はセクション3.2で定義されています。これらのアルゴリズムの例は、メトリックベースの最短パス優先（SPF）、さまざまな種類の制約付きSPFなどです。Prefix-SIDのAlgorithmフィールドには、ルーターが使用するプレフィックスの到達可能性を計算するために使用するアルゴリズムの識別子が含まれます。 Prefix-SIDが関連付けられています。
At origination, the Prefix-SID Algorithm field MUST be set to 0 or to any value advertised in the SR-Algorithm sub-TLV (see Section 3.2).
発信時に、Prefix-SID Algorithmフィールドは0またはSRアルゴリズムサブTLVでアドバタイズされた任意の値に設定する必要があります（セクション3.2を参照）。
A router receiving a Prefix-SID from a remote node and with an algorithm value that such remote node has not advertised in the SR-Algorithm sub-TLV (see Section 3.2) MUST ignore the Prefix-SID sub-TLV.
リモートノードからPrefix-SIDを受信し、そのようなリモートノードがSRアルゴリズムサブTLV（セクション3.2を参照）でアドバタイズしていないアルゴリズム値を持つルーターは、Prefix-SIDサブTLVを無視する必要があります。
SID/Index/Label as defined in Section 2.1.1.1.
セクション2.1.1.1で定義されているSID /インデックス/ラベル。
When the Prefix-SID is an index (and the V-Flag is not set), the value is used to determine the actual label value inside the set of all advertised label ranges of a given router. This allows a receiving router to construct the forwarding state to a particular destination router.
Prefix-SIDがインデックスの場合（およびV-Flagが設定されていない場合）、その値は、特定のルーターのすべてのアドバタイズされたラベル範囲のセット内の実際のラベル値を決定するために使用されます。これにより、受信ルータは特定の宛先ルータへの転送状態を構築できます。
In many use cases, a 'stable transport' address is overloaded as an identifier of a given node. Because Prefixes may be re-advertised into other levels, there may be some ambiguity (e.g., originating router vs. L1L2 router) for which node a particular IP prefix serves as the identifier. The Prefix-SID sub-TLV contains the necessary flags to disambiguate Prefix-to-node mappings. Furthermore, if a given node has several 'stable transport' addresses, there are flags to differentiate those among other Prefixes advertised from a given node.
多くの使用例では、「安定したトランスポート」アドレスが特定のノードの識別子としてオーバーロードされます。プレフィックスは他のレベルに再アドバタイズされる可能性があるため、特定のIPプレフィックスが識別子として機能するノードには、あいまいさ（発信元ルーターとL1L2ルーターなど）がある場合があります。 Prefix-SIDサブTLVには、Prefixからノードへのマッピングを明確にするために必要なフラグが含まれています。さらに、特定のノードに複数の「安定したトランスポート」アドレスがある場合、特定のノードからアドバタイズされる他のプレフィックス間でそれらを区別するためのフラグがあります。
The V-Flag indicates whether the SID/Index/Label field is a value or an index.
Vフラグは、SID /インデックス/ラベルフィールドが値かインデックスかを示します。
The L-Flag indicates whether the value/index in the SID/Index/Label field has local or global significance.
Lフラグは、SID /インデックス/ラベルフィールドの値/インデックスがローカルまたはグローバルのどちらの意味を持つかを示します。
The following settings for V-Flag and L-Flag are valid:
VフラグとLフラグの次の設定が有効です。
The V-Flag and L-Flag are set to 0: The SID/Index/Label field is a 4-octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1.
V-FlagとL-Flagは0に設定されます。SID/ Index / Labelフィールドは、セクション3.1で定義されたエンコーディングを使用してこのルーターによって通知されるSID / Labelスペースのオフセットを定義する4オクテットのインデックスです。
The V-Flag and L-Flag are set to 1: The SID/Index/Label field is a 3-octet local label where the 20 rightmost bits are used for encoding the label value.
VフラグとLフラグは1に設定されます。SID/インデックス/ラベルフィールドは3オクテットのローカルラベルで、右端の20ビットがラベル値のエンコードに使用されます。
All other combinations of V-Flag and L-Flag are invalid, and any SID advertisement received with an invalid setting for the V-Flag and L-Flag MUST be ignored.
V-FlagとL-Flagの他のすべての組み合わせは無効であり、V-FlagおよびL-Flagの無効な設定で受信されたSID通知はすべて無視する必要があります。
The R-Flag MUST be set for prefixes that are not local to the router and are advertised because of:
Rフラグは、ルーターに対してローカルではなく、次の理由でアドバタイズされるプレフィックスに設定する必要があります。
propagation (Level-1 into Level-2);
伝播（レベル1からレベル2）。
leaking (Level-2 into Level-1); or
漏洩（レベル2からレベル1へ）。または
redistribution (e.g., from another protocol).
再配布（たとえば、別のプロトコルから）。
In the case where a Level-1-2 router has local interface addresses configured in one level, it may also propagate these addresses into the other level. In such case, the Level-1-2 router MUST NOT set the R bit.
Level-1-2ルーターが1つのレベルで構成されたローカルインターフェイスアドレスを持っている場合、これらのアドレスを他のレベルに伝達することもできます。そのような場合、Level-1-2ルーターはRビットをセットしてはいけません（MUST NOT）。
The N-Flag is used in order to define a Node-SID. A router MAY set the N-Flag only if all of the following conditions are met:
N-FlagはNode-SIDを定義するために使用されます。ルーターは、次の条件がすべて満たされた場合にのみ、Nフラグを設定できます。
The prefix to which the Prefix-SID is attached is local to the router (i.e., the prefix is configured on one of the local interfaces, e.g., a 'stable transport' loopback).
Prefix-SIDが付加される接頭辞は、ルーターに対してローカルです（つまり、接頭辞は、「安定したトランスポート」ループバックなどのローカルインターフェースの1つで構成されます）。
The prefix to which the Prefix-SID is attached has a Prefix length of either /32 (IPv4) or /128 (IPv6).
Prefix-SIDが付加されるプレフィックスのプレフィックス長は、/ 32（IPv4）または/ 128（IPv6）です。
The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).
プレフィックスのプレフィックス長が/ 32（IPv4）または/ 128（IPv6）と異なる場合、ルーターは受信したプレフィックスSIDのNフラグを無視する必要があります。
The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and R-Flag and with the same semantics of the equivalent flags defined in this document. Whenever the Prefix Attribute Flags sub-TLV is present for a given prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be ignored.
Prefix Attribute Flags sub-TLV [RFC7794]もN-FlagおよびR-Flagを定義し、このドキュメントで定義されている同等のフラグと同じセマンティクスを使用します。特定のプレフィックスにプレフィックス属性フラグサブTLVが存在する場合は常に、そのサブTLVでアドバタイズされたNフラグとRフラグの値を使用する必要があり、対応するプレフィックスSIDサブTLVの値（存在する）無視する必要があります。
The following behavior is associated with the settings of the E-Flag and P-Flag:
次の動作は、EフラグとPフラグの設定に関連付けられています。
* If the P-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST pop the Prefix-SID. This is equivalent to the "penultimate hop-popping" mechanism used in the MPLS data plane, which improves performance of the ultimate hop. MPLS EXP bits of the Prefix-SID are not preserved to the ultimate hop (the Prefix-SID being removed). If the P-Flag is unset, the received E-Flag is ignored.
* P-Flagが設定されていない場合、Prefix-SID発信者の上流のネイバーはすべてPrefix-SIDをポップする必要があります。これは、MPLSデータプレーンで使用される「最後から2番目のホップポップ」メカニズムと同等であり、究極のホップのパフォーマンスを向上させます。 Prefix-SIDのMPLS EXPビットは、最終的なホップまで保持されません（Prefix-SIDは削除されます）。 Pフラグが設定されていない場合、受信したEフラグは無視されます。
* If the P-Flag is set, then:
* Pフラグが設定されている場合：
- If the E-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when, e.g., the originator of the Prefix-SID must stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an inter-area border router (prefix propagation from one area to another) or at an interdomain border router (prefix propagation from one domain to another).
- E-Flagが設定されていない場合、Prefix-SID発信元の上流のネイバーはすべて、Prefix-SIDをスタックの最上位に維持する必要があります。これは、たとえば、Prefix-SIDの発信者が着信パケットを継続的なMPLS LSPにステッチして最終宛先に送信する必要がある場合に役立ちます。これは、エリア間境界ルーター（あるエリアから別のエリアへのプレフィックス伝搬）またはドメイン間ボーダールーター（あるドメインから別のドメインへのプレフィックス伝搬）で発生する可能性があります。
- If the E-Flag is set, then any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with a Prefix-SID having an Explicit NULL value. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits.
- E-Flagが設定されている場合、Prefix-SID発信元の上流のネイバーは、Prefix-SIDを明示的なNULL値を持つPrefix-SIDに置き換える必要があります。これは、たとえば、Prefix-SIDの発信者が関連するプレフィックスの最終宛先であり、発信者が元のEXPビットを使用してパケットを受信する場合に便利です。
When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a reachability advertisement originated by another IS-IS speaker, the router MUST set the P-Flag and MUST clear the E-Flag of the related Prefix-SIDs.
（レベル1からレベル2またはレベル2からレベル1のいずれかに）伝播するとき、別のIS-ISスピーカーから発信された到達可能性アドバタイズメントは、ルータがPフラグを設定し、関連するEフラグをクリアする必要がありますプレフィックスSID。
The Prefix-SID sub-TLV MUST be included when the associated Prefix Reachability TLV is propagated across level boundaries.
関連するPrefix Reachability TLVがレベルの境界を越えて伝播される場合、Prefix-SIDサブTLVを含める必要があります。
The Level-1-2 router that propagates the Prefix-SID sub-TLV between levels maintains the content (flags and SID), except as noted in Sections 2.1.1.2 and 2.1.1.3.
セクション2.1.1.2および2.1.1.3に記載されている場合を除き、レベル間でPrefix-SIDサブTLVを伝播するLevel-1-2ルーターはコンテンツ（フラグとSID）を維持します。
A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj-SID) sub-TLV.
新しいIS-ISサブTLVが定義されています：隣接セグメント識別子（Adj-SID）サブTLV。
The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment Routing IGP-Adjacency-SID as defined in [RFC8402] with flags and fields that may be used, in future extensions of Segment Routing, for carrying other types of SIDs.
Adj-SIDサブTLVは、[RFC8402]で定義されているセグメントルーティングIGP-Adjacency-SIDを運ぶオプションのサブTLVであり、他のタイプのSIDを運ぶために、セグメントルーティングの将来の拡張で使用されるフラグとフィールドがあります。
IS-IS adjacencies are advertised using one of the IS Neighbor TLVs below:
IS-IS隣接関係は、以下のISネイバーTLVのいずれかを使用してアドバタイズされます。
TLV-22 (Extended IS reachability) [RFC5305]
TLV-22（拡張IS到達可能性）[RFC5305]
TLV-222 (MT-ISN) [RFC5120]
TLV-222（MT-ISN）[RFC5120]
TLV-23 (IS Neighbor Attribute) [RFC5311]
TLV-23（ISネイバー属性）[RFC5311]
TLV-223 (MT IS Neighbor Attribute) [RFC5311]
TLV-223（MT ISネイバー属性）[RFC5311]
TLV-141 (inter-AS reachability information) [RFC5316]
TLV-141（AS間到達可能性情報）[RFC5316]
Multiple Adj-SID sub-TLVs MAY be associated with a single IS Neighbor.
複数のAdj-SIDサブTLVを単一のISネイバーに関連付けることができます。
The following format is defined for the Adj-SID sub-TLV:
Adj-SIDサブTLVには次の形式が定義されています。
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 | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 31
タイプ：31
Length: 5 or 6 depending on size of the SID
長さ：SIDのサイズに応じて5または6
Flags: 1-octet field of the following flags:
フラグ：次のフラグの1オクテットフィールド：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+
where:
ただし：
F-Flag: Address-Family Flag. If unset, then the Adj-SID is used when forwarding IPv4-encapsulated traffic to the neighbor. If set, then the Adj-SID is used when forwarding IPv6-encapsulated traffic to the neighbor.
Fフラグ：アドレスファミリフラグ。設定されていない場合、IPv4カプセル化トラフィックをネイバーに転送するときにAdj-SIDが使用されます。設定されている場合、IPv6カプセル化トラフィックをネイバーに転送するときにAdj-SIDが使用されます。
B-Flag: Backup Flag. If set, the Adj-SID is eligible for protection (e.g., using IP Fast Reroute (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as described in [RFC8402].
Bフラグ：バックアップフラグ。 [RFC8402]で説明されているように、設定されている場合、Adj-SIDは保護の対象になります（たとえば、IP Fast Reroute（IPFRR）またはMPLS Fast Reroute（MPLS-FRR）を使用）。
V-Flag: Value Flag. If set, then the Adj-SID carries a value. By default, the flag is SET.
Vフラグ：値フラグ。設定されている場合、Adj-SIDには値が含まれます。デフォルトでは、フラグはSETです。
L-Flag: Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default, the flag is SET.
Lフラグ：ローカルフラグ。設定されている場合、Adj-SIDによって伝送される値/インデックスはローカルで重要です。デフォルトでは、フラグはSETです。
S-Flag: Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of adjacencies (and therefore MAY be assigned to other adjacencies as well).
Sフラグ：フラグを設定します。設定すると、S-Flagは、Adj-SIDが隣接のセットを参照することを示します（したがって、他の隣接にも割り当てられる場合があります）。
P-Flag: Persistent Flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap.
Pフラグ：永続的なフラグ。設定すると、PフラグはAdj-SIDが永続的に割り当てられることを示します。つまり、Adj-SID値は、ルーターの再起動やインターフェイスフラップ全体で一貫性を保ちます。
Other bits: MUST be zero when originated and ignored when received.
その他のビット：発生時はゼロで、受信時は無視する必要があります。
Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].
重量：1オクテット。この値は、負荷分散のためのAdj-SIDの重みを表します。重みの使用は[RFC8402]で定義されています。
SID/Index/Label as defined in Section 2.1.1.1.
セクション2.1.1.1で定義されているSID /インデックス/ラベル。
An SR-capable router MAY allocate an Adj-SID for each of its adjacencies.
SR対応ルーターは、隣接のそれぞれにAdj-SIDを割り当ててもよい（MAY）。
An SR-capable router MAY allocate more than one Adj-SID to an adjacency.
SR対応ルーターは、隣接に複数のAdj-SIDを割り当てることができます（MAY）。
An SR-capable router MAY allocate the same Adj-SID to different adjacencies.
SR対応ルーターは同じAdj-SIDを異なる隣接に割り当ててもよい（MAY）。
When the P-Flag is not set, the Adj-SID MAY be persistent. When the P-Flag is set, the Adj-SID MUST be persistent.
Pフラグが設定されていない場合、Adj-SIDは永続的である場合があります。 Pフラグが設定されている場合、Adj-SIDは永続的である必要があります。
Examples of Adj-SID sub-TLV use are described in [RFC8402].
Adj-SIDサブTLVの使用例は、[RFC8402]で説明されています。
The F-Flag is used in order for the router to advertise the outgoing encapsulation of the adjacency the Adj-SID is attached to.
F-Flagは、ルータがAdj-SIDが接続されている隣接の発信カプセル化をアドバタイズするために使用されます。
In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode LSP (PN LSP) including all neighbors of the DIS.
LANサブネットワークでは、指定中間システム（DIS）が選択され、DISのすべてのネイバーを含む疑似ノードLSP（PN LSP）を発信します。
When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors. Since, on LANs, each router only advertises one adjacency to the DIS (and doesn't advertise any other adjacency), each router advertises the set of Adj-SIDs (for each of its neighbors) inside a newly defined sub-TLV that is a part of the TLV advertising the adjacency to the DIS (e.g., TLV-22).
セグメントルーティングが使用される場合、LAN内の各ルーターは、各ネイバーのAdj-SIDを通知する場合があります。 LANでは、各ルーターは1つの隣接をDISにアドバタイズするだけで（他の隣接はアドバタイズしません）、各ルーターは新しく定義されたサブTLV内の（各ネイバーの）Adj-SIDのセットをアドバタイズします。 DISへの隣接をアドバタイズするTLVの一部（たとえば、TLV-22）。
The following new sub-TLV is defined: LAN Adjacency Segment Identifier (LAN-Adj-SID) containing the set of Adj-SIDs the router assigned to each of its LAN neighbors.
次の新しいサブTLVが定義されています。ルーターが各LANネイバーに割り当てたAdj-SIDのセットを含むLAN隣接セグメント識別子（LAN-Adj-SID）。
The format of the LAN-Adj-SID sub-TLV is as follows:
LAN-Adj-SIDサブTLVの形式は次のとおりです。
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 | Length | Flags | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID (ID length octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 32
タイプ：32
Length: Variable
長さ：可変
Flags: 1-octet field of the following flags:
フラグ：次のフラグの1オクテットフィールド：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|B|V|L|S|P| |
+-+-+-+-+-+-+-+-+
where the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P-Flag are defined in Section 2.2.1.
ここで、Fフラグ、Bフラグ、Vフラグ、Lフラグ、Sフラグ、およびPフラグは、セクション2.2.1で定義されています。
Other bits: MUST be zero when originated and ignored when received.
その他のビット：発生時はゼロで、受信時は無視する必要があります。
Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in [RFC8402].
重量：1オクテット。この値は、負荷分散のためのAdj-SIDの重みを表します。重みの使用は[RFC8402]で定義されています。
Neighbor System-ID: IS-IS System-ID of length "ID Length" as defined in [ISO10589].
隣接システムID：[ISO 10589]で定義されている長さ「IS長さ」のIS-ISシステムID。
SID/Index/Label: As defined in Section 2.1.1.1.
SID /インデックス/ラベル：セクション2.1.1.1で定義されています。
Multiple LAN-Adj-SID sub-TLVs MAY be encoded.
複数のLAN-Adj-SIDサブTLVがエンコードされる場合があります。
Note that this sub-TLV MUST NOT appear in TLV 141.
このサブTLVはTLV 141に表示されてはならないことに注意してください。
In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency to the DIS) can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be used, and all advertisements MUST have the same metric.
TLV-22、TLV-23、TLV-222、またはTLV-223（DISへの隣接の報告）に、LAN-Adj-SIDサブTLVのセット全体、隣接への複数の広告を含めることができない場合DISを使用する必要があり、すべての広告は同じメトリックを持つ必要があります。
Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each router in the LAN, is capable of reconstructing the LAN topology as well as the set of Adj-SIDs each router uses for each of its neighbors.
レベル内の各ルーターは、LAN内の各ルーターのDIS PN LSPと非PN LSPを受信することにより、LANトポロジーと、各ルーターがそのそれぞれに使用する一連のAdj-SIDを再構築できます。隣人。
The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs defined in this document:
SID /ラベルサブTLVは、このドキュメントで定義されている次のTLV /サブTLVに存在する場合があります。
SR-Capabilities sub-TLV (Section 3.1)
SR機能サブTLV（セクション3.1）
SR Local Block sub-TLV (Section 3.3)
SRローカルブロックサブTLV（セクション3.3）
SID/Label Binding TLV (Section 2.4)
SID /ラベルバインディングTLV（セクション2.4）
Multi-Topology SID/Label Binding TLV (Section 2.5)
マルチトポロジSID /ラベルバインディングTLV（セクション2.5）
Note that the codepoint used in all of the above cases is the SID/ Label sub-TLV codepoint specified in the new "sub-TLVs for TLV 149 and 150" registry created by this document.
上記のすべてのケースで使用されるコードポイントは、このドキュメントで作成された新しい「TLV 149および150のサブTLV」レジストリで指定されたSID /ラベルサブTLVコードポイントであることに注意してください。
The SID/Label sub-TLV contains a SID or an MPLS label. The SID/Label sub-TLV has the following format:
SID / LabelサブTLVには、SIDまたはMPLSラベルが含まれています。 SID / LabelサブTLVの形式は次のとおりです。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 1
タイプ：1
Length: 3 or 4
長さ：3または4
SID/Label: If the length is set to 3, then the 20 rightmost bits represent an MPLS label. If the length is set to 4, then the value is a 32-bit index.
SID /ラベル：長さが3に設定されている場合、右端の20ビットはMPLSラベルを表します。長さが4に設定されている場合、値は32ビットのインデックスです。
The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain. There are multiple uses of the SID/Label Binding TLV.
SID /ラベルバインディングTLVは、IS-ISドメイン内のルーターから発信される場合があります。 SID /ラベルバインディングTLVには複数の用途があります。
The SID/Label Binding TLV may be used to advertise prefixes to SID/ Label mappings. This functionality is called the Segment Routing Mapping Server (SRMS). The behavior of the SRMS is defined in [RFC8661].
SID /ラベルバインディングTLVを使用して、プレフィックスをSID /ラベルマッピングにアドバタイズできます。この機能は、セグメントルーティングマッピングサーバー（SRMS）と呼ばれます。 SRMSの動作は[RFC8661]で定義されています。
The SID/Label Binding TLV may also be used to advertise a Mirror SID indicating the ability of a node to process traffic originally destined to another IGP node. This behavior is defined in [RFC8402].
SID /ラベルバインディングTLVは、別のIGPノード宛てのトラフィックを処理するノードの能力を示すミラーSIDをアドバタイズするためにも使用できます。この振る舞いは[RFC8402]で定義されています。
The SID/Label Binding TLV has the following format:
SID /ラベルバインディングTLVの形式は次のとおりです。
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 | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range | Prefix Length | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 149
タイプ：149
Length: Variable
長さ：可変
Flags: 1 octet
フラグ：1オクテット
RESERVED: 1 octet (SHOULD be transmitted as 0 and MUST be ignored on receipt)
予約済み：1オクテット（0として送信する必要があり、受信時には無視する必要があります）
Range: 2 octets
範囲：2オクテット
Prefix Length: 1 octet
プレフィックス長：1オクテット
Prefix: 0-16 octets
プレフィックス：0-16オクテット
sub-TLVs, where each sub-TLV consists of a sequence of:
サブTLV。各サブTLVは次のシーケンスで構成されます。
- 1 octet of sub-TLV type
- サブTLVタイプの1オクテット
- 1 octet of length of the value field of the sub-TLV
- サブTLVの値フィールドの長さの1オクテット
- 0-243 octets of value
- 値の0〜243オクテット
Flags: 1-octet field of the following flags:
フラグ：次のフラグの1オクテットフィールド：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A| |
+-+-+-+-+-+-+-+-+
where:
ただし：
F-Flag: Address-Family Flag. If unset, then the prefix carries an IPv4 prefix. If set, then the prefix carries an IPv6 prefix.
Fフラグ：アドレスファミリフラグ。設定しない場合、プレフィックスはIPv4プレフィックスを持ちます。設定されている場合、プレフィックスにはIPv6プレフィックスが含まれます。
M-Flag: Mirror Context Flag. Set if the advertised SID corresponds to a mirrored context. The use of a mirrored context is described in [RFC8402].
Mフラグ：ミラーコンテキストフラグ。アドバタイズされたSIDがミラーリングされたコンテキストに対応する場合に設定します。ミラーリングされたコンテキストの使用については、[RFC8402]で説明されています。
S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing domain. If the S-Flag is not set, the SID/Label Binding TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sフラグ：設定されている場合、SID /ラベルバインディングTLVはルーティングドメイン全体にフラッディングする必要があります（SHOULD）。 Sフラグが設定されていない場合、SID /ラベルバインディングTLVがレベル間でリークされてはなりません。このビットは、TLVリーク中に変更してはなりません（MUST NOT）。
D-Flag: When the SID/Label Binding TLV is leaked from Level-2 to Level-1, the D-Flag MUST be set. Otherwise, this flag MUST be clear. SID/Label Binding TLVs with the D-Flag set MUST NOT be leaked from Level-1 to Level-2. This is to prevent TLV looping across levels.
Dフラグ：SID /ラベルバインディングTLVがレベル2からレベル1にリークされる場合、Dフラグを設定する必要があります。それ以外の場合、このフラグはクリアされている必要があります。 Dフラグが設定されたSID /ラベルバインディングTLVは、レベル1からレベル2にリークしてはなりません。これは、レベル間のTLVループを防ぐためです。
A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the A bit in order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV are directly connected to their originators. The mechanisms through which the originator of the SID/Label Binding TLV can figure out if a prefix is attached or not are outside the scope of this document (e.g., through explicit configuration). If the Binding TLV is leaked to other areas/levels, the A-Flag MUST be cleared.
Aフラグ：添付フラグ。 SID /ラベルバインディングTLVの発信者は、SID /ラベルバインディングTLVでアドバタイズされたプレフィックスとSIDが発信者に直接接続されていることを通知するために、Aビットを設定できます（MAY）。 SID /ラベルバインディングTLVの発信者が、接頭辞が付加されているかどうかがこのドキュメントの範囲外であるかどうかを確認できるメカニズム（明示的な構成など）。バインディングTLVが他のエリア/レベルにリークされている場合は、Aフラグをクリアする必要があります。
An implementation may decide not to honor the S-Flag in order to not leak Binding TLVs between levels (for policy reasons).
実装は、（ポリシー上の理由により）レベル間でバインディングTLVをリークしないために、Sフラグを尊重しないことを決定する場合があります。
Other bits: MUST be zero when originated and ignored when received.
その他のビット：発生時はゼロで、受信時は無視する必要があります。
The 'Range' field provides the ability to specify a range of addresses and their associated Prefix-SIDs. This advertisement supports the SRMS functionality. It is essentially a compression scheme to distribute a continuous prefix and their continuous, corresponding SID/Label Block. If a single SID is advertised, then the Range field MUST be set to one. For range advertisements > 1, the Range field MUST be set to the number of addresses that need to be mapped into a Prefix-SID. In either case, the prefix is the first address to which a SID is to be assigned.
「範囲」フィールドは、アドレスの範囲とそれに関連付けられたプレフィックスSIDを指定する機能を提供します。この提供情報はSRMS機能をサポートしています。これは本質的に、連続したプレフィックスとそれらの連続した対応するSID /ラベルブロックを配布するための圧縮方式です。単一のSIDがアドバタイズされる場合、Rangeフィールドは1に設定する必要があります。範囲アドバタイズメント> 1の場合、Rangeフィールドは、Prefix-SIDにマップする必要があるアドレスの数に設定する必要があります。どちらの場合も、プレフィックスはSIDが割り当てられる最初のアドレスです。
The 'Prefix' represents the Forwarding Equivalence Class at the tail end of the advertised path. The 'Prefix' does not need to correspond to a routable prefix of the originating node.
「プレフィックス」は、アドバタイズされたパスの末尾にある転送等価クラスを表します。 「プレフィックス」は、発信元ノードのルーティング可能なプレフィックスに対応する必要はありません。
The 'Prefix Length' field contains the length of the prefix in bits.
Only the most significant octets of the prefix are encoded (i.e., 1
octet for prefix length 1 up to 8, 2 octets for prefix length 9 to up
16, 3 octets for prefix length 17 up to 24, 4 octets for prefix
length 25 up to 32, ...., and 16 octets for prefix length 113 up to
128).
The Prefix-SID sub-TLV is defined in Section 2.1 and contains the SID/Index/Label value associated with the prefix and range. The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the M-Flag is clear. The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.
Prefix-SIDサブTLVはセクション2.1で定義されており、プレフィックスと範囲に関連付けられたSID /インデックス/ラベル値が含まれています。 Mフラグがクリアされている場合、Prefix-SIDサブTLVはSID /ラベルバインディングTLVに存在する必要があります。 Mフラグが設定されている場合、Prefix-SIDサブTLVは存在してはなりません。
The Prefix-SID Flags are defined in Section 2.1. The Mapping Server MAY advertise a mapping with the N-Flag set when the prefix being mapped is known in the link-state topology with a mask length of 32 (IPv4) or 128 (IPv6) and when the prefix represents a node. The mechanisms through which the operator defines that a prefix represents a node are outside the scope of this document (typically it will be through configuration).
Prefix-SIDフラグはセクション2.1で定義されています。マッピングサーバーは、マッピングされているプレフィックスがマスク長32（IPv4）または128（IPv6）のリンクステートトポロジで既知である場合、およびプレフィックスがノードを表す場合に、Nフラグセットを使用してマッピングをアドバタイズできます（MAY）。オペレーターが接頭辞がノードを表すことを定義するメカニズムは、このドキュメントの範囲外です（通常、構成によって行われます）。
The other flags defined in Section 2.1 are not used by the Mapping Server and MUST be ignored at reception.
セクション2.1で定義されている他のフラグはマッピングサーバーでは使用されず、受信時には無視する必要があります。
As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server Advertisement. However, if additional information is available, PHP behavior may safely be done. The required information consists of:
マッピングサーバーはプレフィックスアドバタイズメントの発信元を指定しないため、マッピングサーバーアドバタイズメントのみに基づいてPHPの動作を決定することはできません。ただし、追加情報が利用可能な場合、PHPの動作は安全に行われる可能性があります。必要な情報は次のとおりです。
* A prefix reachability advertisement for the prefix has been received, which includes the Prefix Attribute Flags sub-TLV [RFC7794].
* プレフィックスのプレフィックス到達可能性通知が受信されました。これには、プレフィックス属性フラグサブTLV [RFC7794]が含まれます。
* X-Flag and R-Flag are both set to 0 in the Prefix Attribute Flags sub-TLV.
* X-FlagとR-FlagはどちらもPrefix Attribute FlagsサブTLVで0に設定されています。
In the absence of a Prefix Attribute Flags sub-TLV [RFC7794], the A-Flag in the Binding TLV indicates that the originator of a prefix reachability advertisement is directly connected to the prefix; thus, PHP MUST be done by the neighbors of the router originating the prefix reachability advertisement. Note that the A-Flag is only valid in the original area in which the Binding TLV is advertised.
プレフィックス属性フラグサブTLV [RFC7794]がない場合、バインディングTLVのAフラグは、プレフィックス到達可能性アドバタイズメントの発信者がプレフィックスに直接接続されていることを示します。したがって、PHPは、プレフィックス到達可能性アドバタイズを発信するルータのネイバーによって実行される必要があります。 Aフラグは、Binding TLVがアドバタイズされる元のエリアでのみ有効であることに注意してください。
The Algorithm field contains the identifier of the algorithm associated with the SIDs for the prefix(es) in the range. Use of the Algorithm field is described in Section 2.1.
Algorithmフィールドには、範囲内のプレフィックスのSIDに関連付けられたアルゴリズムの識別子が含まれます。アルゴリズムフィールドの使用については、セクション2.1で説明します。
The SID/Label sub-TLV (Type: 1) contains the SID/Label value as defined in Section 2.3. It MUST be present in the SID/Label Binding TLV when the M-Flag is set in the Flags field of the parent TLV.
SID /ラベルサブTLV（タイプ：1）には、セクション2.3で定義されているSID /ラベル値が含まれています。 M-Flagが親TLVのFlagsフィールドで設定されている場合、SID /ラベルバインディングTLVに存在する必要があります。
Example 1: If the following IPv4 router addresses (loopback addresses) need to be mapped into the corresponding Prefix-SID indexes, then:
例1：次のIPv4ルーターアドレス（ループバックアドレス）を対応するPrefix-SIDインデックスにマップする必要がある場合：
Router-A: 192.0.2.1/32, Prefix-SID: Index 1
Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 192.0.2.3/32, Prefix-SID: Index 3
Router-D: 192.0.2.4/32, Prefix-SID: Index 4
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 | Length |0|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 32 | 192 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 1 |Prefix-SID Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Length| Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 2: If the following IPv4 prefixes need to be mapped into the corresponding Prefix-SID indexes, then:
例2：次のIPv4プレフィックスを対応するPrefix-SIDインデックスにマップする必要がある場合、次のようになります。
10.1.1/24, Prefix-SID: Index 51
10.1.1 / 24、Prefix-SID：インデックス51
10.1.2/24, Prefix-SID: Index 52
10.1.2 / 24、Prefix-SID：インデックス52
10.1.3/24, Prefix-SID: Index 53
10.1.3 / 24、Prefix-SID：インデックス53
10.1.4/24, Prefix-SID: Index 54
10.1.4 / 24、Prefix-SID：インデックス54
10.1.5/24, Prefix-SID: Index 55
10.1.5 / 24、Prefix-SID：インデックス55
10.1.6/24, Prefix-SID: Index 56
10.1.6 / 24、Prefix-SID：インデックス56
10.1.7/24, Prefix-SID: Index 57
10.1.7 / 24、Prefix-SID：インデックス57
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 | Length |0|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 7 | 24 | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |Prefix-SID Type| Sub-TLV Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 51 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example 3: If the following IPv6 prefixes need to be mapped into the corresponding Prefix-SID indexes, then:
例3：次のIPv6プレフィックスを対応するPrefix-SIDインデックスにマップする必要がある場合：
2001:db8:1/48, Prefix-SID: Index 151
2001:db8:2/48, Prefix-SID: Index 152
2001:db8:3/48, Prefix-SID: Index 153
2001:db8:4/48, Prefix-SID: Index 154
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 | Length |1|0|0|0|0| | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range = 4 | 48 | 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x0d | 0xb8 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 |Prefix-SID Type| Sub-TLV Length| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 151 |
+-+-+-+-+-+-+-+-+
It is not expected that a network operator will be able to keep fully continuous Prefix/SID/Index mappings. In order to support noncontinuous mapping ranges, an implementation MAY generate several instances of Binding TLVs.
ネットワークオペレータが完全に連続したプレフィックス/ SID /インデックスマッピングを維持できるとは考えられていません。非連続的なマッピング範囲をサポートするために、実装はバインディングTLVのいくつかのインスタンスを生成する場合があります。
For example, if a router wants to advertise the following ranges:
たとえば、ルーターが次の範囲をアドバタイズする場合は、
Range 16: { 192.0.2.1-15, Index 1-15 }
Range 6: { 192.0.2.22-27, Index 22-27 }
Range 41: { 192.0.2.44-84, Index 80-120 }
a router would need to advertise three instances of the Binding TLV.
ルータは、Binding TLVの3つのインスタンスをアドバタイズする必要があります。
The Multi-Topology SID/Label Binding TLV allows the support of Multi-Topology IS-IS (M-ISIS) as defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV has the same format as the SID/Label Binding TLV defined in Section 2.4 with the difference consisting of a Multi-topology Identifier (MT ID) as defined here below:
マルチトポロジSID /ラベルバインディングTLVは、[RFC5120]で定義されているマルチトポロジIS-IS（M-ISIS）のサポートを可能にします。マルチトポロジSID /ラベルバインディングTLVの形式は、セクション2.4で定義されたSID /ラベルバインディングTLVと同じですが、以下に定義するマルチトポロジ識別子（MT ID）で構成されている点が異なります。
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 | Length | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 150
タイプ：150
Length: Variable
長さ：可変
MT ID is the Multi-topology Identifier defined as:
MT IDは、次のように定義されたマルチトポロジ識別子です。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESVD | MT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RESVD: Reserved bits. MUST be reset on transmission and ignored on receive.
RESVD：予約ビット。送信時にリセットし、受信時に無視する必要があります。
MT ID: A 12-bit field containing the non-zero ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology.
MT ID：アナウンスされるトポロジのゼロ以外のIDを含む12ビットのフィールド。 IDがゼロの場合、TLVを無視する必要があります。これは、標準のユニキャストトポロジの一貫したビューを確保するためです。
The other fields and sub-TLVs are defined in Section 2.4.
その他のフィールドとサブTLVはセクション2.4で定義されています。
This section defines sub-TLVs that are inserted into the IS-IS Router Capability that is defined in [RFC7981].
このセクションでは、[RFC7981]で定義されているIS-ISルーター機能に挿入されるサブTLVを定義します。
Segment Routing requires each router to advertise its SR data plane capability and the range of MPLS label values it uses for Segment Routing in the case where global SIDs are allocated (i.e., global indexes). Data plane capabilities and label ranges are advertised using the newly defined SR-Capabilities sub-TLV.
セグメントルーティングでは、グローバルSIDが割り当てられている場合（グローバルインデックスなど）、各ルーターがSRデータプレーン機能とセグメントルーティングに使用するMPLSラベル値の範囲を通知する必要があります。データプレーン機能とラベル範囲は、新しく定義されたSR機能サブTLVを使用してアドバタイズされます。
The Router Capability TLV specifies flags that control its advertisement. The SR-Capabilities sub-TLV MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore, Router Capability TLV distribution flags are set accordingly, i.e., the S-Flag in the Router Capability TLV [RFC7981] MUST be unset.
ルーター機能TLVは、その通知を制御するフラグを指定します。 SR機能サブTLVは、レベル全体に伝播されなければならず、レベルの境界を越えて通知されてはなりません。したがって、ルーター機能TLV配布フラグはそれに応じて設定されます。つまり、ルーター機能TLV [RFC7981]のSフラグは設定解除する必要があります。
The SR-Capabilities sub-TLV has the following format:
SR機能サブTLVの形式は次のとおりです。
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 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2
タイプ：2
Length: Variable
長さ：可変
Flags: 1 octet of flags. The following are defined:
フラグ：フラグの1オクテット。以下が定義されています：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|V| |
+-+-+-+-+-+-+-+-+
where:
ただし：
I-Flag: MPLS IPv4 Flag. If set, then the router is capable of processing SR-MPLS-encapsulated IPv4 packets on all interfaces.
Iフラグ：MPLS IPv4フラグ。設定されている場合、ルータはすべてのインターフェイスでSR-MPLSカプセル化IPv4パケットを処理できます。
V-Flag: MPLS IPv6 Flag. If set, then the router is capable of processing SR-MPLS-encapsulated IPv6 packets on all interfaces.
Vフラグ：MPLS IPv6フラグ。設定すると、ルータはすべてのインターフェイスでSR-MPLSカプセル化IPv6パケットを処理できます。
One or more Segment Routing Global Block (SRGB) Descriptor entries, each of which have the following format:
1つ以上のセグメントルーティンググローバルブロック（SRGB）記述子エントリ。各エントリの形式は次のとおりです。
Range: 3 octets
範囲：3オクテット
SID/Label sub-TLV: MPLS label as defined in Section 2.3
SID / Label sub-TLV：セクション2.3で定義されているMPLSラベル
The SID/Label sub-TLV contains the first value of the SRGB while the range contains the number of SRGB elements. The range value MUST be higher than 0.
SID / LabelサブTLVにはSRGBの最初の値が含まれ、範囲にはSRGB要素の数が含まれます。範囲の値は0より大きくなければなりません。
The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SR-Capabilities sub-TLV. A router receiving multiple SR-Capabilities sub-TLVs from the same originator SHOULD select the first advertisement in the lowest-numbered LSP.
SR機能サブTLVは、任意の数のLSPでアドバタイズされてもかまいませんが、ルーターは複数のSR機能サブTLVをアドバタイズしてはいけません。同じ発信者から複数のSR機能サブTLVを受信するルーターは、最小番号のLSPの最初のアドバタイズを選択する必要があります（SHOULD）。
When multiple SRGB Descriptors are advertised, the entries define an ordered set of ranges on which a SID index is to be applied. For this reason, changing the order in which the descriptors are advertised will have a disruptive effect on forwarding.
複数のSRGB記述子がアドバタイズされる場合、エントリは、SIDインデックスが適用される順序付けされた範囲のセットを定義します。このため、記述子がアドバタイズされる順序を変更すると、転送に混乱が生じます。
When a router adds a new SRGB Descriptor to an existing SR-Capabilities sub-TLV, the new descriptor SHOULD add the newly configured block at the end of the sub-TLV and SHOULD NOT change the order of previously advertised blocks. Changing the order of the advertised descriptors will create label churn in the FIB and black hole / misdirect some traffic during the IGP convergence. In particular, if a range that is not the last is extended, it's preferable to add a new range rather than extending the previously advertised range.
ルータが既存のSR機能サブTLVに新しいSRGB記述子を追加する場合、新しい記述子はサブTLVの最後に新しく構成されたブロックを追加する必要があり（SHOULD）、以前にアドバタイズされたブロックの順序を変更してはなりません（SHOULD NOT）。アドバタイズされた記述子の順序を変更すると、FIBにラベルチャーンが作成され、IGP収束中に一部のトラフィックがブラックホール/誤った方向に向けられます。特に、最後ではない範囲が拡張される場合、以前にアドバタイズされた範囲を拡張するのではなく、新しい範囲を追加することをお勧めします。
The originating router MUST ensure the order is unchanged after a graceful restart (using checkpointing, non-volatile storage, or any other mechanism).
元のルーターは、（チェックポイント、不揮発性ストレージ、またはその他のメカニズムを使用して）グレースフルリスタート後に順序が変更されていないことを確認する必要があります。
The originating router MUST NOT advertise overlapping ranges.
発信元ルーターは、重複する範囲をアドバタイズしてはなりません。
When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [RFC8660].
ルータが複数の重複する範囲を受信するとき、それは[RFC8660]で定義された手順に適合しなければなりません。
Here follows an example of the advertisement of multiple ranges:
次に、複数の範囲のアドバタイズメントの例を示します。
The originating router advertises the following ranges:
発信元ルーターは次の範囲をアドバタイズします。
SR-Cap: range: 100, SID value: 100
SR-Cap: range: 100, SID value: 1000
SR-Cap: range: 100, SID value: 500
The receiving routers concatenate the ranges in the received order and build the SRGB as follows:
受信ルーターは、受信した順序で範囲を連結し、次のようにSRGBを構築します。
SRGB = [100, 199]
[1000, 1099]
[500, 599]
The indexes span multiple ranges:
インデックスは複数の範囲にまたがっています。
index 0 means label 100 ... index 99 means label 199 index 100 means label 1000 index 199 means label 1099 ... index 200 means label 500 ...
インデックス0はラベル100を意味します...インデックス99はラベル199を意味しますインデックス100はラベル1000を意味しますインデックス199はラベル1099を意味します...インデックス200はラベル500を意味します...
The router may use various algorithms when calculating reachability to other nodes or to prefixes attached to these nodes. Examples of these algorithms are metric-based SPF, various sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the router to advertise the algorithms that the router is currently using. Algorithm values are defined in the "IGP Algorithm Type" registry defined in [RFC8665]. The following values have been defined:
ルーターは、他のノードまたはこれらのノードに接続されているプレフィックスへの到達可能性を計算するときに、さまざまなアルゴリズムを使用できます。これらのアルゴリズムの例としては、メトリックベースのSPF、さまざまな種類の制約付きSPFなどがあります。SRアルゴリズムサブTLVを使用すると、ルーターは現在ルーターが使用しているアルゴリズムを通知できます。アルゴリズムの値は、[RFC8665]で定義されている「IGP Algorithm Type」レジストリで定義されています。以下の値が定義されています。
0: SPF algorithm based on link metric. This is the well-known shortest path algorithm as computed by the IS-IS Decision Process. Consistent with the deployed practice for link-state protocols, algorithm 0 permits any node to overwrite the SPF path with a different path based on local policy.
0：リンクメトリックに基づくSPFアルゴリズム。これは、IS-IS決定プロセスによって計算された既知の最短パスアルゴリズムです。リンクステートプロトコルの展開された慣例に従って、アルゴリズム0は、任意のノードがローカルポリシーに基づいて異なるパスでSPFパスを上書きすることを許可します。
1: Strict SPF algorithm based on link metric. The algorithm is identical to algorithm 0, but algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy MUST NOT alter the forwarding decision computed by algorithm 1 at the node claiming to support algorithm 1.
1：リンクメトリックに基づく厳密なSPFアルゴリズム。アルゴリズムはアルゴリズム0と同じですが、アルゴリズム1では、パスに沿ったすべてのノードがSPFルーティングの決定を受け入れる必要があります。ローカルポリシーは、アルゴリズム1をサポートすると主張するノードで、アルゴリズム1によって計算された転送決定を変更してはなりません（MUST NOT）。
The Router Capability TLV specifies flags that control its advertisement. The SR-Algorithm MUST be propagated throughout the level and MUST NOT be advertised across level boundaries. Therefore, Router Capability TLV distribution flags are set accordingly, i.e., the S-Flag MUST be unset.
ルーター機能TLVは、その通知を制御するフラグを指定します。 SRアルゴリズムはレベル全体に伝播されなければならず（MUST）、レベル境界を越えて通知されてはなりません（MUST NOT）。したがって、ルーター機能のTLV配布フラグはそれに応じて設定されます。つまり、Sフラグの設定を解除する必要があります。
The SR-Algorithm sub-TLV is optional. It MUST NOT be advertised more than once at a given level. A router receiving multiple SR-Algorithm sub-TLVs from the same originator SHOULD select the first advertisement in the lowest-numbered LSP.
SRアルゴリズムサブTLVはオプションです。特定のレベルで複数回アドバタイズしてはなりません。同じ発信者から複数のSRアルゴリズムサブTLVを受信するルーターは、最小番号のLSPの最初のアドバタイズを選択する必要があります（SHOULD）。
When the originating router does not advertise the SR-Algorithm sub-TLV, it implies that algorithm 0 is the only algorithm supported by the routers that support the extensions defined in this document.
発信ルータがSRアルゴリズムサブTLVをアドバタイズしない場合、アルゴリズム0が、このドキュメントで定義されている拡張機能をサポートするルータでサポートされている唯一のアルゴリズムであることを意味します。
When the originating router does advertise the SR-Algorithm sub-TLV, then algorithm 0 MUST be present while non-zero algorithms MAY be present.
発信元ルーターがSRアルゴリズムサブTLVをアドバタイズする場合、ゼロ以外のアルゴリズムが存在しても、アルゴリズム0が存在する必要があります。
The SR-Algorithm sub-TLV has the following format:
SRアルゴリズムサブTLVの形式は次のとおりです。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
ただし：
Type: 19
タイプ：19
Length: Variable
長さ：可変
Algorithm: 1 octet of algorithm
アルゴリズム：1オクテットのアルゴリズム
The SR Local Block (SRLB) sub-TLV contains the range of labels the node has reserved for Local SIDs. Local SIDs are used, e.g., for Adj-SIDs, and may also be allocated by components other than the IS-IS protocol. As an example, an application or a controller may instruct the router to allocate a specific Local SID. Therefore, in order for such applications or controllers to know what Local SIDs are available in the router, it is required that the router advertises its SRLB.
SRローカルブロック（SRLB）サブTLVには、ノードがローカルSID用に予約したラベルの範囲が含まれています。ローカルSIDは、たとえばAdj-SIDに使用され、IS-ISプロトコル以外のコンポーネントによって割り当てられる場合もあります。例として、アプリケーションまたはコントローラは、特定のローカルSIDを割り当てるようにルーターに指示する場合があります。したがって、このようなアプリケーションまたはコントローラーがルーターで使用可能なローカルSIDを認識するためには、ルーターがSRLBをアドバタイズする必要があります。
The SRLB sub-TLV is used for this purpose and has following format:
SRLBサブTLVはこの目的で使用され、次の形式になります。
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 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label Sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 22
タイプ：22
Length: Variable
長さ：可変
Flags: 1 octet of flags. None are defined at this stage.
フラグ：フラグの1オクテット。この段階では何も定義されていません。
One or more SRLB Descriptor entries, each of which have the following format:
1つ以上のSRLB記述子エントリ。各エントリの形式は次のとおりです。
Range: 3 octets
範囲：3オクテット
SID/Label sub-TLV: MPLS label as defined in Section 2.3
SID / Label sub-TLV：セクション2.3で定義されているMPLSラベル
The SID/Label sub-TLV contains the first value of the SRLB while the range contains the number of SRLB elements. The range value MUST be higher than 0.
SID / LabelサブTLVにはSRLBの最初の値が含まれ、範囲にはSRLB要素の数が含まれます。範囲の値は0より大きくなければなりません。
The SRLB sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SRLB sub-TLV. A router receiving multiple SRLB sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest-numbered LSP.
SRLBサブTLVは任意の数のLSPでアドバタイズできますが、ルータは複数のSRLBサブTLVをアドバタイズしてはなりません。同じ発信者から複数のSRLBサブTLVを受信するルーターは、最小番号のLSPの最初の通知を選択する必要があります（SHOULD）。
The originating router MUST NOT advertise overlapping ranges.
発信元ルーターは、重複する範囲をアドバタイズしてはなりません。
When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [RFC8660].
ルータが複数の重複する範囲を受信するとき、それは[RFC8660]で定義された手順に適合しなければなりません。
It is important to note that each time a SID from the SRLB is allocated, it should also be reported to all components (e.g., controller or applications) in order for these components to have an up-to-date view of the current SRLB allocation and to avoid collision between allocation instructions.
SRLBからのSIDが割り当てられるたびに、これらのコンポーネントが現在のSRLB割り当ての最新のビューを持つために、すべてのコンポーネント（たとえば、コントローラーまたはアプリケーション）にも報告する必要があることに注意することが重要です割り当て命令間の衝突を避けるため。
Within the context of IS-IS, the reporting of Local SIDs is done through IS-IS sub-TLVs such as the Adj-SID. However, the reporting of allocated Local SIDs may also be done through other means and protocols that are outside the scope of this document.
IS-ISのコンテキスト内では、ローカルSIDのレポートは、Adj-SIDなどのIS-ISサブTLVを通じて行われます。ただし、割り当てられたローカルSIDの報告は、このドキュメントの範囲外である他の手段やプロトコルを使用して行うこともできます。
A router advertising the SRLB sub-TLV may also have other label ranges, outside the SRLB, for its local allocation purposes that are NOT advertised in the SRLB. For example, it is possible that an Adj-SID is allocated using a local label not part of the SRLB.
SRLBサブTLVをアドバタイズするルータには、SRLBでアドバタイズされないローカル割り当ての目的で、SRLBの外に他のラベル範囲がある場合もあります。たとえば、SRLBの一部ではないローカルラベルを使用してAdj-SIDが割り当てられる可能性があります。
The SRMS Preference sub-TLV is used in order to associate a preference with SRMS advertisements from a particular source.
SRMSプリファレンスサブTLVは、プリファレンスを特定のソースからのSRMSアドバタイズに関連付けるために使用されます。
The SRMS Preference sub-TLV has the following format:
SRMS設定サブTLVの形式は次のとおりです。
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 | Length | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 24
タイプ：24
Length: 1
長さ：1
Preference: 1 octet and unsigned 8-bit SRMS preference.
設定：1オクテットで符号なし8ビットSRMS設定。
The SRMS Preference sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise more than one SRMS Preference sub-TLV. A router receiving multiple SRMS Preference sub-TLVs, from the same originator, SHOULD select the first advertisement in the lowest-numbered LSP.
SRMSプリファレンスサブTLVは任意の数のLSPでアドバタイズできますが、ルータは複数のSRMSプリファレンスサブTLVをアドバタイズしてはなりません。同じ発信者から複数のSRMS設定サブTLVを受信するルーターは、最小番号のLSPの最初の通知を選択する必要があります（SHOULD）。
The use of the SRMS preference during the SID selection process is described in [RFC8661].
SID選択プロセス中のSRMSプリファレンスの使用については、[RFC8661]で説明されています。
Per this document, IANA has allocated the following TLVs and sub-TLVs.
このドキュメントに従って、IANAは次のTLVとサブTLVを割り当てました。
This document makes the following registrations in the "Sub-TLVs for TLV 22, 23, 25, 141, 222, and 223" registry.
このドキュメントは、「TLV 22、23、25、141、222、および223のサブTLV」レジストリに次の登録を行います。
+------+--------------------+----+----+----+-----+-----+-----+
| Type | Description | 22 | 23 | 25 | 141 | 222 | 223 |
+======+====================+====+====+====+=====+=====+=====+
| 31 | Adjacency Segment | y | y | n | y | y | y |
| | Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
| 32 | LAN Adjacency | y | y | n | y | y | y |
| | Segment Identifier | | | | | | |
+------+--------------------+----+----+----+-----+-----+-----+
Table 1
表1
This document makes the following registrations in the "Sub-TLVs for TLV 135, 235, 236, and 237" registry.
このドキュメントは、「TLV 135、235、236、および237のサブTLV」レジストリに次の登録を行います。
+------+---------------------------+-----+-----+-----+-----+
| Type | Description | 135 | 235 | 236 | 237 |
+======+===========================+=====+=====+=====+=====+
| 3 | Prefix Segment Identifier | y | y | y | y |
+------+---------------------------+-----+-----+-----+-----+
Table 2
表2
This document makes the following registrations in the "Sub-TLVs for TLV 242" registry.
このドキュメントでは、「TLV 242のサブTLV」レジストリに次の登録を行います。
+------+------------------------------------+
| Type | Description |
+======+====================================+
| 2 | Segment Routing Capability |
+------+------------------------------------+
| 19 | Segment Routing Algorithm |
+------+------------------------------------+
| 22 | Segment Routing Local Block (SRLB) |
+------+------------------------------------+
| 24 | Segment Routing Mapping Server |
| | Preference (SRMS Preference) |
+------+------------------------------------+
Table 3
表3
This document registers the following TLV:
このドキュメントには、次のTLVが登録されています。
+-------+----------------------------+-----+-----+-----+-------+
| Value | Name | IIH | LSP | SNP | Purge |
+=======+============================+=====+=====+=====+=======+
| 149 | Segment Identifier / Label | n | y | n | n |
| | Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
| 150 | Multi-Topology Segment | n | y | n | n |
| | Identifier / Label Binding | | | | |
+-------+----------------------------+-----+-----+-----+-------+
Table 4
表4
This document creates the following sub-TLV Registry:
このドキュメントは、次のサブTLVレジストリを作成します。
Name: Sub-TLVs for TLVs 149 and 150
Name: Sub-TLVs for TLVs 149 and 150
Registration Procedure: Expert Review [RFC8126]
登録手順：専門家によるレビュー[RFC8126]
+-------+---------------------------+
| Type | Description |
+=======+===========================+
| 0 | Reserved |
+-------+---------------------------+
| 1 | SID/Label |
+-------+---------------------------+
| 2 | Unassigned |
+-------+---------------------------+
| 3 | Prefix Segment Identifier |
+-------+---------------------------+
| 4-255 | Unassigned |
+-------+---------------------------+
Table 5
表5
With the use of the extensions defined in this document, IS-IS carries information that will be used to program the MPLS data plane [RFC3031]. In general, the same type of attacks that can be carried out on the IP/IPv6 control plane can be carried out on the MPLS control plane, resulting in traffic being misrouted in the respective data planes. However, the latter may be more difficult to detect and isolate.
IS-ISは、このドキュメントで定義されている拡張機能を使用して、MPLSデータプレーン[RFC3031]のプログラミングに使用される情報を伝達します。一般に、IP / IPv6コントロールプレーンで実行できるのと同じタイプの攻撃をMPLSコントロールプレーンで実行できるため、それぞれのデータプレーンでトラフィックが誤ってルーティングされます。ただし、後者を検出して分離するのはより難しい場合があります。
Existing security extensions as described in [RFC5304] and [RFC5310] apply to these Segment Routing extensions.
[RFC5304]および[RFC5310]で説明されている既存のセキュリティ拡張機能は、これらのセグメントルーティング拡張機能に適用されます。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISO 8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[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., "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>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<https://www.rfc-editor.org/info/rfc5120>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<https://www.rfc-editor.org/info/rfc5304>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC7794] Ginsberg、L.、Ed。、Decraene、B.、Previdi、S.、Xu、X。、およびU. Chunduri、「拡張IPv4およびIPv6到達可能性のためのIS-ISプレフィックス属性」、RFC 7794、DOI 10.17487 / RFC7794、2016年3月、<https://www.rfc-editor.org/info/rfc7794>。
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <https://www.rfc-editor.org/info/rfc7981>.
[RFC7981] Ginsberg、L.、Previdi、S。、およびM. Chen、「IS-IS Extensions for Advertising Router Information」、RFC 7981、DOI 10.17487 / RFC7981、2016年10月、<https：//www.rfc-editor .org / info / rfc7981>。
[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., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8660] Bashandy、A。、編、Filsfils、C。、編、Previdi、S.、Decraene、B.、Litkowski、S。、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC 8660、DOI 10.17487 / RFC8660、2019年12月、<https://www.rfc-editor.org/info/rfc8660>。
[RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing MPLS Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, December 2019, <https://www.rfc-editor.org/info/rfc8661>.
[RFC8661] Bashandy、A.、Ed。、Filsfils、C.、Ed。、Previdi、S.、Decraene、B.、and S. Litkowski、 "Segment Routing MPLS Interworking with LDP"、RFC 8661、DOI 10.17487 / RFC8661 、2019年12月、<https://www.rfc-editor.org/info/rfc8661>。
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, <https://www.rfc-editor.org/info/rfc8665>.
[RFC8665] Psenak、P。、編、Previdi、S。、編、Filsfils、C.、Gredler、H.、Shakir、R.、Henderickx、W。、およびJ. Tantsura、「セグメントルーティングのOSPF拡張"、RFC 8665、DOI 10.17487 / RFC8665、2019年12月、<https://www.rfc-editor.org/info/rfc8665>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<https://www.rfc-editor.org/info/rfc5305> 。
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, <https://www.rfc-editor.org/info/rfc5308>.
[RFC5308] Hopps、C。、「Routing IPv6 with IS-IS」、RFC 5308、DOI 10.17487 / RFC5308、2008年10月、<https://www.rfc-editor.org/info/rfc5308>。
[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, <https://www.rfc-editor.org/info/rfc5311>.
[RFC5311] McPherson、D.、Ed。、Ginsberg、L.、Previdi、S。、およびM. Shand、「IS-ISのリンク状態PDU（LSP）スペースの簡易拡張」、RFC 5311、DOI 10.17487 / RFC5311 、2009年2月、<https://www.rfc-editor.org/info/rfc5311>。
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5316] Chen、M.、Zhang、R。、およびX. Duan、「Inter-Autonomous System（AS）MPLSおよびGMPLSトラフィックエンジニアリングをサポートするISIS拡張機能」、RFC 5316、DOI 10.17487 / RFC5316、2008年12月、< https://www.rfc-editor.org/info/rfc5316>。
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7855] Previdi、S.、Ed。、Filsfils、C.、Ed。、Decraene、B.、Litkowski、S.、Horneffer、M.、and R. Shakir、 "Source Packet Routing in Networking（SPRING）Problem Statementおよび要件」、RFC 7855、DOI 10.17487 / RFC7855、2016年5月、<https://www.rfc-editor.org/info/rfc7855>。
[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] 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>.
Acknowledgements
謝辞
We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre Francois, and Jesper Skrivers for their contribution to the content of this document.
このドキュメントの内容に貢献してくれたDave Ward、Dan Frost、Stewart Bryant、Pierre Francois、Jesper Skriversに感謝します。
Contributors
貢献者
The following people gave a substantial contribution to the content of this document and should be considered as coauthors:
次の人々は、このドキュメントの内容にかなりの貢献をしており、共著者と見なされるべきです：
Stephane Litkowski Orange France Email: stephane.litkowski@orange.com
ステファンリトコウスキーオレンジフランスメール：stephane.litkowski@orange.com
Jeff Tantsura Apstra, Inc. Email: jefftant@gmail.com
Jeff Tantsura Apstra、Inc.メール：jefftant@gmail.com
Peter Psenak Cisco Systems Inc. United States of America Email: ppsenak@cisco.com
Peter Psenak Cisco Systems Inc.アメリカ合衆国メール：ppsenak@cisco.com
Martin Horneffer Deutsche Telekom Germany Email: Martin.Horneffer@telekom.de
Martin Horneffer Deutsche Telekom Germany Email: Martin.Horneffer@telekom.de
Wim Henderickx Nokia Belgium Email: wim.henderickx@nokia.com
Wim Henderickx Nokia Belgium Email：wim.henderickx@nokia.com
Edward Crabbe Oracle United States of America Email: edward.crabbe@oracle.com
Edward Crabbe Oracle United States of America Eメール：edward.crabbe@oracle.com
Rob Shakir Google United Kingdom Email: robjs@google.com
Rob Shakir Googleイギリスメール：robjs@google.com
Igor Milojevic Individual Serbia Email: milojevicigor@gmail.com
Igor Milojevic個人セルビアメール：milojevicigor@gmail.com
Saku Ytti TDC Finland Email: saku@ytti.fi
Saku Ytti TDC Finland Email: saku@ytti.fi
Authors' Addresses
著者のアドレス
Stefano Previdi (editor) Huawei Technologies Italy
Stefano Previdi (editor) Huawei Technologies Italy
Email: stefano@previdi.net
Les Ginsberg (editor) Cisco Systems, Inc. United States of America
Les Ginsberg（編集者）Cisco Systems、Inc.アメリカ合衆国
Email: ginsberg@cisco.com
Clarence Filsfils Cisco Systems, Inc. Brussels Belgium
Clarence Filsfils Cisco Systems, Inc. Brussels Belgium
Email: cfilsfil@cisco.com
Ahmed Bashandy Arrcus
アーメドバシャンドフォーカス
Email: abashandy.ietf@gmail.com
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com
Bruno Decraene Orange France
Bruno Decraene Orange France
Email: bruno.decraene@orange.com