[要約] RFC 8320は、最大冗長ツリーをサポートするためのLDP拡張に関するものです。このRFCの目的は、ネットワークの信頼性と冗長性を向上させるために、LDPプロトコルに最大冗長ツリーのサポートを追加することです。
Internet Engineering Task Force (IETF) A. Atlas
Request for Comments: 8320 K. Tiruveedhula
Category: Standards Track C. Bowers
ISSN: 2070-1721 Juniper Networks
J. Tantsura
Individual
IJ. Wijnands
Cisco Systems, Inc.
February 2018
LDP Extensions to Support Maximally Redundant Trees
最大冗長ツリーをサポートするLDP拡張機能
Abstract
概要
This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR".
このドキュメントでは、最大配布ツリー（MRT）のラベルスイッチドパス（LSP）の作成をサポートするラベル配布プロトコル（LDP）の拡張について説明します。 MRTの主な用途は、ユニキャストおよびマルチキャストIP / LDP高速リルートであり、これを「MRT-FRR」と呼びます。
The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability.
LDPへの唯一のプロトコル拡張は、単にMRT機能をアドバタイズする機能です。このドキュメントでは、その拡張機能と、MRT機能をアドバタイズするラベルスイッチングルーター（LSR）およびラベルエッジルーター（LER）に期待される関連動作について説明します。
MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.
MRT-FRRはLDPマルチトポロジ拡張を使用するため、3つのマルチトポロジIDがMPLS MT-IDスペースから割り当てられています。
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/rfc8320.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8320で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 6
4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 6
4.1.1. Interaction of MRT Capability and MT Capability . . . 7
4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 8
4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 8
4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 8
4.4. Interaction of MRT-Related LDP Advertisements with the
MRT Topology and Computations . . . . . . . . . . . . . . 9
5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 10
5.1. MRT-Specific Behavior . . . . . . . . . . . . . . . . . . 10
5.1.1. ABR Behavior and Use of the Rainbow FEC . . . . . . . 10
5.1.2. Proxy-Node Attachment Router Behavior . . . . . . . . 11
5.2. LDP Protocol Procedures in the Context of MRT Label
Distribution . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. LDP Peer in RFC 5036 . . . . . . . . . . . . . . . . 12
5.2.2. Next Hop in RFC 5036 . . . . . . . . . . . . . . . . 13
5.2.3. Egress LSR in RFC 5036 . . . . . . . . . . . . . . . 13
5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence
Requirements in RFC 5036 . . . . . . . . . . . . . . 15
5.2.5. Validating FECs in the Routing Table . . . . . . . . 15
5.2.6. Recognizing New FECs . . . . . . . . . . . . . . . . 15
5.2.7. Not Propagating Rainbow FEC Label Mappings . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Potential Restrictions on MRT-Related MT-ID Values Imposed by
RFC 6420 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document describes the LDP signaling extensions and associated behavior necessary to support the architecture that defines how IP/ LDP Fast Reroute can use MRTs [RFC7812]. The current document provides a brief description of the MRT-FRR architecture, focusing on the aspects most directly related to LDP signaling. The complete description and specification of the MRT-FRR architecture can be found in [RFC7812].
このドキュメントでは、LDPシグナリング拡張機能と、IP / LDP高速リルートでMRTを使用する方法を定義するアーキテクチャをサポートするために必要な関連動作について説明します[RFC7812]。現在のドキュメントでは、MRT-FRRアーキテクチャの簡単な説明を提供し、LDPシグナリングに最も直接関連する側面に焦点を当てています。 MRT-FRRアーキテクチャの完全な説明と仕様は、[RFC7812]にあります。
At least one common standardized algorithm (e.g., the MRT Lowpoint algorithm explained and fully documented in [RFC7811]) is required to be deployed so that the routers supporting MRT computation consistently compute the same MRTs. LDP depends on an IGP for computation of MRTs and alternates. Extensions to OSPF are defined in [OSPF-MRT]. Extensions to IS-IS are defined in [IS-IS-MRT].
MRT計算をサポートするルーターが一貫して同じMRTを計算できるように、少なくとも1つの一般的な標準化アルゴリズム（たとえば、[RFC7811]で説明および完全に文書化されているMRTローポイントアルゴリズム）を展開する必要があります。 LDPは、MRTおよび代替の計算をIGPに依存しています。 OSPFの拡張は[OSPF-MRT]で定義されています。 IS-ISの拡張は[IS-IS-MRT]で定義されています。
MRT can also be used to protect multicast traffic (signaled via PIM or Multipoint LDP (mLDP)) using either global protection or local protection as described in [ARCH]. An MRT path can be used to provide node-protection for mLDP traffic via the mechanisms described in [RFC7715]; an MRT path can also be used to provide link protection for mLDP traffic.
MARCは、[ARCH]で説明されているように、グローバル保護またはローカル保護のいずれかを使用して、マルチキャストトラフィック（PIMまたはマルチポイントLDP（mLDP）で通知）を保護するためにも使用できます。 MRTパスを使用して、[RFC7715]で説明されているメカニズムを介してmLDPトラフィックのノード保護を提供できます。 MRTパスを使用して、mLDPトラフィックにリンク保護を提供することもできます。
For each destination, IP/LDP Fast Reroute with MRT (MRT-FRR) creates two alternate destination-based trees separate from the shortest-path forwarding used during stable operation. LDP uses the multi-topology extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) for these two sets of forwarding trees, MRT-Blue and MRT-Red.
各宛先について、MRTを使用したIP / LDP高速リルート（MRT-FRR）は、安定した動作中に使用される最短パス転送とは別の2つの代替宛先ベースのツリーを作成します。 LDPはマルチトポロジ拡張[RFC7307]を使用して、MRT-BlueとMRT-Redの2つの転送ツリーセットの転送等価クラス（FEC）に信号を送ります。
In order to create MRT paths and support IP/LDP Fast Reroute, a new capability extension is needed for LDP. An LDP implementation supporting MRT MUST also follow the rules described here for originating and managing FECs related to MRT, as indicated by their multi-topology ID. Network reconvergence is described in [RFC7812] and the worst-case network convergence time can be flooded via the extension in [PARAM-SYNC].
MRTパスを作成してIP / LDP Fast Rerouteをサポートするには、LDPに新しい機能拡張が必要です。 MRTをサポートするLDP実装は、マルチトポロジIDで示されているように、MRTに関連するFECを生成および管理するためにここで説明されているルールにも従う必要があります。ネットワークの再収束については[RFC7812]で説明されており、最悪の場合のネットワーク収束時間は[PARAM-SYNC]の拡張機能によってフラッディングされる可能性があります。
IP/LDP Fast Reroute using MRTs can provide 100% coverage for link and node failures in an arbitrary network topology where the failure doesn't partition the network. It can also be deployed incrementally; an MRT Island is formed of connected supporting routers and the MRTs are computed inside that island.
MRTを使用したIP / LDP高速リルートは、障害がネットワークを分割しない任意のネットワークトポロジにおけるリンクおよびノードの障害に対して100％のカバレッジを提供できます。また、段階的に展開することもできます。 MRTアイランドは接続されたサポートルーターで構成され、MRTはそのアイランド内で計算されます。
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]で説明されているように解釈されます。
For ease of reading, some of the terminology defined in [RFC7812] is repeated here. Please refer to Section 3 of [RFC7812] for a more complete list.
読みやすくするために、[RFC7812]で定義されている用語の一部がここで繰り返されています。より完全なリストについては、[RFC7812]のセクション3を参照してください。
Redundant Trees (RTs): A pair of trees where the path from any node X to the root R along the first tree is node-disjoint with the path from the same node X to the root along the second tree. Redundant trees can always be computed in 2-connected graphs.
冗長ツリー（RT）：最初のツリーに沿った任意のノードXからルートRへのパスが、同じノードXから2番目のツリーに沿ったルートへのパスとノード分離しているツリーのペア。冗長ツリーは常に2連結グラフで計算できます。
Maximally Redundant Trees (MRTs): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. In graphs that are not 2-connected, it is not possible to compute RTs. However, it is possible to compute MRTs. MRTs are maximally redundant in the sense that they are as redundant as possible given the constraints of the network graph.
最大冗長ツリー（MRT）：最初のツリーに沿った任意のノードXからルートRへのパスと、2番目のツリーに沿った同じノードXからルートへのパスが最小数のノードと最小値を共有するツリーのペアリンクの数。このような各共有ノードはカット頂点です。共有リンクはすべてカットリンクです。 2連結でないグラフでは、RTを計算することはできません。ただし、MRTを計算することは可能です。 MRTは、ネットワークグラフの制約を考慮して、可能な限り冗長であるという意味で、最大限に冗長です。
MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used to describe the associated forwarding topology and MPLS Multi-Topology Identifier (MT-ID).
MRT-Red：MRT-Redは、2つのMRTの1つを表すために使用されます。関連する転送トポロジとMPLSマルチトポロジ識別子（MT-ID）を記述するために使用されます。
MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MPLS MT-ID.
MRT-Blue：MRT-Blueは、2つのMRTの1つを表すために使用されます。関連する転送トポロジとMPLS MT-IDを説明するために使用されます。
Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the multiple MRT forwarding topologies and to the default forwarding topology. This is referred to as the "Rainbow MRT MPLS MT-ID" and is used by LDP to reduce signaling and permit the same label to always be advertised to all peers for the same (MT-ID, Prefix).
レインボーMRT：複数のMRT転送トポロジとデフォルトの転送トポロジを参照するMPLS MT-IDがあると便利です。これは「Rainbow MRT MPLS MT-ID」と呼ばれ、LDPによって使用されてシグナリングが削減され、同じラベルが同じ（MT-ID、プレフィックス）のすべてのピアに常にアドバタイズされるようになります。
MRT Island: The set of routers that support a particular MRT Profile and the links connecting them that support MRT.
MRTアイランド：特定のMRTプロファイルをサポートするルーターのセットと、MRTをサポートするそれらを接続するリンク。
Island Border Router (IBR): A router in the MRT Island that is connected to a router not in the MRT Island, both of which are in a common area or level.
アイランドボーダールーター（IBR）：MRTアイランドにないルーターに接続されているMRTアイランドのルーター。どちらも共通のエリアまたはレベルにあります。
Island Neighbor (IN): A router that is not in the MRT Island but is adjacent to an IBR and in the same area/level as the IBR.
アイランドネイバー（IN）：MRTアイランドにはないが、IBRに隣接し、IBRと同じエリア/レベルにあるルーター。
There are several places in this document where the construction "red(blue) FEC" is used to cover the case of the red FEC and the case of the blue FEC, independently. As an example, consider the sentence "When the ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings advertisements for the corresponding Rainbow FEC and advertise label mappings for the red(blue) FEC." This sentence should be read as applying to red FECs. Then it should be read as applying to blue FECs.
このドキュメントでは、「red（blue）FEC」という構造が、赤いFECのケースと青いFECのケースを個別にカバーするために使用されている箇所がいくつかあります。例として、「ABRが赤（青）FECに最適な領域の動作を必要とする場合、対応するRainbow FECの既存のラベルマッピングアドバタイズメントを撤回し、赤（青）FECのラベルマッピングをアドバタイズする必要があります。この文は、赤いFECに適用するものとして読む必要があります。次に、それは青いFECに適用するものとして読む必要があります。
Routers need to know which of their LDP neighbors support MRT. This is communicated using the MRT Capability Advertisement. Supporting MRT indicates several different aspects of behavior, as listed below.
ルータは、どのLDPネイバーがMRTをサポートしているかを知る必要があります。これは、MRT Capability Advertisementを使用して伝達されます。 MRTのサポートは、以下に示すように、動作のいくつかの異なる側面を示しています。
1. Sending and receiving multi-topology FEC elements, as defined in [RFC7307].
1. [RFC7307]で定義されているマルチトポロジFEC要素の送受信。
2. Understanding the Rainbow MRT MT-ID and applying the associated labels to all relevant MT-IDs.
2. Rainbow MRT MT-IDを理解し、関連するラベルをすべての関連するMT-IDに適用する。
3. Advertising the Rainbow MRT FEC to the appropriate neighbors for the appropriate prefix.
3. Rainbow MRT FECを適切なネイバーに適切なプレフィックスとしてアドバタイズします。
4. If acting as LDP egress for a prefix in the default topology, also acting as egress for the same prefix in MRT-Red and MRT-Blue.
4. デフォルトトポロジでプレフィックスのLDP出力として機能する場合、MRT-RedおよびMRT-Blueで同じプレフィックスの出力としても機能します。
5. For a FEC learned from a neighbor that does not support MRT, originating FECs for MRT-Red and MRT-Blue with the same prefix. This MRT Island egress behavior is to support an MRT Island that does not include all routers in the area/level.
5. MRTをサポートしないネイバーから学習したFECの場合、同じプレフィックスを持つMRT-RedおよびMRT-Blueの発信FEC。このMRTアイランドの出力動作は、エリア/レベルのすべてのルーターを含まないMRTアイランドをサポートすることです。
A new MRT Capability Parameter TLV is defined in accordance with the LDP Capability definition guidelines [RFC5561].
新しいMRT機能パラメーターTLVは、LDP機能定義ガイドライン[RFC5561]に従って定義されています。
The LDP MRT Capability can be advertised during LDP session initialization or after the LDP session is established. Advertisement of the MRT Capability indicates support of the procedures for establishing the MRT-Blue and MRT-Red Label Switched Paths (LSPs) detailed in this document. If the peer has not advertised the MRT Capability, then it indicates that LSR does not support MRT procedures.
LDP MRT機能は、LDPセッションの初期化中またはLDPセッションの確立後に通知できます。 MRT機能のアドバタイズは、このドキュメントで詳述されているMRT-BlueおよびMRT-Redのラベルスイッチドパス（LSP）を確立するための手順のサポートを示します。ピアがMRT機能を通知していない場合は、LSRがMRT手順をサポートしていないことを示しています。
If a router advertises the LDP MRT Capability to its peer, but the peer has not advertised the MRT Capability, then the router MUST NOT advertise MRT-related FEC-label bindings to that peer.
ルーターがLDP MRT機能をピアにアドバタイズしても、ピアがMRT機能をアドバタイズしていない場合、ルーターはMRT関連のFECラベルバインディングをそのピアにアドバタイズしてはなりません（MUST NOT）。
The following is the format of the MRT Capability Parameter.
以下は、MRT機能パラメーターのフォーマットです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MRT Capability (0x050E) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
MRT Capability TLV Format
MRT機能TLV形式
Where:
ただし：
U-bit: The unknown TLV bit MUST be 1. A router that does not recognize the MRT Capability TLV will silently ignore the TLV and process the rest of the message as if the unknown TLV did not exist.
Uビット：不明なTLVビットは1である必要があります。MRT機能TLVを認識しないルーターは、暗黙的にTLVを無視し、不明なTLVが存在しないかのようにメッセージの残りを処理します。
F-bit: The forward unknown TLV bit MUST be 0 as required by Section 3 of [RFC5561].
Fビット：[RFC5561]のセクション3で要求されているように、転送不明TLVビットは0でなければなりません。
MRT Capability: 0x050E
MRT機能：0x050E
Length: The length (in octets) of the TLV. Its value is 1.
長さ：TLVの長さ（オクテット単位）。その値は1です。
S-bit: The State bit MUST be 1 if used in the LDP Initialization message. MAY be set to 0 or 1 in the dynamic Capability message to advertise or withdraw the capability, respectively, as described in [RFC5561].
Sビット：LDP初期化メッセージで使用される場合、状態ビットは1でなければなりません。 [RFC5561]で説明されているように、動的な機能メッセージでそれぞれ0または1に設定して、機能をアドバタイズまたは撤回することができます。
An LSR advertising the LDP MRT Capability MUST also advertise the LDP Multi-Topology (MT) Capability. If an LSR negotiates the LDP MRT Capability with an LDP neighbor without also negotiating the LDP MT Capability, the LSR MUST behave as if the LDP MRT Capability was not negotiated and respond with the "MRT Capability negotiated without MT Capability" status code in the LDP Notification message (defined in the document). The E-bit of this Notification should be set to 0 to indicate that this is an Advisory Notification. The LDP session SHOULD NOT be terminated.
LDP MRT機能をアドバタイズするLSRは、LDPマルチトポロジ（MT）機能もアドバタイズする必要があります。 LSRがLDP MT機能をネゴシエートせずにLDPネイバーとLDP MRT機能をネゴシエートする場合、LSRは、LDP MRT機能がネゴシエートされなかったかのように動作し、LDPの「MT機能なしでネゴシエートされたMRT機能」ステータスコードで応答する必要があります。通知メッセージ（ドキュメントで定義）。この通知のEビットを0に設定して、これがアドバイザリ通知であることを示す必要があります。 LDPセッションは終了しないでください。
The MRT LDP Capability Advertisement does not distinguish between IPv4 and IPv6 address families. An LSR that advertises the MRT LDP Capability is expected to advertise MRT-related FEC-label bindings for the same address families for which it advertises shortest-path FEC-label bindings. Therefore, an LSR advertising MRT LDP Capability and shortest-path FEC-label bindings for IPv4 only (or IPv6 only) would be expected to advertise MRT-related FEC-label binding for IPv4 only (or IPv6 only). An LSR advertising the MRT LDP Capability and shortest-path FEC-label bindings for BOTH IPv4 and IPv6 is expected to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. In this scenario, advertising MRT-related FEC-label bindings only for IPv4 only (or only for IPv6) is not supported.
MRT LDP機能アドバタイズメントは、IPv4アドレスファミリとIPv6アドレスファミリを区別しません。 MRT LDP機能をアドバタイズするLSRは、最短パスFECラベルバインディングをアドバタイズするのと同じアドレスファミリのMRT関連FECラベルバインディングをアドバタイズすることが期待されています。したがって、IPv4のみ（またはIPv6のみ）のMRT LDP機能と最短パスFECラベルバインディングをアドバタイズするLSRは、IPv4のみ（またはIPv6のみ）のMRT関連FECラベルバインディングをアドバタイズすることが期待されます。 IPv4とIPv6の両方のMRT LDP機能と最短パスFECラベルバインディングをアドバタイズするLSRは、IPv4とIPv6の両方のMRT関連FECラベルバインディングをアドバタイズすることが期待されています。このシナリオでは、IPv4のみ（またはIPv6のみ）のMRT関連のFECラベルバインディングのアドバタイズはサポートされていません。
Section 10.1 of [RFC7812] describes the need for an Area Border Router (ABR) to have different neighbors use different MPLS labels when sending traffic to the ABR for the same FEC. More detailed discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1.
[RFC7812]のセクション10.1は、エリア境界ルータ（ABR）が同じFECのABRにトラフィックを送信するときに、異なるネイバーが異なるMPLSラベルを使用する必要性を説明しています。 Rainbow MRT MT-IDの詳細については、セクション5.1.1を参照してください。
Another use for the Rainbow MRT MT-ID is for an LSR to send the Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate penultimate-hop-popping for all three types of FECs (shortest path, red, and blue). The EXPLICIT_NULL label advertised using the Rainbow MRT MT-ID similarly applies to all the types of FECs. Note that the only scenario in which it is generally useful to advertise the implicit or explicit null label for all three FEC types is when the FEC refers to the LSR itself. See Section 5.2.3 for more details.
Rainbow MRT MT-IDのもう1つの用途は、LSRがIMPLICIT_NULLラベル付きのRainbow MRT MT-IDを送信して、3種類すべてのFEC（最短パス、赤、青）の最後から2番目のホップポップを示すことです。 Rainbow MRT MT-IDを使用してアドバタイズされるEXPLICIT_NULLラベルは、すべてのタイプのFECに同様に適用されます。 3つのFECタイプすべてに対して暗黙的または明示的なヌルラベルをアドバタイズすることが一般的に役立つ唯一のシナリオは、FECがLSR自体を参照する場合であることに注意してください。詳細については、セクション5.2.3を参照してください。
The value of the Rainbow MRT MPLS MT-ID (3945) has been assigned by IANA from the MPLS MT-ID space.
Rainbow MRT MPLS MT-ID（3945）の値は、MPLS MT-IDスペースからIANAによって割り当てられています。
To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812] defines the Default MRT Profile. Section 8 specifies the values in the "MPLS Multi-Topology Identifiers" registry for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (3946 and 3947).
LDPでMRTサポートを提供するには、MTプレフィックスFECを使用します。 [RFC7812]はデフォルトのMRTプロファイルを定義します。セクション8では、デフォルトのMRTプロファイル（3946および3947）に関連付けられたMRT-RedおよびMRT-Blue MPLS MT-IDの「MPLS Multi-Topology Identifiers」レジストリの値を指定しています。
As described in Section 8.1 of [RFC7812], when a new MRT Profile is defined, new and unique values should be allocated from the "MPLS Multi-Topology Identifiers" registry, corresponding to the MRT-Red and MRT-Blue MT-ID values for the new MRT Profile.
[RFC7812]のセクション8.1で説明されているように、新しいMRTプロファイルが定義されている場合、MRT-RedおよびMRT-Blue MT-ID値に対応する「MPLS Multi-Topology Identifiers」レジストリから新しい一意の値を割り当てる必要があります新しいMRTプロファイル用。
The MT Prefix FEC encoding is defined in [RFC7307] and is used without alteration for advertising label mappings for MRT-Blue, MRT-Red, and Rainbow MRT FECs.
MTプレフィックスFECエンコーディングは[RFC7307]で定義されており、変更なしでMRT-Blue、MRT-Red、およびRainbow MRT FECのラベルマッピングをアドバタイズするために使用されます。
4.4. Interaction of MRT-Related LDP Advertisements with the MRT Topology and Computations
4.4. MRT関連のLDPアドバタイズメントとMRTトポロジおよび計算との相互作用
[RFC7811] and [RFC7812] describe how the MRT topology is created based on information in IGP advertisements. The MRT topology and computations rely on IGP advertisements. The presence or absence of MRT-related LDP advertisements does not affect the MRT topology or the MRT-Red and MRT-Blue next hops computed for that topology.
[RFC7811]および[RFC7812]は、IGPアドバタイズメントの情報に基づいてMRTトポロジが作成される方法を説明しています。 MRTトポロジと計算は、IGPアドバタイズメントに依存しています。 MRT関連のLDPアドバタイズの有無は、MRTトポロジ、またはそのトポロジに対して計算されたMRT-RedおよびMRT-Blueのネクストホップに影響を与えません。
As an example, consider a network where all nodes are running MRT IGP extensions to determine the MRT topology, which is then used to compute MRT-Red and MRT-Blue next hops. The network operator also configures the nodes in this network to exchange MRT-related LDP advertisements in order to distribute MPLS labels corresponding to those MRT next hops. Suppose that, due to a misconfiguration on one particular link, the MRT-related LDP advertisements are not being properly exchanged for that link. Since the MRT-related IGP advertisements for the link are still being distributed, the link is still included in the MRT topology and computations. In this scenario, there will be missing MPLS forwarding entries corresponding to paths that use the misconfigured link.
例として、すべてのノードがMRT IGP拡張機能を実行してMRTトポロジを決定するネットワークを考えます。MRTトポロジは、MRT-RedおよびMRT-Blueネクストホップの計算に使用されます。ネットワークオペレーターは、これらのMRTネクストホップに対応するMPLSラベルを配布するために、MRT関連のLDPアドバタイズを交換するようにこのネットワークのノードを構成します。 1つの特定のリンクの設定ミスにより、MRT関連のLDPアドバタイズがそのリンクと適切に交換されていないとします。リンクのMRT関連のIGPアドバタイズが引き続き配信されているため、リンクはMRTトポロジと計算に含まれています。このシナリオでは、誤って構成されたリンクを使用するパスに対応するMPLS転送エントリが不足しています。
Note that the situation is analogous to the interaction of normal LDP advertisements and IGP advertisements for shortest-path forwarding. Deactivating the distribution of labels for normal shortest-path FECs on a link does not change the topology on which the Shortest Path First (SPF) algorithm is run by the IGP.
この状況は、最短パス転送のための通常のLDPアドバタイズメントとIGPアドバタイズメントの相互作用に類似していることに注意してください。リンク上の通常の最短パスFECのラベル配布を非アクティブ化しても、IGPが最短パス優先（SPF）アルゴリズムを実行するトポロジは変更されません。
"LDP IGP Synchronization" [RFC5443] addresses the issue of the LDP topology not matching the IGP topology by advertising the maximum IGP cost on links where LDP is not fully operational. This makes the IGP topology match the LDP topology. As described in Section 7.3.1 of [RFC7812], MRT is designed to be compatible with the LDP IGP synchronization mechanism. When the IGP advertises the maximum cost on a link where LDP is not fully operational, the link is excluded from MRT Island formation, which prevents the MRT algorithm from creating any paths using that link.
「LDP IGP同期」[RFC5443]は、LDPが完全に動作していないリンクで最大IGPコストを通知することにより、IGPトポロジと一致しないLDPトポロジの問題に対処します。これにより、IGPトポロジがLDPトポロジと一致します。 [RFC7812]のセクション7.3.1で説明されているように、MRTはLDP IGP同期メカニズムと互換性があるように設計されています。 IGPがLDPが完全に動作していないリンクで最大コストをアドバタイズすると、そのリンクはMRTアイランドの形成から除外され、MRTアルゴリズムがそのリンクを使用してパスを作成できなくなります。
This sections describes how and when labels for MRT-Red and MRT-Blue FECs are advertised. In order to provide protection paths that are immediately usable by the point of local repair in the event of a failure, the associated LSPs need to be created before a failure occurs.
このセクションでは、MRT-RedおよびMRT-Blue FECのラベルがアドバタイズされる方法とタイミングについて説明します。障害発生時にローカル修復ポイントがすぐに使用できる保護パスを提供するには、障害が発生する前に関連するLSPを作成する必要があります。
In this section, we will use the term "shortest-path FEC" to refer to the usual FEC associated with the shortest-path destination-based forwarding tree for a given prefix as determined by the IGP. We will use the terms "red FEC" and "blue FEC" to refer to FECs associated with the MRT-Red and MRT-Blue destination-based forwarding trees for a given prefix as determined by a particular MRT algorithm.
このセクションでは、「最短パスFEC」という用語を使用して、IGPによって決定された特定のプレフィックスの最短パス宛先ベース転送ツリーに関連付けられた通常のFECを指します。 「赤いFEC」および「青いFEC」という用語を使用して、特定のMRTアルゴリズムによって決定される特定のプレフィックスのMRT-RedおよびMRT-Blue宛先ベースの転送ツリーに関連付けられたFECを指します。
We first describe label distribution behavior specific to MRT. Then, we provide the correct interpretation of several important concepts in [RFC5036] in the context of MRT FEC label distribution.
最初に、MRTに固有のラベル配布動作について説明します。次に、MRT FECラベル配布のコンテキストで、[RFC5036]のいくつかの重要な概念の正しい解釈を提供します。
[RFC5036] specifies two different Label Distribution Control Modes (Independent and Ordered), two different Label Retention Modes (Conservative and Liberal), and two different Label Advertisement Modes (Downstream Unsolicited and Downstream on Demand). The current specification for LDP MRT requires that the same Label Distribution Control, Label Retention, and Label Advertisement modes be used for the shortest-path FECs and the MRT FECs.
[RFC5036]は、2つの異なるラベル配布制御モード（独立および順序）、2つの異なるラベル保持モード（保守的およびリベラル）、および2つの異なるラベルアドバタイズメントモード（ダウンストリーム非送信請求およびダウンストリームオンデマンド）を指定します。 LDP MRTの現在の仕様では、最短パスFECとMRT FECに同じラベル配布制御、ラベル保持、およびラベルアドバタイズメントモードを使用する必要があります。
Section 10.1 of [RFC7812] describes the need for an ABR to have different neighbors use different MPLS labels when sending traffic to the ABR for the same FEC. The method to accomplish this using the Rainbow MRT MT-ID is described in detail in [RFC7812]. Here we provide a brief summary. To those LDP peers in the same area as the best route to the destination, the ABR advertises two different labels corresponding to the MRT-Red and MRT-Blue forwarding trees for the destination. An LDP peer receiving these advertisements forwards MRT traffic to the ABR using these two different labels, depending on the FEC of the traffic. We refer to this as "best-area advertising and forwarding behavior", which is identical to normal MRT behavior.
[RFC7812]のセクション10.1では、同じFECのABRにトラフィックを送信するときに、ABRが異なるネイバーに異なるMPLSラベルを使用させる必要性について説明しています。 Rainbow MRT MT-IDを使用してこれを達成する方法は、[RFC7812]で詳細に説明されています。ここでは、簡単な概要を示します。 ABRは、宛先への最適なルートと同じエリアにあるそれらのLDPピアに、宛先のMRT-RedおよびMRT-Blue転送ツリーに対応する2つの異なるラベルをアドバタイズします。これらのアドバタイズを受信するLDPピアは、トラフィックのFECに応じて、これら2つの異なるラベルを使用してMRTトラフィックをABRに転送します。これを「ベストエリア広告および転送動作」と呼びます。これは、通常のMRT動作と同じです。
For all other LDP peers supporting MRT, the ABR advertises a FEC-label binding for the FEC, which is in the Rainbow MRT MT-ID, with the label that corresponds to that FEC in the default forwarding tree for the destination. An LDP peer receiving this advertisement forwards MRT traffic to the ABR using this label, for both MRT-Red and MRT-Blue traffic. We refer to this as "non-best-area advertising and forwarding behavior".
MRTをサポートする他のすべてのLDPピアの場合、ABRはFECのFECラベルバインディングをアドバタイズします。これは、Rainbow MRT MT-IDにあり、宛先のデフォルトの転送ツリーでそのFECに対応するラベルを使用します。このアドバタイズを受信するLDPピアは、MRTレッドトラフィックとMRTブルートラフィックの両方について、このラベルを使用してMRTトラフィックをABRに転送します。これを「非ベストエリア広告および転送動作」と呼びます。
The use of the Rainbow-FEC by the ABR for non-best-area advertisements is RECOMMENDED. An ABR MAY advertise the label for the default topology in separate MRT-Blue and MRT-Red advertisements. An LSR advertising the MRT Capability MUST recognize the Rainbow MRT MT-ID and associate the advertised label with the specific prefix with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles that advertise LDP as the forwarding mechanism.
ABRが非ベストエリア広告にRainbow-FECを使用することをお勧めします。 ABRは、デフォルトトポロジのラベルを、MRT-BlueおよびMRT-Redの個別のアドバタイズでアドバタイズできます（MAY）。 MRT機能をアドバタイズするLSRは、Rainbow MRT MT-IDを認識し、アドバタイズされたラベルを、LDPを転送メカニズムとしてアドバタイズするすべてのMRTプロファイルに関連付けられたMRT-RedおよびMRT-Blue MT-IDと特定のプレフィックスに関連付ける必要があります。
Due to changes in topology or configuration, an ABR and a given LDP peer may need to transition from best-area advertising and forwarding behavior to non-best-area behavior for a given destination, and vice versa. When the ABR requires best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings advertisements for the corresponding Rainbow FEC and advertise label mappings for the red(blue) FEC. When the ABR requires non-best-area behavior for a red(blue) FEC, it MUST withdraw any existing label mappings for both red and blue FECs and advertise label mappings for the corresponding Rainbow FEC label-binding.
トポロジまたは設定の変更により、ABRと特定のLDPピアは、特定の宛先のベストエリアアドバタイズおよび転送動作から非ベストエリア動作に、またはその逆に移行する必要がある場合があります。 ABRが赤（青）FECに最適な領域の動作を要求する場合、対応するRainbow FECの既存のラベルマッピングアドバタイズメントを撤回し、赤（青）FECのラベルマッピングをアドバタイズする必要があります。 ABRが赤（青）FECの非ベストエリア動作を必要とする場合、赤と青の両方のFECの既存のラベルマッピングを撤回し、対応するRainbow FECラベルバインディングのラベルマッピングをアドバタイズする必要があります。
In this transition, an ABR should never advertise a red(blue) FEC before withdrawing the corresponding Rainbow FEC (or vice versa). However, should this situation occur, the expected behavior of an LSR receiving these conflicting advertisements is defined as follows:
この移行では、ABRは対応するRainbow FECを撤回する前に赤（青）FECをアドバタイズするべきではありません（またはその逆）。ただし、この状況が発生した場合、これらの競合するアドバタイズを受信するLSRの予想される動作は、次のように定義されます。
- If an LSR receives a label mapping advertisement for a Rainbow FEC from an MRT LDP peer while it still retains a label mapping for the corresponding red or blue FEC, the LSR MUST continue to use the label mapping for the red or blue FEC, and it MUST send a Label Release message corresponding to the Rainbow FEC label advertisement.
- LSRがMRT LDPピアからRainbow FECのラベルマッピングアドバタイズを受信する一方で、対応する赤または青のFECのラベルマッピングを保持している場合、LSRは赤または青のFECのラベルマッピングを引き続き使用する必要があり、 Rainbow FECラベルアドバタイズメントに対応するラベルリリースメッセージを送信する必要があります。
- If an LSR receives a label mapping advertisement for a red or blue FEC while it still retains a label mapping for the corresponding Rainbow FEC, the LSR MUST continue to use the label mapping for the Rainbow FEC, and it MUST send a Label Release message corresponding to the red or blue FEC label advertisement.
- LSRが対応するRainbow FECのラベルマッピングを保持している間に、LSRが赤または青のFECのラベルマッピングアドバタイズを受信した場合、LSRはRainbow FECのラベルマッピングを引き続き使用し、対応するラベルリリースメッセージを送信する必要があります。赤または青のFECラベル広告に。
Section 11.2 of [RFC7812] describes how MRT provides FRR protection for multi-homed prefixes using calculations involving a named proxy-node. This covers the scenario where a prefix is originated by a router in the same area as the MRT Island, but outside of the MRT Island. It also covers the scenario of a prefix being advertised by multiple routers in the MRT Island.
[RFC7812]のセクション11.2は、MRTがマルチホームプレフィックスにFRR保護を提供し、名前付きプロキシノードを含む計算を使用する方法を説明しています。これは、プレフィックスがMRTアイランドと同じエリアにあるがMRTアイランドの外にあるルーターによって発信されるシナリオをカバーしています。また、MRTアイランドの複数のルーターによってプレフィックスが通知されるシナリオについても説明します。
In the named proxy-node calculation, each multi-homed prefix is represented by a conceptual proxy-node that is attached to two real proxy-node attachment routers. (A single proxy-node attachment router is allowed in the case of a prefix advertised by a same area router outside of the MRT Island, which is singly connected to the MRT Island.) All routers in the MRT Island perform the same calculations to determine the same two proxy-node attachment routers for each multi-homed prefix. Section 5.9 of [RFC7811] describes the procedure for identifying one proxy-node attachment router as "red" and one as "blue" with respect to the multi-homed prefix, and computing the MRT red and blue next hops to reach those red and blue proxy-node attachment routers.
名前付きプロキシノードの計算では、各マルチホームプレフィックスは、2つの実際のプロキシノード接続ルーターに接続されている概念的なプロキシノードによって表されます。 （MRTアイランドに単独で接続されている、MRTアイランド外の同じエリアルーターによってアドバタイズされたプレフィックスの場合、単一のプロキシノード接続ルーターが許可されます。）MRTアイランド内のすべてのルーターは、同じ計算を実行して決定します。各マルチホームプレフィックスに同じ2つのプロキシノード接続ルーター。 [RFC7811]のセクション5.9は、マルチホームプレフィックスに関して1つのプロキシノードアタッチメントルーターを「赤」と1つとして「青」として識別し、それらの赤と青に到達するためのMRT赤と青のネクストホップを計算する手順を説明しています青いプロキシノード接続ルーター。
In terms of LDP behavior, a red proxy-node attachment router for a given prefix MUST originate a label mapping for the red FEC for that prefix, while the blue proxy-node attachment router for a given prefix MUST originate a label mapping for the blue FEC for that prefix. If the red(blue) proxy-node attachment router is an Island Border Router (IBR), then when it receives a packet with the label corresponding to the red(blue) FEC for a prefix, it MUST forward the packet to the Island Neighbor (IN) whose cost was used in the selection of the IBR as a proxy-node attachment router. The IBR MUST swap the incoming label for the outgoing label corresponding to the shortest-path FEC for the prefix advertised by the IN. In the case where the IN does not support LDP, the IBR MUST pop the incoming label and forward the packet to the IN.
LDP動作の観点から、特定のプレフィックスの赤いプロキシノード接続ルーターは、そのプレフィックスの赤いFECのラベルマッピングを作成する必要がありますが、特定のプレフィックスの青いプロキシノード接続ルーターは、青色のラベルマッピングを作成する必要がありますそのプレフィックスのFEC。赤（青）のプロキシノードアタッチメントルーターがアイランドボーダールーター（IBR）の場合、プレフィックスの赤（青）のFECに対応するラベルが付いたパケットを受信すると、そのパケットをアイランドネイバーに転送する必要があります。 （IN）プロキシノードアタッチメントルーターとしてのIBRの選択に使用されたコスト。 IBRは、INによってアドバタイズされたプレフィックスの最短パスFECに対応する発信ラベルと着信ラベルを交換する必要があります。 INがLDPをサポートしていない場合、IBRは着信ラベルをポップし、パケットをINに転送する必要があります。
If the proxy-node attachment router is not an IBR, then the packet MUST be removed from the MRT forwarding topology and sent along the interface(s) that caused the router to advertise the prefix. This interface might be out of the area/level/AS.
プロキシノードアタッチメントルーターがIBRでない場合、パケットはMRT転送トポロジから削除され、ルーターがプレフィックスをアドバタイズする原因となったインターフェイスに沿って送信される必要があります。このインターフェイスは、エリア/レベル/ ASの外にある可能性があります。
[RFC5036] specifies the LDP label distribution procedures for shortest-path FECs. In general, the same procedures can be applied to the distribution of label mappings for red and blue FECs, provided that the procedures are interpreted in the context of MRT FEC label distribution. The correct interpretation of several important concepts in [RFC5036] in the context of MRT FEC label distribution is provided below.
[RFC5036]は、最短パスFECのLDPラベル配布手順を指定します。一般に、手順がMRT FECラベル配布のコンテキストで解釈される場合、同じ手順を赤と青のFECのラベルマッピングの配布に適用できます。 MRT FECラベル配布のコンテキストにおける[RFC5036]のいくつかの重要な概念の正しい解釈を以下に示します。
In the context of distributing label mappings for red and blue FECs, we restrict the LDP peer in [RFC5036] to mean LDP peers for which the LDP MRT Capability has been negotiated. In order to make this distinction clear, in this document we will use the term "MRT LDP peer" to refer to an LDP peer for which the LDP MRT Capability has been negotiated.
赤と青のFECのラベルマッピングを配布する状況では、[RFC5036]のLDPピアを、LDP MRT機能がネゴシエートされたLDPピアを意味するように制限します。この区別を明確にするために、このドキュメントでは、「MRT LDPピア」という用語を使用して、LDP MRT機能がネゴシエートされたLDPピアを指します。
Several procedures in [RFC5036] use the next hop of a (shortest-path) FEC to determine behavior. The next hop of the shortest-path FEC is based on the shortest-path forwarding tree to the prefix associated with the FEC. When the procedures of [RFC5036] are used to distribute label mapping for red and blue FECs, the next hop for the red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the prefix associated with the FEC.
[RFC5036]のいくつかの手順では、（最短パス）FECのネクストホップを使用して動作を決定します。最短パスFECのネクストホップは、FECに関連付けられたプレフィックスへの最短パス転送ツリーに基づいています。 [RFC5036]の手順を使用して赤と青のFECのラベルマッピングを配布する場合、赤（青）FECのネクストホップは、FECに関連付けられたプレフィックスへのMRT-赤（青）転送ツリーに基づいています。
For example, Appendix A.1.7 of [RFC5036] specifies the response by an LSR to a change in the next hop for a FEC. For a shortest-path FEC, the next hop may change as the result of the LSR running a shortest-path computation on a modified IGP topology database. For the red and blue FECs, the red and blue next hops may change as the result of the LSR running a particular MRT algorithm on a modified IGP topology database.
たとえば、[RFC5036]の付録A.1.7は、FECのネクストホップの変更に対するLSRによる応答を指定しています。最短パスFECの場合、変更されたIGPトポロジデータベースでLSRが最短パス計算を実行した結果、ネクストホップが変わる可能性があります。赤と青のFECの場合、変更されたIGPトポロジデータベースで特定のMRTアルゴリズムを実行しているLSRの結果として、赤と青のネクストホップが変わる可能性があります。
As another example, Section 2.6.1.2 of [RFC5036] specifies that when an LSR is using LSP Ordered Control, it may initiate the transmission of a label mapping only for a (shortest-path) FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. The FEC next hop for a shortest-path FEC is based on the shortest-path forwarding tree to the prefix associated with the FEC. In the context of distributing MRT LDP labels, this procedure is understood to mean the following. When an LSR is using LSP Ordered Control, it may initiate the transmission of a label mapping only for a red(blue) FEC for which it has a label mapping for the red(blue) FEC next hop, or for which the LSR is the egress. The red or blue FEC next hop is based on the MRT-Red or Blue forwarding tree to the prefix associated with the FEC.
別の例として、[RFC5036]のセクション2.6.1.2は、LSRがLSP Ordered Controlを使用している場合、LSPにラベルマッピングがある（最短パス）FECに対してのみラベルマッピングの送信を開始できることを指定していますFECネクストホップ、またはLSRが出力です。最短パスFECのFECネクストホップは、FECに関連付けられたプレフィックスへの最短パス転送ツリーに基づいています。 MRT LDPラベルを配布する場合、この手順は以下を意味すると理解されています。 LSRがLSP Ordered Controlを使用している場合、赤（青）FECネクストホップのラベルマッピングがある、またはLSRが出口。赤または青のFECネクストホップは、FECに関連付けられたプレフィックスへのMRT-赤または青の転送ツリーに基づいています。
Procedures in [RFC5036] related to Ordered Control label distribution mode rely on whether or not an LSR may act as an egress LSR for a particular FEC in order to determine whether or not the LSR may originate a label mapping for that FEC. The status of being an egress LSR for a particular FEC is also used in the loop detection procedures described in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the conditions under which an LSR may act as an egress LSR with respect to a particular (shortest-path) FEC:
順序制御ラベル配布モードに関連する[RFC5036]の手順は、LSRがそのFECのラベルマッピングを発信できるかどうかを判断するために、LSRが特定のFECの出力LSRとして機能するかどうかに依存します。特定のFECの出力LSRのステータスは、[RFC5036]で説明されているループ検出手順でも使用されます。 [RFC5036]のセクション2.6.1.2は、LSRが特定の（最短パス）FECに関して出力LSRとして機能する条件を指定しています。
1. The (shortest-path) FEC refers to the LSR itself (including one of its directly attached interfaces).
1. （最短パス）FECは、LSR自体（直接接続されたインターフェースの1つを含む）を指します。
2. The next hop router for the (shortest-path) FEC is outside of the Label Switching Network.
2. （最短パス）FECのネクストホップルータは、ラベルスイッチングネットワークの外部にあります。
3. (Shortest-path) FEC elements are reachable by crossing a routing domain boundary.
3. （最短パス）FEC要素は、ルーティングドメインの境界を越えることによって到達可能です。
The conditions for determining an egress LSR with respect to a red or blue FEC need to be modified. An LSR may act as an egress LSR with respect to a particular red(blue) FEC under any of the following conditions:
赤または青のFECに関して出力LSRを決定するための条件を変更する必要があります。 LSRは、次のいずれかの条件下で、特定の赤（青）FECに関して出力LSRとして機能します。
1. The prefix associated with the red(blue) FEC refers to the LSR itself (including one of its directly attached interfaces).
1. 赤（青）のFECに関連付けられているプレフィックスは、LSR自体（直接接続されているインターフェイスの1つを含む）を指します。
2. The LSR is the red(blue) proxy-node attachment router with respect to the multi-homed prefix associated with the red(blue) FEC. This includes the degenerate case of a single red and blue proxy-node attachment router for a single-homed prefix.
2. LSRは、赤（青）のFECに関連付けられたマルチホームプレフィックスに関する赤（青）のプロキシノード接続ルーターです。これには、シングルホームプレフィックスの赤と青の単一のプロキシノードアタッチメントルーターの縮退ケースが含まれます。
3. The LSR is an ABR AND the MRT LDP peer requires non-best-area advertising and forwarding behavior for the prefix associated with the FEC.
3. LSRはABRであり、MRT LDPピアはFECに関連付けられたプレフィックスに対して非ベストエリアアドバタイズおよび転送動作を必要とします。
Note that condition 3 scopes an LSR's status as an egress LSR with respect to a particular FEC to a particular MRT LDP peer. Therefore, the condition "Is LSR egress for FEC?" that occurs in several procedures in [RFC5036] needs to be interpreted as "Is LSR egress for FEC with respect to Peer?"
条件3では、特定のMRT LDPピアに対する特定のFECに関して、LSRのステータスが出力LSRとしてスコープされることに注意してください。したがって、条件は「LSRはFECに対して下りか？」 [RFC5036]のいくつかの手順で発生する問題は、「ピアに関するFECのLSR出力か？」と解釈する必要があります。
Also note that there is no explicit condition that allows an LSR to be classified as an egress LSR with respect to a red or blue FEC based only on the primary next hop for the shortest-path FEC not supporting LDP or not supporting LDP MRT Capability. These situations are covered by the proxy-node attachment router and ABR conditions (conditions 2 and 3). In particular, an Island Border Router is not the egress LSR for a red(blue) FEC unless it is also the red(blue) proxy-node attachment router for that FEC.
LDPをサポートしていない、またはLDP MRT機能をサポートしていない最短パスFECのプライマリネクストホップのみに基づいて、赤または青のFECに関してLSRを出力LSRとして分類できる明示的な条件がないことにも注意してください。これらの状況は、プロキシノード接続ルーターとABR条件（条件2および3）でカバーされます。特に、アイランドボーダールーターは、そのFECの赤（青）プロキシノード接続ルーターでもない限り、赤（青）FECの出力LSRではありません。
Also note that, in general, a proxy-node attachment router for a given prefix should not advertise an implicit or explicit null label for the corresponding red or blue FEC, even though it may be an egress LSR for the shortest-path FEC. In general, the proxy-node attachment router needs to forward red or blue traffic for that prefix to a particular loop-free island neighbor, which may be different from the shortest-path next hop. The proxy-node attachment router needs to receive the red or blue traffic with a non-null label to correctly forward it.
また、一般に、特定のプレフィックスのプロキシノードアタッチメントルーターは、対応する赤または青のFECの暗黙的または明示的なnullラベルをアドバタイズしないでください。これは、最短パスFECの出力LSRであってもかまいません。一般に、プロキシノードアタッチメントルーターは、そのプレフィックスの赤または青のトラフィックを特定のループのないアイランドネイバーに転送する必要があります。これは、最短パスのネクストホップとは異なる場合があります。プロキシノードアタッチメントルーターは、正しく転送するために、null以外のラベルの付いた赤または青のトラフィックを受信する必要があります。
5.2.4. Use of Rainbow FEC to Satisfy Label Mapping Existence Requirements in RFC 5036
5.2.4. Rainbow FECを使用してRFC 5036のラベルマッピングの存在要件を満たす
Several procedures in [RFC5036] require the LSR to determine if it has previously received and retained a label mapping for a FEC from the next hop. In the case of an LSR that has received and retained a label mapping for a Rainbow FEC from an ABR, the label mapping for the Rainbow FEC satisfies the label mapping existence requirement for the corresponding red and blue FECs. Label mapping existence requirements in the context of MRT LDP label distribution are modified as: "Has LSR previously received and retained a label mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from the red(blue) next hop?"
[RFC5036]のいくつかの手順では、LSRが次のホップからFECのラベルマッピングを以前に受信して保持していたかどうかを判断する必要があります。 ABRからRainbow FECのラベルマッピングを受信して保持したLSRの場合、Rainbow FECのラベルマッピングは、対応する赤と青のFECのラベルマッピングの存在要件を満たします。 MRT LDPラベル配布のコンテキストでのラベルマッピングの存在要件は、次のように変更されています。
As an example, this behavior allows an LSR that has received and retained a label mapping for the Rainbow FEC to advertise label mappings for the corresponding red and blue FECs when operating in Ordered Control label distribution mode.
例として、この動作により、レインボーFECのラベルマッピングを受信して保持したLSRは、順序制御ラベル配布モードで動作しているときに、対応する赤と青のFECのラベルマッピングをアドバタイズできます。
In [RFC5036], an LSR uses its routing table to validate prefixes associated with shortest-path FECs. For example, Section 3.5.7.1 of [RFC5036] specifies that "an LSR receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element." In the context of MRT FECs, a red or blue FEC element matches a routing table entry if the corresponding shortest-path FEC element matches a routing table entry.
[RFC5036]では、LSRはルーティングテーブルを使用して、最短パスFECに関連付けられたプレフィックスを検証します。たとえば、[RFC5036]のセクション3.5.7.1は、「プレフィックスのダウンストリームLSRからラベルマッピングメッセージを受信するLSRは、ルーティングテーブルにFEC要素と完全に一致するエントリが含まれていない限り、ラベルを転送に使用しないでください」と規定しています。 MRT FECのコンテキストでは、対応する最短パスFEC要素がルーティングテーブルエントリと一致する場合、赤または青のFEC要素がルーティングテーブルエントリと一致します。
Appendix A.1.6 of [RFC5036] describes the response of an LSR to the "Recognize New FEC" event, which occurs when an LSR learns a new (shortest-path) FEC via the routing table. In the context of MRT FECs, if the MRT LDP Capability has been enabled, then when an LSR learns a new shortest-path FEC, the LSR should generate "Recognize New FEC" events for the corresponding Red and Blue FECS in addition to the normally generated "Recognize New FEC" event for the shortest-path FEC
[RFC5036]の付録A.1.6は、LSRがルーティングテーブルを介して新しい（最短パス）FECを学習するときに発生する「Recognize New FEC」イベントに対するLSRの応答を説明しています。 MRT FECのコンテキストでは、MRT LDP機能が有効になっている場合、LSRが新しい最短パスFECを学習すると、LSRは通常の処理に加えて、対応する赤と青のFECSの「新しいFECの認識」イベントを生成する必要があります。最短パスFECの「Recognize New FEC」イベントを生成
A label mapping for the Rainbow FEC should only be originated by an ABR under the conditions described in Section 5.1.1. A neighbor of the ABR that receives a label mapping for the Rainbow FEC MUST NOT propagate a label mapping for that Rainbow FEC.
Rainbow FECのラベルマッピングは、セクション5.1.1で説明されている条件下でのみABRによって作成されるべきです。 Rainbow FECのラベルマッピングを受信するABRのネイバーは、そのRainbow FECのラベルマッピングを伝播してはなりません。
The labels distributed by the extensions in this document create additional forwarding paths that do not follow shortest-path routes. The transit label swapping operations defining these alternative forwarding paths are created during normal operations (before a failure occurs). Therefore, a malicious packet with an appropriate label injected into the network from a compromised location would be forwarded to a destination along a non-shortest path. When this technology is deployed, a network security design should not rely on assumptions about potentially malicious traffic only following shortest paths.
このドキュメントの拡張機能によって配布されるラベルは、最短パスルートをたどらない追加の転送パスを作成します。これらの代替転送パスを定義するトランジットラベルスワッピング操作は、通常の操作中に（障害が発生する前に）作成されます。したがって、侵害された場所からネットワークに挿入された適切なラベルが付いた悪意のあるパケットは、非最短パスに沿って宛先に転送されます。このテクノロジを展開する場合、ネットワークセキュリティの設計は、最悪の経路のみをたどる悪意のある可能性のあるトラフィックに関する想定に依存するべきではありません。
It should be noted that the creation of non-shortest forwarding paths is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to construct forwarding paths that do not follow the shortest path.
非最短の転送パスの作成はMRTに固有のものではないことに注意してください。たとえば、RSVP-TE [RFC3209]を使用して、最短パスをたどらない転送パスを構築できます。
7. Potential Restrictions on MRT-Related MT-ID Values Imposed by RFC 6420
7. RFC 6420によって課されるMRT関連のMT-ID値に対する潜在的な制限
As discussed in the introduction, in addition to unicast-forwarding applications, MRT can be used to provide disjoint trees for multicast traffic distribution. In the case of PIM, this is accomplished by using the MRT red and blue next hops as the PIM Reverse Path Forwarding (RPF) topology, the collection of routes used by PIM to perform the RPF operation when building source trees. The PIM Multi-Topology ID (MT-ID) Join Attribute defined in Section 5.2 of [RFC6420] can be used to establish MRT-based multicast distribution trees. [RFC6420] limits the values of the PIM MT-ID from 1 through 4095.
概要で説明したように、ユニキャスト転送アプリケーションに加えて、MRTを使用して、マルチキャストトラフィック配信にばらばらのツリーを提供できます。 PIMの場合、これは、MRTの赤と青のネクストホップをPIMリバースパス転送（RPF）トポロジとして使用することで実現されます。これは、PIMがソースツリーの構築時にRPF操作を実行するために使用するルートのコレクションです。 [RFC6420]のセクション5.2で定義されているPIMマルチトポロジID（MT-ID）結合属性を使用して、MRTベースのマルチキャスト配信ツリーを確立できます。 [RFC6420]は、PIM MT-IDの値を1〜4095に制限します。
For the purpose of reducing management overhead and simplifying troubleshooting, it is desirable to be able to use the same numerical value for the PIM MT-ID as for the MPLS MT-ID for multicast and unicast applications using MRT routes constructed using the same MRT Profile. In order to enable this simplification, the MPLS MT-ID values assigned in this document fall in the range 1 through 4095. The "MPLS Multi-Topology Identifiers" registry reflects this by listing the values from 3948 through 3995 as for MRT-related MPLS MT-ID values. This allows for 51 MRT-related MPLS MT-ID values that can be directly mapped to PIM MT-ID values, which accommodates 25 MRT Profiles with red and blue MT-ID pairs, with one extra for the Rainbow MPLS MT-ID value. [RFC7307] designates the MT-ID range 6-3995 as "Unassigned for future IGP topologies". As shown in the IANA Considerations, the guidance for the range 3948-3995 has been changed to "Unassigned (for future MRT-related values)".
管理オーバーヘッドを削減し、トラブルシューティングを簡素化する目的で、同じMRTプロファイルを使用して構築されたMRTルートを使用するマルチキャストおよびユニキャストアプリケーションのMPLS MT-IDと同じ数値をPIM MT-IDに使用できることが望ましい。この簡素化を可能にするために、このドキュメントで割り当てられたMPLS MT-ID値は1〜4095の範囲にあります。「MPLSマルチトポロジ識別子」レジストリは、MRT関連のMPLSの場合と同様に、3948〜3995の値をリストすることでこれを反映します。 MT-ID値。これにより、PIM MT-ID値に直接マッピングできる51のMRT関連MPLS MT-ID値が可能になり、赤と青のMT-IDペアを持つ25のMRTプロファイルに対応し、Rainbow MPLS MT-ID値用に1つ追加されます。 [RFC7307]は、MT-ID範囲6〜3995を「将来のIGPトポロジ用に未割り当て」として指定します。 IANAの考慮事項に示されているように、範囲3948〜3995のガイダンスは「未割り当て（将来のMRT関連の値用）」に変更されました。
IANA has allocated a value for the new LDP Capability TLV from the "Label Distribution Protocol (LDP) Parameters" registry under "TLV Type Name Space": MRT Capability TLV (0x050E).
IANAは、「TLV Type Name Space」の下の「Label Distribution Protocol（LDP）Parameters」レジストリから新しいLDP機能TLVの値を割り当てました：MRT機能TLV（0x050E）。
Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ -----------------
0x050E MRT Capability TLV RFC 8320
IANA has allocated a value for the new LDP Status Code from the "Label Distribution Protocol (LDP) Parameters" registry under "Status Code Name Space": MRT Capability negotiated without MT Capability (0x00000034). The Status Code E-bit is set to 0.
IANAは、「ステータスコードネームスペース」の下の「ラベル配布プロトコル（LDP）パラメータ」レジストリから新しいLDPステータスコードの値を割り当てました。MT機能なしで交渉されたMRT機能（0x00000034）。ステータスコードEビットは0に設定されます。
Value E Description Reference Notes / Reg. Date
------------- - ------------------ ------------ -----------------
0x00000034 0 MRT Capability RFC 8320
negotiated without
MT Capability
IANA has allocated three values from the "MPLS Multi-Topology Identifiers" registry [RFC7307]:
IANAは、「MPLSマルチトポロジ識別子」レジストリ[RFC7307]から3つの値を割り当てました。
3945 Rainbow MRT MPLS MT-ID
3945レインボーMRT MPLS MT-ID
3946 Default Profile MRT-Red MPLS MT-ID
3946デフォルトプロファイルMRT-Red MPLS MT-ID
3947 Default Profile MRT-Blue MPLS MT-ID
3947デフォルトプロファイルMRT-Blue MPLS MT-ID
Also, IANA has changed the Purpose field of the "MPLS Multi-Topology Identifiers" registry for MT-ID range 3948-3995 to "Unassigned (for future MRT-related values)". The registration procedure for the entire registry remains Standards Action [RFC8126]. The current registry is shown below:
また、IANAは、MT-ID範囲3948-3995の「MPLS Multi-Topology Identifiers」レジストリの目的フィールドを「未割り当て（将来のMRT関連の値用）」に変更しました。レジストリ全体の登録手順は標準アクション[RFC8126]のままです。現在のレジストリを以下に示します。
Value Purpose Reference
------------ ---------------------- ------------
0 Default/standard topology [RFC7307]
1 IPv4 in-band management [RFC7307]
2 IPv6 routing topology [RFC7307]
3 IPv4 multicast topology [RFC7307]
4 IPv6 multicast topology [RFC7307]
5 IPv6 in-band management [RFC7307]
6-3944 Unassigned (for future IGP topologies)
3945 Rainbow MRT MPLS MT-ID RFC 8320
3946 Default Profile MRT-Red MPLS MT-ID RFC 8320
3947 Default Profile MRT-Blue MPLS MT-ID RFC 8320
3948-3995 Unassigned (for future MRT-related values) RFC 8320
3996-4095 Reserved for Experimental Use [RFC7307]
4096-65534 Unassigned (for MPLS topologies)
65535 Wildcard Topology [RFC7307]
[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>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、DOI 10.17487 / RFC5036、October 2007、<https：// www。 rfc-editor.org/info/rfc5036>。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>.
[RFC5561]トーマス、B。、ラザ、K。、アガーワル、S。、アガーワル、R。、およびJL。 Le Roux、「LDP Capabilities」、RFC 5561、DOI 10.17487 / RFC5561、2009年7月、<https://www.rfc-editor.org/info/rfc5561>。
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, <https://www.rfc-editor.org/info/rfc6420>.
[RFC6420] Cai、Y。およびH. Ou、「PIM Multi-Topology ID（MT-ID）Join Attribute」、RFC 6420、DOI 10.17487 / RFC6420、2011年11月、<https://www.rfc-editor.org / info / rfc6420>。
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, July 2014, <https://www.rfc-editor.org/info/rfc7307>.
[RFC7307] Zhao、Q.、Raza、K.、Zhou、C.、Fang、L.、Li、L。、およびD. King、「LDP Extensions for Multi-Topology」、RFC 7307、DOI 10.17487 / RFC7307、 2014年7月、<https://www.rfc-editor.org/info/rfc7307>。
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, DOI 10.17487/RFC7811, June 2016, <https://www.rfc-editor.org/info/rfc7811>.
[RFC7811] Enyedi、G.、Csaszar、A.、Atlas、A.、Bowers、C。、およびA. Gopalan、「最大冗長ツリー（MRT-FRR）を使用してIP / LDP高速リルートを計算するアルゴリズム」、RFC 7811、DOI 10.17487 / RFC7811、2016年6月、<https://www.rfc-editor.org/info/rfc7811>。
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, <https://www.rfc-editor.org/info/rfc7812>.
[RFC7812] Atlas、A.、Bowers、C。、およびG. Enyedi、「最大冗長ツリー（MRT-FRR）を使用したIP / LDP高速リルートのアーキテクチャ」、RFC 7812、DOI 10.17487 / RFC7812、2016年6月、< https://www.rfc-editor.org/info/rfc7812>。
[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>。
[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>。
[ARCH] Atlas, A., Kebler, R., Wijnands, IJ., Csaszar, A., and G. Envedi, "An Architecture for Multicast Protection Using Maximally Redundant Trees", Work in Progress, draft-atlas-rtgwg-mrt-mc-arch-02, July 2013.
[ARCH] Atlas、A.、Kebler、R.、Wijnands、IJ。、Csaszar、A。、およびG. Envedi、「An anarchitetic for Multicast Protection Using Multily Redundant Trees」、Work in Progress、draft-atlas-rtgwg- mrt-mc-arch-02、2013年7月。
[IS-IS-MRT] Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. Tantsura, "Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRTs)", Work in Progress, draft-ietf-isis-mrt-03, June 2017.
[IS-IS-MRT] Li、Z.、Wu、N.、Zhao、Q.、Atlas、A.、Bowers、C.、J. Tantsura、 "Intermediate System to Intermediate System（IS-IS）Extensions for Maximally Redundant Trees（MRTs）」、Work in Progress、draft-ietf-isis-mrt-03、2017年6月。
[OSPF-MRT] Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, "OSPF Extensions to Support Maximally Redundant Trees", Work in Progress, draft-ietf-ospf-mrt-03, June 2017.
[OSPF-MRT] Atlas、A.、Hegde、S.、Bowers、C.、Tantsura、J。、およびZ. Li、「最大限に冗長なツリーをサポートするOSPF拡張機能」、作業中、draft-ietf-ospf- mrt-03、2017年6月。
[PARAM-SYNC] Bryant, S., Atlas, A., and C. Bowers, "Routing Timer Parameter Synchronization", Work in Progress, draft-ietf-rtgwg-routing-timer-param-sync-00, October 2017.
[PARAM-SYNC]ブライアント、S。、アトラス、A。、およびC.バウアーズ、「ルーティングタイマーパラメーターの同期」、作業中、draft-ietf-rtgwg-routing-timer-param-sync-00、2017年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, <https://www.rfc-editor.org/info/rfc5443>.
[RFC5443] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP Synchronization」、RFC 5443、DOI 10.17487 / RFC5443、2009年3月、<https://www.rfc-editor.org/info/ rfc5443>。
[RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "Multipoint LDP (mLDP) Node Protection", RFC 7715, DOI 10.17487/RFC7715, January 2016, <https://www.rfc-editor.org/info/rfc7715>.
[RFC7715] Wijnands、IJ。、Ed。、Raza、K.、Atlas、A.、Tantsura、J。、およびQ. Zhao、「Multipoint LDP（mLDP）Node Protection」、RFC 7715、DOI 10.17487 / RFC7715、January 2016、<https://www.rfc-editor.org/info/rfc7715>。
Acknowledgements
謝辞
The authors would like to thank Ross Callon, Loa Andersson, Stewart Bryant, Mach Chen, Greg Mirsky, Uma Chunduri, and Tony Przygienda for their comments and suggestions.
著者は、コメントと提案をしてくれたRoss Callon、Loa Andersson、Stewart Bryant、Mach Chen、Greg Mirsky、Uma Chunduri、およびTony Przygiendaに感謝します。
Authors' Addresses
著者のアドレス
Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Alia Atlas Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: akatlas@juniper.net
Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: kishoret@juniper.net
Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
クリスバウアーズジュニパーネットワークス1194 N.マチルダアベニューサニーベール、カリフォルニア州94089アメリカ合衆国
Email: cbowers@juniper.net
Jeff Tantsura Individual United States of America
ジェフタンスラ個人アメリカ合衆国
Email: jefftant.ietf@gmail.com
IJsbrand Wijnands Cisco Systems, Inc.
IJsbrand Wijnands Cisco Systems、Inc.
Email: ice@cisco.com