One document matched: draft-ietf-mpls-ldp-mrt-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC4915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4915.xml">
<!ENTITY RFC4970 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4970.xml">
<!ENTITY RFC5340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC5561 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5561.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml">
<!ENTITY RFC7307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7307.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml">
<!ENTITY I-D.atlas-rtgwg-mrt-mc-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-rtgwg-mrt-mc-arch.xml">
<!ENTITY I-D.ietf-mpls-ldp-multi-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-multi-topology.xml">
<!ENTITY I-D.wijnands-mpls-mldp-node-protection SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijnands-mpls-mldp-node-protection.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-mpls-ldp-mrt-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="LDP Extensions to Support MRT">LDP Extensions to Support Maximally Redundant Trees</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Kishore Tiruveedhula" initials="K." surname="Tiruveedhula">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>kishoret@juniper.net</email>
</address>
</author>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>cbowers@juniper.net</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
<organization>Individual</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>jefftant.ietf@gmail.com</email>
</address>
</author>
<author fullname="IJsbrand Wijnands" initials="IJ.W." surname="Wijnands">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>ice@cisco.com</email>
</address>
</author>
<date day="18" month="May" year="2016"/>
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>This document specifies extensions to the Label Distribution
Protocol(LDP) to support the creation of label-switched paths for
Maximally Redundant Trees (MRT). A prime use of MRTs is for
unicast and multicast IP/LDP Fast-Reroute, which we will refer to
as MRT-FRR. </t>
<t>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 LSRs and LERs
advertising the MRT Capability.</t>
<t>MRT-FRR uses LDP multi-topology extensions and requires three
different multi-topology IDs to be allocated from the MPLS MT-ID
space.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the LDP signaling extension and
associated behavior necessary to support the architecture that
defines how IP/LDP Fast-Reroute can use MRTs <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. It is necessary
to be familiar with the architecture in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> to understand how
and why the LDP extensions for behavior are needed.</t>
<t>At least one common standardized algorithm (e.g. the MRT
Lowpoint algorithm explained and fully documented in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>) is required 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 <xref
target="I-D.ietf-ospf-mrt"/>. Extension to IS-IS are defined in
<xref target="I-D.ietf-isis-mrt"/>. </t>
<t>MRT can also be used to protect multicast traffic (signalled
via PIM or mLDP) using either global protection or local
protection <xref target="I-D.atlas-rtgwg-mrt-mc-arch"/>. An MRT
path can be used to provide node-protection for mLDP traffic via
the mechanisms described in <xref
target="I-D.wijnands-mpls-mldp-node-protection"/>; an MRT path
can also be used to provide link protection for mLDP
traffic.</t>
<t>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 <xref target="RFC7307"/> to signal
Forwarding Equivalency Classes (FECs) for these two sets of
forwarding trees, MRT-Blue and MRT-Red.</t>
<t>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 <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> and the
worst-case network convergence time can be flooded via the
extension in Section 7 of <xref
target="I-D.ietf-ospf-mrt"/>.</t>
<t>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.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/></t>
</section>
<section title="Terminology">
<t>For ease of reading, some of the terminology defined in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> is repeated here.</t>
<t><list style="hanging">
<t hangText="Redundant Trees (RT): ">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. These can be computed in 2-connected
graphs.</t>
<t hangText="Maximally Redundant Trees (MRT): ">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. Any RT is an MRT but many MRTs are not RTs. The
two MRTs are referred to as MRT-Blue and MRT-Red.</t>
<t hangText="MRT-Red: "> MRT-Red is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Red is the decreasing MRT
where links in the GADAG are taken in the direction from a higher
topologically ordered node to a lower one.</t>
<t hangText="MRT-Blue: "> MRT-Blue is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Blue is the increasing MRT
where links in the GADAG are taken in the direction from a lower
topologically ordered node to a higher one.</t>
<t hangText="Rainbow MRT MT-ID: "> It is useful to have an MT-ID
that refers to the multiple MRT topologies and to the default
topology. This is referred to as the Rainbow MRT 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).</t>
<t hangText="MRT Island: "> From the computing router, the set of
routers that support a particular MRT profile and are connected
via MRT-eligible links.</t>
<t hangText="Island Border Router (IBR): "> A router in the MRT
Island that is connected to a router not in the MRT Island and
both routers are in a common area or level.</t>
<t hangText="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..</t>
</list></t>
</section>
<section title="Overview of LDP Signaling Extensions for MRT">
<t>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.
<list style="numbers">
<t>Sending and receiving multi-topology FEC elements, as defined in
<xref target="RFC7307"/>.</t>
<t>Understanding the Rainbow MRT MT-ID and applying the associated
labels to all relevant MT-IDs.</t>
<t>Advertising the Rainbow MRT FEC to the appropriate neighbors for
the appropriate prefix.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<section title="MRT Capability Advertisement">
<t>A new MRT Capability Parameter TLV is defined in accordance with
LDP Capability definition guidelines<xref target="RFC5561"/>.</t>
<t>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 LSP paths detailed in this document.
If the peer has not advertised the MRT capability, then it
indicates that LSR does not support MRT procedures.</t>
<t> 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.</t>
<t>The following is the format of the MRT Capability Parameter.</t>
<figure title="MRT Capability TLV Format">
<artwork align="center"><![CDATA[
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 (IANA) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:
<list style="hanging">
<t hangText="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.</t>
<t hangText="F-bit: "> The forward unknown TLV bit MUST be 0 as
required by Section 3 of <xref target="RFC5561"/>.</t>
<t hangText="MRT Capability: "> TBD-MRT-LDP-1 (To Be Allocated by
IANA)</t>
<t hangText="Length: "> The length (in octets) of TLV. Its value is
1.</t>
<t hangText="S-bit: "> The State bit MUST be 1 if used in LDP
"Initialization" message. MAY be set to 0 or 1 in dynamic
"Capability" message to advertise or withdraw the capability
respectively, as described in <xref target="RFC5561"/>.</t>
</list></t>
<section title="Interaction of MRT Capability and MT Capability">
<t> An LSR advertising the LDP MRT Capability MUST also advertise the
LDP Multi-topology (MT) capability. If an LSR negotiates LDP MRT
Capability with an LDP neighbor without also negotiating the LDP MT
Capability, the LSR MUST behave as if LDP MRT Capability has not been
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.
</t>
</section>
<section title="Interaction of LDP MRT Capability with IPv4 and IPv6">
<t>The MRT LDP Capability Advertisement does not distinguish between
IPv4 and IPv6 address families. An LSR which 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.
</t>
</section>
</section>
<section title="Use of the Rainbow MRT MT-ID">
<t>Section 10.1 of <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> 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 <xref
target="sec_rainbow"/>.
</t>
<t>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 <xref target="sec_egress_lsr"/> for
more details.
</t>
<t> The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be
assigned by IANA from the MPLS MT-ID space. Prototype experiments have
used the value 3999.</t>
</section>
<section title="MRT-Blue and MRT-Red FECs">
<t>To provide MRT support in LDP, the MT Prefix FEC is used.
<xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>
defines the Default MRT Profile. This document
contains the IANA request for the MRT-Red and MRT-Blue MPLS MT-IDs
associated with the Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).</t>
<t>The MT Prefix FEC encoding is defined in <xref target="RFC7307"/>
and is used without alteration for advertising label mappings for
MRT-Blue, MRT-Red and Rainbow MRT FECs.</t>
</section>
</section>
<section title="LDP MRT FEC Advertisements">
<t>This sections describes how and when labels for MRT-Red and
MRT-Blue FECs are advertised. The associated LSPs must be created
before a failure occurs, in order to provide protection paths which
are immediately usable by the point of local repair in the event of a
failure.</t>
<t> 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.
</t>
<t> We first describe label distribution behavior specific to MRT.
Then we provide the correct interpretation of several important
concepts in <xref target="RFC5036"/> in the context of MRT FEC label
distribution.</t>
<section title="MRT-specific behavior">
<section anchor="sec_rainbow" title="ABR behavior and use of the Rainbow FEC">
<t>Section 10.1 of <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> 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. The
method to accomplish this using the Rainbow MRT MT-ID is described in
detail in <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. 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.
</t>
<t>For all other LDP peers supporting MRT, the ABR advertises a
FEC-label binding for the Rainbow MRT MT-ID scoped FEC with the label
corresponding to 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.
</t>
<t>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.</t>
<t> 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.
</t>
<t> 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. If an
LSR receives a label mapping advertisement for 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.
</t>
</section>
<section anchor="sec_proxy_node" title="Proxy-node attachment router behavior">
<t>Section 11.2 of <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> 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 a multiple routers in the MRT Island.
</t>
<t>In the named proxy-node calculation, each multi-homed prefix is
represented by a conceptual proxy-node which 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.
<xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> 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. </t>
<t> 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 a 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 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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="LDP protocol procedures in the context of MRT label distribution">
<t> <xref target="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 <xref target="RFC5036"/> in the context of MRT
FEC label distribution is provided below.</t>
<section title="LDP peer in RFC5036">
<t> In the context of distributing label mappings for red and blue
FECs, we restrict LDP peer in <xref target="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.</t>
</section>
<section title="Next hop in RFC5036">
<t> Several procedures in <xref target="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 <xref
target="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.
</t>
<t> For example, Appendix A.1.7. of <xref target="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. </t>
<t> As another example, Section 2.6.1.2 of <xref target="RFC5036"/>
specifies how 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.</t>
</section>
<section anchor="sec_egress_lsr" title="Egress LSR in RFC5036">
<t> Procedures in <xref target="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 loop
detection procedures in <xref target="RFC5036"/>. Section 2.6.1.2 of
<xref target="RFC5036"/> specifies the conditions under which an LSR
may act as an egress LSR with respect to a particular (shortest path)
FEC.
<list style="numbers">
<t>The (shortest path) FEC refers to the LSR itself (including one
of its directly attached interfaces). </t>
<t>The next hop router for the (shortest path) FEC is outside of the
Label Switching Network. </t>
<t>(Shortest path) FEC elements are reachable by crossing a routing
domain boundary.</t>
</list>
</t>
<t> 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:
<list style="numbers">
<t>The prefix associated with the red(blue) FEC refers to the LSR
itself (including one of its directly attached interfaces). </t>
<t>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.</t>
<t>The LSR is an area border router (ABR) AND the MRT LDP peer
requires non-best-area advertising and forwarding behavior for the
prefix associated with the FEC.</t>
</list>
</t>
<t> 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 <xref target="RFC5036"/> needs to be interpreted
as "Is LSR egress for FEC with respect to Peer?" </t>
<t> Also note that there is no explicit condition that allows an LSR
to be classified as an egress LSR with respect 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.
</t>
<t> 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.
</t>
</section>
<section title="Use of Rainbow FEC to satisfy label mapping existence requirements in RFC5036">
<t>Several procedures in <xref target="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?"
</t>
<t>As an example, this behavior allows an LSR which 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.
</t>
</section>
<section title="Validating FECs in routing table">
<t> In <xref target="RFC5036"/> an LSR uses its routing table to
validate prefixes associated with shortest path FECs. For example,
section 3.5.7.1 of <xref target="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.
</t>
</section>
<section title="Recognizing new FECs">
<t> Section A.1.6 of <xref target="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, when MRT LDP capability has been enabled, when an
LSR learns a new shortest path FEC, it should generate "Recognize New
FEC" events for the corresponding red and blue FECs, in addition to
the "Recognize New FEC" event for the shortest path FEC.
</t>
</section>
<section title="Not propagating Rainbow FEC label mappings">
<t> A label mapping for the Rainbow FEC should only be originated by
an ABR under the conditions described in <xref target="sec_rainbow"/>.
A neighbor of the ABR that receives a label mapping for the Rainbow
FEC MUST NOT propagate a label mapping for that Rainbow FEC.
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>The labels distributed by the extensions in this document create
additional forwarding paths that do not following 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.</t>
<t>It should be noted that the creation of non-shortest forwarding
paths is not unique to MRT.</t>
</section>
<section title="Potential restrictions on MRT-related MT-ID values
imposed by RFC6420">
<t> 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 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 <xref target="RFC6420"/> can be
used to establish MRT-based multicast distribution trees. <xref
target="RFC6420"/> limits the values of the PIM MT-ID from 1 through
4095.</t>
<t>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
application using MRT routes constructed using the same MRT profile. In
order to enable this simplification, the MPLS MT-ID values assigned in
this document need to fall in the range 1 through 4095. The IANA request
below reflects this by requesting that the MPLS MT-ID values from 3945
through 3995 be used for MRT-related MPLS MT-ID values. This allows for
51 MRT-related MPLS MT-ID values which 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. <xref
target="RFC7307"/> designates the MPLS MT-ID range 6-3995 as
"Unassigned(for future IGP topologies)". The IANA request below changes
the guidance for MT-ID range 3948-3995 to "Unassigned (for future
MRT-related values)".
</t>
</section>
<section title="IANA Considerations">
<t>IANA is requested to allocate a value for the new LDP Capability
TLV (the first free value in the range 0x0500 to 0x05FF) from the
Label Distribution Protocol (LDP) Parameters
registry "TLV Type Name Space": MRT Capability TLV (TBD-MRT-LDP-1).
</t>
<figure>
<artwork align="center"><![CDATA[
Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ -----------------
TBD-MRT-LDP-1 MRT Capability TLV [This draft]
]]></artwork>
</figure>
<t>IANA is requested to allocate a value for the new LDP Status Code
(the first free value in the range 0x00000032-0x00000036) from the
Label Distribution Protocol (LDP) Parameters
registry "Status Code Name Space": "MRT Capability negotiated
without MT Capability" (TBD-MRT-LDP-2). The Status Code E-bit is
set to 0.
</t>
<figure>
<artwork align="center"><![CDATA[
Value E Description Reference Notes / Reg. Date
-------------- - ------------------ ------------ -----------------
TBD-MRT-LDP-2 0 MRT Capability [This draft]
negotiated without
MT Capability
]]></artwork>
</figure>
<t>IANA is requested to allocate three values from the MPLS Multi-Topology
Identifiers Registry <xref target="RFC7307"/>.
<list>
<t>Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945 </t>
<t>Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested value: 3946 </t>
<t>Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested value: 3947 </t>
</list>
IANA is also requested to change the purpose field of the MPLS
Multi-Topology Identifiers Registry for MT-ID range 3948-3995 to
"Unassigned (for future MRT-related values)", assuming the above
suggested values are assigned. The Registration procedure for the entire
registry remains "Standards Action". The entire registry after implementing
the above requests is shown below.
</t>
<figure>
<artwork align="center"><![CDATA[
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)
TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft]
TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft]
TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft]
3948-3995 Unassigned (for future MRT-related values)
3996-4095 Reserved for Experimental Use [RFC7307]
4096-65534 Unassigned (for MPLS topologies)
65535 Wildcard Topology [RFC7307]
]]></artwork>
</figure>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ross Callon, Loa Andersson,
Stewart Bryant, Mach Chen, and Greg Mirsky for their
suggestions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC5561;
&RFC5036;
&RFC7307;
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-architecture-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-algorithm-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6420.xml"?>
</references>
<references title="Informative References">
&RFC2119;
&I-D.atlas-rtgwg-mrt-mc-arch;
&I-D.wijnands-mpls-mldp-node-protection;
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-mrt-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-mrt-00.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 08:38:23 |