< draft-ietf-mpls-ldp-mrt-01.txt   draft-ietf-mpls-ldp-mrt-02.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: January 5, 2016 Juniper Networks Expires: April 2, 2016 Juniper Networks
J. Tantsura J. Tantsura
Ericsson Ericsson
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
July 4, 2015 September 30, 2015
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-01 draft-ietf-mpls-ldp-mrt-02
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
associated behavior expected for LSRs and LERs advertising the MRT associated behavior expected for LSRs and LERs advertising the MRT
Capability. Capability.
MRT-FRR uses LDP multi-topology extensions and requires three MRT-FRR uses LDP multi-topology extensions and requires three
different multi-topology IDs to be allocated from the LDP MT-ID different multi-topology IDs to be allocated from the MPLS MT-ID
space. space.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 5, 2016. This Internet-Draft will expire on April 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 46 skipping to change at page 2, line 46
distribution . . . . . . . . . . . . . . . . . . . . . . 10 distribution . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10
5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10
5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 11 5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 12
5.2.5. Validating FECs in routing table . . . . . . . . . . 13 5.2.5. Validating FECs in routing table . . . . . . . . . . 13
5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13
5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Potential restrictions on MRT-related MT-ID values imposed
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
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 [I-D.ietf-rtgwg-mrt-frr-architecture].
It is necessary to be familiar with the architecture in It is necessary to be familiar with the architecture in
[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the
LDP extensions for behavior are needed. LDP extensions for behavior are needed.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
Where: Where:
U-bit: The unknown TLV bit MUST be 1. A router that does not 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 recognize the MRT Capability TLV will silently ignore the TLV and
process the rest of the message as if the unknown TLV did not process the rest of the message as if the unknown TLV did not
exist. exist.
F-bit: The forward unknown TLV bit MUST be 0 as required by F-bit: The forward unknown TLV bit MUST be 0 as required by
Section 3 of [RFC5561]. Section 3 of [RFC5561].
MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA) MRT Capability: TBD-MRT-LDP-1 (To Be Allocated by IANA)
Length: The length (in octets) of TLV. Its value is 1. Length: The length (in octets) of TLV. Its value is 1.
S-bit: The State bit MUST be 1 if used in LDP "Initialization" 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 message. MAY be set to 0 or 1 in dynamic "Capability" message to
advertise or withdraw the capability respectively, as described in advertise or withdraw the capability respectively, as described in
[RFC5561]. [RFC5561].
4.1.1. Interaction of MRT Capability and MT Capability 4.1.1. Interaction of MRT Capability and MT Capability
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 MT-ID (TBA-MRT-LDP-2) will be assigned The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be
by IANA from the LDP MT-ID space. Prototype experiments have used assigned by IANA from the MPLS MT-ID space. Prototype experiments
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.
[I-D.ietf-rtgwg-mrt-frr-architecture] contains the IANA request for [I-D.ietf-rtgwg-mrt-frr-architecture] defines the Default MRT
the MRT-Red and MRT-Blue MT-IDs associated with the Default MRT Profile. This document contains the IANA request for the MRT-Red and
Profile. MRT-Blue MPLS MT-IDs associated with the Default MRT Profile (TBD-
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 9, line 40 skipping to change at page 9, line 40
Island, but outside of the MRT Island. It also covers the scenario 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. of a prefix being advertised by 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. The resulting graph in the computation consists multi-homed prefix. [I-D.ietf-rtgwg-mrt-frr-algorithm] describes the
of the MRT Island with the proxy-node representing the multi-homed procedure for identifying one proxy-node attachment router as "red"
prefix directly attached to the two proxy-node attachment routers. and one as "blue" with respect to the multi-homed prefix, and
Conceptually, one then runs the MRT algorithm on this simplified computing the MRT red and blue next-hops to reach those red and blue
graph to determine the MRT-red and blue next-hops to reach the proxy- proxy-node attachment routers.
node, which gives the next-hops to reach the prefix. In this manner,
one can see that one of the two proxy-node attachment routers will
always have a MRT-red next-hop to the proxy-node while the other will
always have the MRT-blue next-hop to the proxy-node. We will refer
to these as the red and blue proxy-node attachment routers
respectively. (In practice, the MRT-red and blue next-hops to reach
the proxy-node can then be determined in a more computationally
efficient manner based on the MRT-red and blue next-hops to reach the
proxy-node attachment routers, as described in
[I-D.ietf-rtgwg-mrt-frr-algorithm].)
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 14, line 11 skipping to change at page 14, line 5
(before a failure occurs). Therefore, a malicious packet with an (before a failure occurs). Therefore, a malicious packet with an
appropriate label injected into the network from a compromised appropriate label injected into the network from a compromised
location would be forwarded to a destinations along a non-shortest location would be forwarded to a destinations along a non-shortest
path. When this technology is deployed, a network security design path. When this technology is deployed, a network security design
should not rely on assumptions about potentially malicious traffic should not rely on assumptions about potentially malicious traffic
only following shortest paths. only following 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.
7. IANA Considerations 7. Potential restrictions on MRT-related MT-ID values imposed by
RFC6420
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 [RFC6420] can be used to
establish MRT-based multicast distribution trees. [RFC6420] limits
the values of the PIM MT-ID from 1 through 4095.
For the purpose of reducing management overhead and simplifying
troubleshooting, it is desirable to be able to use the same numerical
value for the PIM MT-ID as for the MPLS MT-ID, for multicast and
unicast 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. [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)".
8. IANA Considerations
IANA is requested to allocate a value for the new LDP Capability TLV 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 LDP (the first free value in the range 0x0500 to 0x05FF) from the Label
registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1). Distribution Protocol (LDP) Parameters registry "TLV Type Name
Space": MRT Capability TLV (TBD-MRT-LDP-1).
Value Description Reference Notes / Reg. Date Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ ----------------- ------------- ------------------ ------------ -----------------
TBA-MRT-LDP-1 MRT Capability TLV [This draft] TBD-MRT-LDP-1 MRT Capability TLV [This draft]
IANA is requested to allocate a value for the new LDP Status Code IANA is requested to allocate a value for the new LDP Status Code
(the first free value in the range 0x00000032-0x00000036) from the (the first free value in the range 0x00000032-0x00000036) from the
LDP registry "Status Code Name Space": "MRT Capability negotiated Label Distribution Protocol (LDP) Parameters registry "Status Code
without MT Capability" (TBA-MRT-LDP-3). Name Space": "MRT Capability negotiated without MT Capability" (TBD-
MRT-LDP-2). The Status Code E-bit is set to 0.
Value E Description Reference Notes / Reg. Date Value E Description Reference Notes / Reg. Date
------------- - ------------------ ------------ ----------------- -------------- - ------------------ ------------ -----------------
TBA-MRT-LDP-3 0 MRT Capability [This draft] TBD-MRT-LDP-2 0 MRT Capability [This draft]
negotiated without negotiated without
MT Capability MT Capability
IANA is requested to allocate a value from the MPLS Multi-Topology IANA is requested to allocate three values from the MPLS Multi-
Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2). Topology Identifiers Registry [RFC7307].
Value Purpose Reference Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) with suggested value: 3945
------------- ------------------ ------------
TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft]
8. Acknowledgements Default Profile MRT-Red MPLS MT-ID (TBD-MRT-LDP-4) with suggested
value: 3946
Default Profile MRT-Blue MPLS MT-ID (TBD-MRT-LDP-5) with suggested
value: 3947
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.
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]
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.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-05 (work in progress), July 2015. algorithm-05 (work in progress), July 2015.
[I-D.ietf-rtgwg-mrt-frr-architecture] [I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/ A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft- LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-05 (work in progress), ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
January 2015. January 2015.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Specification", RFC 5036, October 2007. "LDP Specification", RFC 5036, DOI 10.17487/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, July 2009. Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009,
<http://www.rfc-editor.org/info/rfc5561>.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
<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, July King, "LDP Extensions for Multi-Topology", RFC 7307,
2014. DOI 10.17487/RFC7307, July 2014,
<http://www.rfc-editor.org/info/rfc7307>.
9.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., Zhao, Q., Atlas, A., Bowers, C., and J.
Tantsura, "Intermediate System to Intermediate System (IS- Tantsura, "Intermediate System to Intermediate System (IS-
skipping to change at page 16, line 6 skipping to change at page 17, line 17
"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-00 (work in progress), January 2015.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
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. 25 change blocks. 
56 lines changed or deleted 119 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/