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
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".
本文件规定了标签分发协议（LDP）的扩展，以支持为最大冗余树（MRT）创建标签交换路径（LSP）。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能力的能力。本文档描述了标签交换路由器（LSR）和标签边缘路由器（LER）宣传MRT功能的扩展和相关行为。
MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.
MRT-FRR使用LDP多拓扑扩展，因此从MPLS MT-ID空间分配了三个多拓扑ID。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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].
至少需要部署一个通用的标准化算法（例如，[RFC7811]中解释并完整记录的MRT低点算法），以便支持MRT计算的路由器一致地计算相同的MRT。LDP依赖IGP来计算MRT和备选方案。OSPF的扩展在[OSPF-MRT]中定义。IS-IS-MRT中定义了IS-IS的扩展。
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.
MRT还可用于使用[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）创建两个备用目的地树，与稳定运行期间使用的最短路径转发分离。LDP使用多拓扑扩展[RFC7307]为这两组转发树（MRT Blue和MRT Red）发送转发等价类（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快速重路由，需要对LDP进行新的能力扩展。支持MRT的LDP实现还必须遵循此处描述的规则，以发起和管理与MRT相关的FEC，如其多拓扑ID所示。网络重新聚合在[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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照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.
冗余树（RTs）：一对树，其中沿第一棵树从任何节点X到根R的路径与沿第二棵树从同一节点X到根的路径不相交。冗余树总是可以在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的路径以及沿第二棵树从同一节点X到根的路径共享最小节点数和最小链路数。每个这样的共享节点都是一个切割顶点。任何共享链接都是剪切链接。在非2-连通图中，不可能计算RTs。但是，可以计算MRT。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).
捷运红：捷运红用于描述两条捷运中的一条；它用于描述关联的转发拓扑和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蓝色：MRT蓝色用于描述两个MRT中的一个；用于描述关联的转发拓扑和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).
Rainbow MRT：有一个MPLS MT-ID是很有用的，它引用多个MRT转发拓扑和默认转发拓扑。这被称为“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）：捷运岛上的路由器，与不在捷运岛上的路由器相连，两者都位于公共区域或级别。
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.
本文件中有几个地方使用了“红色（蓝色）FEC”结构，分别涵盖红色FEC和蓝色FEC的情况。作为一个例子，考虑句子“当ABR需要红色（蓝色）FEC的最佳区域行为时，它必须撤回任何现有的标签映射广告，以对应的彩虹FEC和红色（蓝色）FEC的广告标签映射。”这个句子应该被理解为适用于红色FECS。然后，应将其理解为适用于蓝色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表示行为的几个不同方面，如下所示。
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].
根据LDP能力定义指南[RFC5561]，定义了新的MRT能力参数TLV。
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
LDP MRT能力可以在LDP会话初始化期间或在LDP会话建立之后进行广告。地铁能力的广告表明支持
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.
本文件详述了建立MRT蓝色和红色标签交换路径（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标签绑定。
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 |
+-+-+-+-+-+-+-+-+
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
捷运能力：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。可在动态能力消息中设置为0或1，以分别公布或撤销能力，如[RFC5561]中所述。
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
宣传LDP MRT能力的LSR还必须宣传LDP多拓扑（MT）能力。如果LSR在不协商LDP MT能力的情况下与LDP邻居协商LDP MRT能力，则LSR必须表现为LDP MRT能力未协商，并在LDP通知消息中使用“协商无MT能力的MRT能力”状态码（定义见
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.
文件）。此通知的E位应设置为0，以表示这是一个咨询通知。自民党会议不应终止。
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）的LSR广告MRT LDP功能和最短路径FEC标签绑定预计将仅为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标签。第5.1.1节对Rainbow MRT MT-ID进行了更详细的讨论。
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的另一个用途是LSR发送Rainbow MRT MT-ID，其中包含一个隐式的_NULL标签，以指示所有三种类型的FEC（最短路径、红色和蓝色）的倒数第二跳弹出。使用Rainbow MRT MT-ID公布的显式\u空标签同样适用于所有类型的FEC。请注意，当FEC引用LSR本身时，为所有三种FEC类型公布隐式或显式空标签通常是有用的唯一场景。详见第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）的值已由IANA从MPLS MT-ID空间分配。
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节指定了“MPLS多拓扑标识符”注册表中与默认MRT配置文件（3946和3947）关联的MRT Red和MRT Blue MPLS MT ID的值。
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配置文件时，应从“MPLS多拓扑标识符”注册表中分配新的唯一值，对应于新MRT配置文件的MRT红色和MRT蓝色MT-ID值。
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 Red和MRT Blue下跳。网络运营商还将该网络中的节点配置为交换与MRT相关的LDP广告，以便分发与那些MRT下一跳对应的MPLS标签。假设，由于某一特定链路上的配置错误，与捷运相关的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成本，解决了LDP拓扑与IGP拓扑不匹配的问题。这使得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红色和MRT蓝色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红色和MRT蓝色目的地的转发树相关联的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]指定了两种不同的标签分发控制模式（独立和有序）、两种不同的标签保留模式（保守和自由）以及两种不同的标签广告模式（下游未经请求和下游按需）。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节描述了ABR在为同一FEC向ABR发送流量时，需要让不同的邻居使用不同的MPLS标签。[RFC7812]中详细描述了使用Rainbow MRT MT-ID实现此目的的方法。这里我们提供一个简短的总结。对于与到达目的地的最佳路由位于同一区域的那些LDP对等点，ABR为目的地播发与MRT Red和MRT Blue转发树对应的两个不同标签。接收这些广告的LDP对等方根据业务的FEC，使用这两个不同的标签将MRT业务转发给ABR。我们称之为“最佳区域广告和转发行为”，这与普通捷运行为相同。
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
对于支持MRT的所有其他LDP对等方，ABR在Rainbow MRT MT-ID中公布FEC的FEC标签绑定，该标签对应于目的地默认转发树中的该FEC。接收到此广告的LDP对等方使用此标签将MRT流量转发给ABR，用于MRT和Red
and MRT-Blue traffic. We refer to this as "non-best-area advertising and forwarding behavior".
还有地铁蓝色交通。我们称之为“非最佳区域广告和转发行为”。
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在非最佳区域广告中使用彩虹FEC。ABR可以在单独的MRT蓝色和MRT红色广告中广告默认拓扑的标签。宣传MRT能力的LSR必须识别Rainbow MRT MT-ID，并将宣传标签与特定前缀以及与所有宣传LDP作为转发机制的MRT配置文件相关联的MRT红色和MRT蓝色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的最佳区域行为时，它必须为相应的彩虹FEC撤销任何现有标签映射广告，并为红色（蓝色）FEC撤销广告标签映射。当ABR要求红色（蓝色）FEC具有非最佳区域行为时，它必须为红色和蓝色FEC提取任何现有标签映射，并为相应的彩虹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在撤回相应的彩虹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对等方接收到彩虹FEC的标签映射广告，而它仍然保留对应的红色或蓝色FEC的标签映射，那么LSR必须继续使用红色或蓝色FEC的标签映射，并且它必须发送对应于彩虹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接收到红色或蓝色FEC的标签映射播发，但仍保留相应彩虹FEC的标签映射，则LSR必须继续使用彩虹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.
在命名代理节点计算中，每个多宿主前缀由附加到两个实际代理节点连接路由器的概念代理节点表示。（如果MRT岛外的同一区域路由器（单独连接到MRT岛）播发前缀，则允许使用单个代理节点连接路由器。）MRT岛中的所有路由器执行相同的计算，以确定每个多宿前缀的相同两个代理节点连接路由器。[RFC7811]的第5.9节描述了将一个代理节点连接路由器标识为“红色”和一个多宿前缀标识为“蓝色”的过程，并计算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标签分配程序。一般来说，相同的程序可应用于红色和蓝色FEC标签映射的分布，前提是这些程序是在MRT FEC标签分布的上下文中解释的。下文提供了[RFC5036]中关于MRT FEC标签分发的几个重要概念的正确解释。
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
在为红色和蓝色FEC分配标签映射的上下文中，我们将[RFC5036]中的LDP对等点限制为已协商LDP MRT能力的LDP对等点。为了明确这一区别，在本文件中，我们将使用术语“MRT LDP”
peer" to refer to an LDP peer for which the LDP MRT Capability has been negotiated.
“对等方”指已协商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的下一跳基于MRT红色（蓝色）转发树到与FEC相关联的前缀。
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规定了LSR对FEC下一跳变化的响应。对于最短路径FEC，下一跳可能由于LSR在修改的IGP拓扑数据库上运行最短路径计算而改变。对于红色和蓝色fec，红色和蓝色下一跳可能会随着LSR在修改的IGP拓扑数据库上运行特定MRT算法而改变。
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顺序控制时，它可以仅为（最短路径）FEC启动标签映射的传输，对于该FEC，它具有FEC下一跳的标签映射，或者LSR是出口。最短路径FEC的FEC下一跳基于到与FEC相关联的前缀的最短路径转发树。在分发MRT LDP标签的情况下，本程序的含义如下。当LSR使用LSP顺序控制时，它可以仅针对其具有用于红色（蓝色）FEC下一跳的标签映射的红色（蓝色）FEC，或者对于其LSR是出口的红色（蓝色）FEC，发起标签映射的传输。红色或蓝色FEC下一跳基于MRT红色或蓝色转发树，转发到与FEC相关联的前缀。
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，以确定LSR是否可以为该FEC发起标签映射。特定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本身（包括其一个直接连接的接口）。
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本身（包括其一个直接连接的接口）。
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将LSR的状态限定为相对于特定FEC到特定MRT LDP对等方的出口LSR。因此，[RFC5036]中的几个过程中出现的条件“FEC的LSR出口是否？”需要解释为“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的主下一跳将LSR分类为关于红色或蓝色FEC的出口LSR。代理节点连接路由器和ABR条件（条件2和3）涵盖了这些情况。特别地，岛边界路由器不是红色（蓝色）FEC的出口LSR，除非它也是该FEC的红色（蓝色）代理节点连接路由器。
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通告隐式或显式空标签，即使它可能是最短路径FEC的出口LSR。通常，代理节点连接路由器需要将该前缀的红色或蓝色流量转发给特定的无环路孤岛邻居，这可能不同于下一跳的最短路径。代理节点连接路由器需要接收带有非空标签的红色或蓝色通信量才能正确转发。
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的标签映射。在LSR从ABR接收并保留彩虹FEC的标签映射的情况下，彩虹FEC的标签映射满足对应的红色和蓝色FEC的标签映射存在要求。MRT LDP标签分发上下文中的标签映射存在要求修改为：“LSR以前是否从红色（蓝色）下一跳接收并保留了红色（蓝色）FEC（或相应彩虹FEC）的标签映射？”
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元素完全匹配的条目。”，如果相应的最短路径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”事件的响应，该事件发生在LSR通过路由表学习新（最短路径）FEC时。在MRT FEC的上下文中，如果MRT LDP能力已启用，则当LSR学习到新的最短路径FEC时，LSR除了通常生成的最短路径FEC“识别新FEC”事件外，还应为相应的红色和蓝色FEC生成“识别新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.
彩虹FEC的标签映射只能由ABR在第5.1.1节所述条件下发起。接收彩虹FEC标签映射的ABR邻居不得传播该彩虹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）拓扑来实现的，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路由的多播和单播应用，希望能够对PIM MT-ID使用与MPLS MT-ID相同的数值。为了实现这种简化，本文档中分配的MPLS MT-ID值在1到4095的范围内。“MPLS多拓扑标识符”注册表通过列出3948到3995之间的值以及与MRT相关的MPLS MT-ID值来反映这一点。这允许51个与MRT相关的MPLS MT-ID值直接映射到PIM MT-ID值，其中包含25个带有红色和蓝色MT-ID对的MRT配置文件，另外一个用于Rainbow MPLS MT-ID值。[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类型名称空间”下的“标签分发协议（LDP）参数”注册表为新LDP能力TLV分配了一个值：MRT能力TLV（0x050E）。
Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ -----------------
0x050E MRT Capability TLV RFC 8320
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
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]中分配了三个值：
3945 Rainbow MRT MPLS MT-ID
3945彩虹地铁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蓝色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多拓扑标识符”注册表的目的字段更改为“未分配（用于未来的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]
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.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<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能力”，RFC 5561，DOI 10.17487/RFC55611909年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多拓扑ID（MT-ID）连接属性”，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扩展”，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，“使用最大冗余树计算IP/LDP快速重路由的算法（MRT-FRR）”，RFC 7811，DOI 10.17487/RFC78112016年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，“使用最大冗余树的IP/LDP快速重路由架构（MRT-FRR）”，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]Cotton，M.，Leiba，B.，和T.Narten，“在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，“使用最大冗余树的多播保护架构”，正在进行的工作，草稿-Atlas-rtgwg-mrt-mc-ARCH-022013年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，“最大冗余树（MRT）的中间系统到中间系统（IS-IS）扩展”，正在进行的工作，草案-ietf-isis-MRT-032017年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扩展”，正在进行的工作，草案-ietf-OSPF-MRT-032017年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]Bryant，S.，Atlas，A.，和C.Bowers，“路由定时器参数同步”，正在进行的工作，草稿-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：LSP隧道RSVP的扩展”，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同步”，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，“多点LDP（mLDP）节点保护”，RFC 7715，DOI 10.17487/RFC7715，2016年1月<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
美国马萨诸塞州韦斯特福德科技园大道10号Alia Atlas Juniper Networks 01886
Email: akatlas@juniper.net
Email: akatlas@juniper.net
Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号Kishore Tiruveedhula Juniper Networks美国01886
Email: kishoret@juniper.net
Email: kishoret@juniper.net
Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
Chris Bowers Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美利坚合众国
Email: cbowers@juniper.net
Email: cbowers@juniper.net
Jeff Tantsura Individual United States of America
Jeff Tantsura美利坚合众国个人
Email: jefftant.ietf@gmail.com
Email: jefftant.ietf@gmail.com
IJsbrand Wijnands Cisco Systems, Inc.
IJsbrand Wijnands思科系统公司。
Email: ice@cisco.com
Email: ice@cisco.com