draft-ietf-mpls-ldp-mrt-03.txt   draft-ietf-mpls-ldp-mrt-04.txt 
MPLS Working Group A. Atlas MPLS Working Group A. Atlas
Internet-Draft K. Tiruveedhula Internet-Draft K. Tiruveedhula
Intended status: Standards Track C. Bowers Intended status: Standards Track C. Bowers
Expires: November 19, 2016 Juniper Networks Expires: April 2, 2017 Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
May 18, 2016 September 29, 2016
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-03 draft-ietf-mpls-ldp-mrt-04
Abstract Abstract
This document specifies extensions to the Label Distribution This document specifies extensions to the Label Distribution
Protocol(LDP) to support the creation of label-switched paths for Protocol(LDP) to support the creation of label-switched paths for
Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast 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. and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.
The sole protocol extension to LDP is simply the ability to advertise The sole protocol extension to LDP is simply the ability to advertise
an MRT Capability. This document describes that extension and the an MRT Capability. This document describes that extension and the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2016. This Internet-Draft will expire on April 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document describes the LDP signaling extension and associated This document describes the LDP signaling extension and associated
behavior necessary to support the architecture that defines how IP/ behavior necessary to support the architecture that defines how IP/
LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be
It is necessary to be familiar with the architecture in familiar with the architecture in [RFC7812] to understand how and why
[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the the LDP extensions for behavior are needed.
LDP extensions for behavior are needed.
At least one common standardized algorithm (e.g. the MRT Lowpoint At least one common standardized algorithm (e.g. the MRT Lowpoint
algorithm explained and fully documented in algorithm explained and fully documented in [RFC7811]) is required so
[I-D.ietf-rtgwg-mrt-frr-algorithm]) is required so that the routers that the routers supporting MRT computation consistently compute the
supporting MRT computation consistently compute the same MRTs. LDP same MRTs. LDP depends on an IGP for computation of MRTs and
depends on an IGP for computation of MRTs and alternates. Extensions alternates. Extensions to OSPF are defined in [I-D.ietf-ospf-mrt].
to OSPF are defined in [I-D.ietf-ospf-mrt]. Extension to IS-IS are Extension to IS-IS are defined in [I-D.ietf-isis-mrt].
defined in [I-D.ietf-isis-mrt].
MRT can also be used to protect multicast traffic (signalled via PIM MRT can also be used to protect multicast traffic (signalled via PIM
or mLDP) using either global protection or local protection or mLDP) using either global protection or local protection
[I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide [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 node-protection for mLDP traffic via the mechanisms described in
[I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be [I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be
used to provide link protection for mLDP traffic. used to provide link protection for mLDP traffic.
For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates
two alternate destination-based trees separate from the shortest path two alternate destination-based trees separate from the shortest path
forwarding used during stable operation. LDP uses the multi-topology forwarding used during stable operation. LDP uses the multi-topology
extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs)
for these two sets of forwarding trees, MRT-Blue and MRT-Red. for these two sets of forwarding trees, MRT-Blue and MRT-Red.
In order to create MRT paths and support IP/LDP Fast-Reroute, a new In order to create MRT paths and support IP/LDP Fast-Reroute, a new
capability extension is needed for LDP. An LDP implementation capability extension is needed for LDP. An LDP implementation
supporting MRT MUST also follow the rules described here for supporting MRT MUST also follow the rules described here for
originating and managing FECs related to MRT, as indicated by their originating and managing FECs related to MRT, as indicated by their
multi-topology ID. Network reconvergence is described in multi-topology ID. Network reconvergence is described in [RFC7812]
[I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network and the worst-case network convergence time can be flooded via the
convergence time can be flooded via the extension in Section 7 of extension in Section 7 of [I-D.ietf-ospf-mrt].
[I-D.ietf-ospf-mrt].
IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
node failures in an arbitrary network topology where the failure node failures in an arbitrary network topology where the failure
doesn't partition the network. It can also be deployed doesn't partition the network. It can also be deployed
incrementally; an MRT Island is formed of connected supporting incrementally; an MRT Island is formed of connected supporting
routers and the MRTs are computed inside that island. routers and the MRTs are computed inside that island.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
3. Terminology 3. Terminology
For ease of reading, some of the terminology defined in For ease of reading, some of the terminology defined in [RFC7812] is
[I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. repeated here.
Redundant Trees (RT): A pair of trees where the path from any node 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 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. path from the same node X to the root along the second tree.
These can be computed in 2-connected graphs. Redundant trees can always be computed in 2-connected graphs.
Maximally Redundant Trees (MRT): A pair of trees where the path 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 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 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 minimum number of nodes and the minimum number of links. Each
such shared node is a cut-vertex. Any shared links are cut-links. 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 In graphs that are not 2-connected, it is not possible to compute
referred to as MRT-Blue and MRT-Red. 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-Red: MRT-Red is used to describe one of the two MRTs; it is 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. used to describe the associated forwarding topology and MPLS
Specifically, MRT-Red is the decreasing MRT where links in the Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the
GADAG are taken in the direction from a higher topologically decreasing MRT where links in the GADAG are taken in the direction
ordered node to a lower one. from a higher topologically ordered node to a lower one.
MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is 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. used to described the associated forwarding topology and MPLS MT-
Specifically, MRT-Blue is the increasing MRT where links in the ID. Specifically, MRT-Blue is the increasing MRT where links in
GADAG are taken in the direction from a lower topologically the GADAG are taken in the direction from a lower topologically
ordered node to a higher one. ordered node to a higher one.
Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
multiple MRT topologies and to the default topology. This is multiple MRT forwarding topologies and to the default forwarding
referred to as the Rainbow MRT MT-ID and is used by LDP to reduce topology. This is referred to as the Rainbow MRT MPLS MT-ID and
signaling and permit the same label to always be advertised to all is used by LDP to reduce signaling and permit the same label to
peers for the same (MT-ID, Prefix). always be advertised to all peers for the same (MT-ID, Prefix).
MRT Island: From the computing router, the set of routers that MRT Island: The set of routers that support a particular MRT
support a particular MRT profile and are connected via MRT- profile and the links connecting them that support MRT.
eligible links.
Island Border Router (IBR): A router in the MRT Island that is Island Border Router (IBR): A router that is not in the MRT Island
connected to a router not in the MRT Island and both routers are but is adjacent to an IBR and in the same area/level as the IBR.
in a common area or level.
Island Neighbor (IN): A router that is not in the MRT Island but is 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.. adjacent to an IBR and in the same area/level as the IBR..
4. Overview of LDP Signaling Extensions for MRT 4. Overview of LDP Signaling Extensions for MRT
Routers need to know which of their LDP neighbors support MRT. This Routers need to know which of their LDP neighbors support MRT. This
is communicated using the MRT Capability Advertisement. Supporting is communicated using the MRT Capability Advertisement. Supporting
MRT indicates several different aspects of behavior, as listed below. MRT indicates several different aspects of behavior, as listed below.
skipping to change at page 7, line 16 skipping to change at page 7, line 14
and shortest path FEC-label bindings for IPv4 only (or IPv6 only) and shortest path FEC-label bindings for IPv4 only (or IPv6 only)
would be expected to advertise MRT-related FEC-label binding for IPv4 would be expected to advertise MRT-related FEC-label binding for IPv4
only (or IPv6 only). An LSR advertising the MRT LDP capability and only (or IPv6 only). An LSR advertising the MRT LDP capability and
shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected
to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6. to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
In this scenario, advertising MRT-related FEC-label bindings only for In this scenario, advertising MRT-related FEC-label bindings only for
IPv4 only (or only for IPv6) is not supported. IPv4 only (or only for IPv6) is not supported.
4.2. Use of the Rainbow MRT MT-ID 4.2. Use of the Rainbow MRT MT-ID
Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the Section 10.1 of [RFC7812] describes the need for an area border
need for an area border router (ABR) to have different neighbors use router (ABR) to have different neighbors use different MPLS labels
different MPLS labels when sending traffic to the ABR for the same when sending traffic to the ABR for the same FEC. More detailed
FEC. More detailed discussion of the Rainbow MRT MT-ID is provided discussion of the Rainbow MRT MT-ID is provided in Section 5.1.1 of
in Section 5.1.1. the current document.
Another use for the Rainbow MRT MT-ID is for an LSR to send the 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 Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
penultimate-hop-popping for all three types of FECs (shortest path, penultimate-hop-popping for all three types of FECs (shortest path,
red, and blue). The EXPLICIT_NULL label advertised using the Rainbow 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 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 only scenario in which it is generally useful to advertise the
implicit or explicit null label for all three FEC types is when 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. FEC refers to the LSR itself. See Section 5.2.3 for more details.
The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be 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 assigned by IANA from the MPLS MT-ID space. Prototype experiments
have used the value 3999. have used the value 3999.
4.3. MRT-Blue and MRT-Red FECs 4.3. MRT-Blue and MRT-Red FECs
To provide MRT support in LDP, the MT Prefix FEC is used. To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812]
[I-D.ietf-rtgwg-mrt-frr-architecture] defines the Default MRT defines the Default MRT Profile. This document contains the IANA
Profile. This document contains the IANA request for the MRT-Red and request for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the
MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (TBD- Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).
MRT-LDP-4 and TBD-MRT-LDP-5).
The MT Prefix FEC encoding is defined in [RFC7307] and is used The MT Prefix FEC encoding is defined in [RFC7307] and is used
without alteration for advertising label mappings for MRT-Blue, MRT- without alteration for advertising label mappings for MRT-Blue, MRT-
Red and Rainbow MRT FECs. Red and Rainbow MRT FECs.
5. LDP MRT FEC Advertisements 5. LDP MRT FEC Advertisements
This sections describes how and when labels for MRT-Red and MRT-Blue This sections describes how and when labels for MRT-Red and MRT-Blue
FECs are advertised. The associated LSPs must be created before a FECs are advertised. The associated LSPs must be created before a
failure occurs, in order to provide protection paths which are failure occurs, in order to provide protection paths which are
skipping to change at page 8, line 22 skipping to change at page 8, line 20
a given prefix as determined by a particular MRT algorithm. a given prefix as determined by a particular MRT algorithm.
We first describe label distribution behavior specific to MRT. Then We first describe label distribution behavior specific to MRT. Then
we provide the correct interpretation of several important concepts we provide the correct interpretation of several important concepts
in [RFC5036] in the context of MRT FEC label distribution. in [RFC5036] in the context of MRT FEC label distribution.
5.1. MRT-specific behavior 5.1. MRT-specific behavior
5.1.1. ABR behavior and use of the Rainbow FEC 5.1.1. ABR behavior and use of the Rainbow FEC
Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the Section 10.1 of [RFC7812] describes the need for an area border
need for an area border router (ABR) to have different neighbors use router (ABR) to have different neighbors use different MPLS labels
different MPLS labels when sending traffic to the ABR for the same when sending traffic to the ABR for the same FEC. The method to
FEC. The method to accomplish this using the Rainbow MRT MT-ID is accomplish this using the Rainbow MRT MT-ID is described in detail in
described in detail in [I-D.ietf-rtgwg-mrt-frr-architecture]. Here [RFC7812]. Here we provide a brief summary. To those LDP peers in
we provide a brief summary. To those LDP peers in the same area as the same area as the best route to the destination, the ABR
the best route to the destination, the ABR advertises two different advertises two different labels corresponding to the MRT-Red and MRT-
labels corresponding to the MRT-Red and MRT-Blue forwarding trees for Blue forwarding trees for the destination. An LDP peer receiving
the destination. An LDP peer receiving these advertisements forwards these advertisements forwards MRT traffic to the ABR using these two
MRT traffic to the ABR using these two different labels, depending on different labels, depending on the FEC of the traffic. We refer to
the FEC of the traffic. We refer to this as best-area advertising this as best-area advertising and forwarding behavior, which is
and forwarding behavior, which is identical to normal MRT behavior. identical to normal MRT behavior.
For all other LDP peers supporting MRT, the ABR advertises a FEC- 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 label binding for the Rainbow MRT MT-ID scoped FEC with the label
corresponding to the default forwarding tree for the destination. An corresponding to the default forwarding tree for the destination. An
LDP peer receiving this advertisement forwards MRT traffic to the ABR 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 using this label, for both MRT Red and MRT Blue traffic. We refer to
this as non-best-area advertising and forwarding behavior. this as non-best-area advertising and forwarding behavior.
The use of the Rainbow-FEC by the ABR for non-best-area The use of the Rainbow-FEC by the ABR for non-best-area
advertisements is RECOMMENDED. An ABR MAY advertise the label for advertisements is RECOMMENDED. An ABR MAY advertise the label for
skipping to change at page 9, line 26 skipping to change at page 9, line 23
mapping for the red or blue FEC, and it MUST send a Label Release mapping for the red or blue FEC, and it MUST send a Label Release
Message corresponding to the rainbow FEC label advertisement. If an Message corresponding to the rainbow FEC label advertisement. If an
LSR receives a label mapping advertisement for red or blue FEC while LSR receives a label mapping advertisement for red or blue FEC while
it still retains a label mapping for the corresponding rainbow FEC, it still retains a label mapping for the corresponding rainbow FEC,
the LSR MUST continue to use the label mapping for the 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 and it MUST send a Label Release Message corresponding to the red or
blue FEC label advertisement. blue FEC label advertisement.
5.1.2. Proxy-node attachment router behavior 5.1.2. Proxy-node attachment router behavior
Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes how Section 11.2 of [RFC7812] describes how MRT provides FRR protection
MRT provides FRR protection for multi-homed prefixes using for multi-homed prefixes using calculations involving a named proxy-
calculations involving a named proxy-node. This covers the scenario node. This covers the scenario where a prefix is originated by a
where a prefix is originated by a router in the same area as the MRT router in the same area as the MRT Island, but outside of the MRT
Island, but outside of the MRT Island. It also covers the scenario Island. It also covers the scenario of a prefix being advertised by
of a prefix being advertised by a multiple routers in the MRT Island. a multiple routers in the MRT Island.
In the named proxy-node calculation, each multi-homed prefix is In the named proxy-node calculation, each multi-homed prefix is
represented by a conceptual proxy-node which is attached to two real represented by a conceptual proxy-node which is attached to two real
proxy-node attachment routers. (A single proxy-node attachment proxy-node attachment routers. (A single proxy-node attachment
router is allowed in the case of a prefix advertised by a same area 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 router outside of the MRT Island which is singly connected to the MRT
Island.) All routers in the MRT Island perform the same calculations Island.) All routers in the MRT Island perform the same calculations
to determine the same two proxy-node attachment routers for each to determine the same two proxy-node attachment routers for each
multi-homed prefix. [I-D.ietf-rtgwg-mrt-frr-algorithm] describes the multi-homed prefix. [RFC7811] describes the procedure for
procedure for identifying one proxy-node attachment router as "red" identifying one proxy-node attachment router as "red" and one as
and one as "blue" with respect to the multi-homed prefix, and "blue" with respect to the multi-homed prefix, and computing the MRT
computing the MRT red and blue next-hops to reach those red and blue red and blue next-hops to reach those red and blue proxy-node
proxy-node attachment routers. attachment routers.
In terms of LDP behavior, a red proxy-node attachment router for a 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 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, while the a blue proxy-node attachment router for a given
prefix MUST originate a label mapping for the blue FEC for that prefix MUST originate a label mapping for the blue FEC for that
prefix. If the red(blue) proxy-node attachment router is an Island prefix. If the red(blue) proxy-node attachment router is an Island
Border Router (IBR), then when it receives a packet with the label 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 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 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 selection of the IBR as a proxy-node attachment router. The IBR MUST
skipping to change at page 13, line 38 skipping to change at page 13, line 36
5.2.7. Not propagating Rainbow FEC label mappings 5.2.7. Not propagating Rainbow FEC label mappings
A label mapping for the Rainbow FEC should only be originated by an 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 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 the ABR that receives a label mapping for the Rainbow FEC MUST NOT
propagate a label mapping for that Rainbow FEC. propagate a label mapping for that Rainbow FEC.
6. Security Considerations 6. Security Considerations
The labels distributed by the extensions in this document create The labels distributed by the extensions in this document create
additional forwarding paths that do not following shortest path additional forwarding paths that do not follow shortest path routes.
routes. The transit label swapping operations defining these The transit label swapping operations defining these alternative
alternative forwarding paths are created during normal operations forwarding paths are created during normal operations (before a
(before a failure occurs). Therefore, a malicious packet with an failure occurs). Therefore, a malicious packet with an appropriate
appropriate label injected into the network from a compromised label injected into the network from a compromised location would be
location would be forwarded to a destination along a non-shortest forwarded to a destination along a non-shortest path. When this
path. When this technology is deployed, a network security design technology is deployed, a network security design should not rely on
should not rely on assumptions about potentially malicious traffic assumptions about potentially malicious traffic only following
only following shortest paths. shortest paths.
It should be noted that the creation of non-shortest forwarding paths It should be noted that the creation of non-shortest forwarding paths
is not unique to MRT. is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to
construct forwarding paths that do not follow the shortest path.
7. Potential restrictions on MRT-related MT-ID values imposed by 7. Potential restrictions on MRT-related MT-ID values imposed by
RFC6420 RFC6420
As discussed in the introduction, in addition to unicast forwarding As discussed in the introduction, in addition to unicast forwarding
applications, MRT can be used to provide disjoint trees for multicast applications, MRT can be used to provide disjoint trees for multicast
traffic distribution. In the case of PIM, this is accomplished by 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 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 collection of routes used by PIM to perform the RPF operation when
building source trees. The PIM Multi-Topology ID (MT-ID) Join building source trees. The PIM Multi-Topology ID (MT-ID) Join
skipping to change at page 16, line 9 skipping to change at page 16, line 9
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Ross Callon, Loa Andersson, Stewart The authors would like to thank Ross Callon, Loa Andersson, Stewart
Bryant, Mach Chen, and Greg Mirsky for their suggestions. Bryant, Mach Chen, and Greg Mirsky for their suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-05 (work in progress), July 2015.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
January 2015.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009, DOI 10.17487/RFC5561, July 2009,
<http://www.rfc-editor.org/info/rfc5561>. <http://www.rfc-editor.org/info/rfc5561>.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
<http://www.rfc-editor.org/info/rfc6420>. <http://www.rfc-editor.org/info/rfc6420>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307, King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014, DOI 10.17487/RFC7307, July 2014,
<http://www.rfc-editor.org/info/rfc7307>. <http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc7812>.
10.2. Informative References 10.2. Informative References
[I-D.atlas-rtgwg-mrt-mc-arch] [I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
arch-02 (work in progress), July 2013. arch-02 (work in progress), July 2013.
[I-D.ietf-isis-mrt] [I-D.ietf-isis-mrt]
Li, Z., Wu, N., Zhao, Q., Atlas, A., Bowers, C., and J. Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
Tantsura, "Intermediate System to Intermediate System (IS- Tantsura, "Intermediate System to Intermediate System (IS-
IS) Extensions for Maximally Redundant Trees (MRT)", IS) Extensions for Maximally Redundant Trees (MRT)",
draft-ietf-isis-mrt-00 (work in progress), February 2015. draft-ietf-isis-mrt-02 (work in progress), May 2016.
[I-D.ietf-ospf-mrt] [I-D.ietf-ospf-mrt]
Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
"OSPF Extensions to Support Maximally Redundant Trees", "OSPF Extensions to Support Maximally Redundant Trees",
draft-ietf-ospf-mrt-00 (work in progress), January 2015. draft-ietf-ospf-mrt-02 (work in progress), May 2016.
[I-D.wijnands-mpls-mldp-node-protection] [I-D.wijnands-mpls-mldp-node-protection]
Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
A., and Q. Zhao, "mLDP Node Protection", draft-wijnands- A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-
mpls-mldp-node-protection-04 (work in progress), June mpls-mldp-node-protection-04 (work in progress), June
2013. 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc3209>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
 End of changes. 28 change blocks. 
100 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/