< draft-ietf-mpls-ldp-mrt-05.txt   draft-ietf-mpls-ldp-mrt-06.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: August 21, 2017 Juniper Networks Expires: February 18, 2018 Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
February 17, 2017 August 17, 2017
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-05 draft-ietf-mpls-ldp-mrt-06
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 August 21, 2017. This Internet-Draft will expire on February 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5
4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5
4.1.1. Interaction of MRT Capability and MT Capability . . . 6 4.1.1. Interaction of MRT Capability and MT Capability . . . 6
4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6 4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6
4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7 4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7
4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7
5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 4.4. Interaction of MRT-related LDP advertisements with the
5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8 MRT topology and computations . . . . . . . . . . . . . . 8
5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 8
5.1.2. Proxy-node attachment router behavior . . . . . . . . 9 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 9
5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 9
5.1.2. Proxy-node attachment router behavior . . . . . . . . 10
5.2. LDP protocol procedures in the context of MRT label 5.2. LDP protocol procedures in the context of MRT label
distribution . . . . . . . . . . . . . . . . . . . . . . 10 distribution . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 11
5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 11
5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 11 5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 12
5.2.4. Use of Rainbow FEC to satisfy label mapping existence 5.2.4. Use of Rainbow FEC to satisfy label mapping existence
requirements in RFC5036 . . . . . . . . . . . . . . . 12 requirements in RFC5036 . . . . . . . . . . . . . . . 13
5.2.5. Validating FECs in routing table . . . . . . . . . . 13 5.2.5. Validating FECs in routing table . . . . . . . . . . 14
5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 14
5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Potential restrictions on MRT-related MT-ID values imposed 7. Potential restrictions on MRT-related MT-ID values imposed
by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 14 by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 [RFC7812]. It is necessary to be LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be
familiar with the architecture in [RFC7812] to understand how and why familiar with the architecture in [RFC7812] to understand how and why
the LDP extensions for behavior are needed. the 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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
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 RFC 2119[RFC2119]
3. Terminology 3. Terminology
For ease of reading, some of the terminology defined in [RFC7812] is For ease of reading, some of the terminology defined in [RFC7812] is
repeated here. repeated here. Please refer to the Section 3 of [RFC7812] for a more
complete list.
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.
Redundant trees can always 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.
In graphs that are not 2-connected, it is not possible to compute In graphs that are not 2-connected, it is not possible to compute
RTs. However, it is possible to compute MRTs. MRTs are maximally RTs. However, it is possible to compute MRTs. MRTs are maximally
redundant in the sense that they are as redundant as possible redundant in the sense that they are as redundant as possible
given the constraints of the network graph. 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 describe the associated forwarding topology and MPLS used to describe the associated forwarding topology and MPLS
Multi-Topology IDentifier (MT-ID). Specifically, MRT-Red is the Multi-Topology IDentifier (MT-ID).
decreasing MRT where links in the GADAG are taken in the direction
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 MPLS MT- used to described the associated forwarding topology and MPLS MT-
ID. Specifically, MRT-Blue is the increasing MRT where links in ID.
the GADAG are taken in the direction from a lower topologically
ordered node to a higher one.
Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
multiple MRT forwarding topologies and to the default forwarding multiple MRT forwarding topologies and to the default forwarding
topology. This is referred to as the Rainbow MRT MPLS MT-ID and 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 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). always be advertised to all peers for the same (MT-ID, Prefix).
MRT Island: The set of routers that support a particular MRT MRT Island: The set of routers that support a particular MRT
profile and the links connecting them that support MRT. profile and the links connecting them that support MRT.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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. assigned by IANA from the MPLS MT-ID space.
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. [RFC7812] To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812]
defines the Default MRT Profile. Section 8 of this document defines the Default MRT Profile. Section 8 of the current document
specifies code points for the MRT-Red and MRT-Blue MPLS MT-IDs specifies the values in the MPLS Multi-Topology Identifiers Registry
associated with the Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT- for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the Default
LDP-5). MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5).
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.
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.
4.4. Interaction of MRT-related LDP advertisements with the MRT
topology and computations
[RFC7811] and [RFC7812] describe how the MRT topology is created
based on information in IGP advertisements. The MRT topology and
computations rely on 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.
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.
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 SPF algorithm is
run by the IGP.
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
immediately usable by the point of local repair in the event of a immediately usable by the point of local repair in the event of a
failure. failure.
In this section, we will use the term "shortest path FEC" to refer to In this section, we will use the term "shortest path FEC" to refer to
the usual FEC associated with the shortest path destination-based the usual FEC associated with the shortest path destination-based
forwarding tree for a given prefix as determined by the IGP. We will 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 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 with the MRT-Red and MRT-Blue destination-based forwarding trees for
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.
[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.
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 [RFC7812] describes the need for an area border Section 10.1 of [RFC7812] describes the need for an area border
router (ABR) to have different neighbors use different MPLS labels router (ABR) to have different neighbors use different MPLS labels
when sending traffic to the ABR for the same FEC. The method to 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 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 [RFC7812]. Here we provide a brief summary. To those LDP peers in
the same area as the best route to the destination, the ABR the same area as the best route to the destination, the ABR
skipping to change at page 9, line 11 skipping to change at page 10, line 8
behavior to non-best-area behavior for a given destination, and vice 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, versa. When the ABR requires best-area behavior for a red(blue) FEC,
it MUST withdraw any existing label mappings advertisements for the it MUST withdraw any existing label mappings advertisements for the
corresponding rainbow FEC and advertise label mappings 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. When the ABR requires non-best-area behavior for a
red(blue) FEC, it MUST withdraw any existing label mappings for both red(blue) FEC, it MUST withdraw any existing label mappings for both
red and blue FECs and advertise label mappings for the corresponding red and blue FECs and advertise label mappings for the corresponding
Rainbow FEC label binding. Rainbow FEC label binding.
In this transition, an ABR should never advertise a red(blue) FEC In this transition, an ABR should never advertise a red(blue) FEC
before withdrawing the corrsponding rainbow FEC (or vice versa). before withdrawing the corresponding rainbow FEC (or vice versa).
However, should this situation occur, the expected behavior of an LSR However, should this situation occur, the expected behavior of an LSR
receiving these conflicting advertisements is defined as foll If an receiving these conflicting advertisements is defined as foll If an
LSR receives a label mapping advertisement for a rainbow FEC from 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 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 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 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,
skipping to change at page 9, line 41 skipping to change at page 10, line 38
Island. It also covers the scenario of a prefix being advertised by Island. It also covers the scenario 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. [RFC7811] describes the procedure for multi-homed prefix. Section 5.9 of [RFC7811] describes the procedure
identifying one proxy-node attachment router as "red" and one as for identifying one proxy-node attachment router as "red" and one as
"blue" with respect to the multi-homed prefix, and computing the MRT "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 red and blue next-hops to reach those red and blue 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
skipping to change at page 15, line 49 skipping to change at page 16, line 49
TBD-MRT-LDP-4 Default Profile MRT-Red 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] TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft]
3948-3995 Unassigned (for future MRT-related values) [This draft] 3948-3995 Unassigned (for future MRT-related values) [This draft]
3996-4095 Reserved for Experimental Use [RFC7307] 3996-4095 Reserved for Experimental Use [RFC7307]
4096-65534 Unassigned (for MPLS topologies) 4096-65534 Unassigned (for MPLS topologies)
65535 Wildcard Topology [RFC7307] 65535 Wildcard Topology [RFC7307]
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, Greg Mirsky, and Uma Chunduri for their comments Bryant, Mach Chen, Greg Mirsky, Uma Chunduri and Tony Przygienda for
and suggestions. their comments and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, <https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5561>. 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>. <https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7307>. editor.org/info/rfc7307>.
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
DOI 10.17487/RFC7811, June 2016, DOI 10.17487/RFC7811, June 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7811>. editor.org/info/rfc7811>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<http://www.rfc-editor.org/info/rfc7812>. <https://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]
skipping to change at page 17, line 16 skipping to change at page 18, line 22
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-02 (work in progress), May 2016. 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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <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
 End of changes. 26 change blocks. 
56 lines changed or deleted 95 lines changed or added

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