< draft-ietf-mpls-mldp-node-protection-02.txt   draft-ietf-mpls-mldp-node-protection-03.txt >
Network Working Group IJ. Wijnands, Ed. Network Working Group IJ. Wijnands, Ed.
Internet-Draft E. Rosen Internet-Draft E. Rosen
Intended status: Standards Track K. Raza Intended status: Standards Track K. Raza
Expires: May 17, 2015 Cisco Systems, Inc. Expires: August 7, 2015 Cisco Systems, Inc.
J. Tantsura J. Tantsura
Ericsson Ericsson
A. Atlas A. Atlas
Juniper Networks Juniper Networks
Q. Zhao Q. Zhao
Huawei Technology Huawei Technology
November 13, 2014 February 3, 2015
mLDP Node Protection mLDP Node Protection
draft-ietf-mpls-mldp-node-protection-02 draft-ietf-mpls-mldp-node-protection-03
Abstract Abstract
This document describes procedures to support node protection for This document describes procedures to support node protection for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
(MP LSPs) built by LDP ("Label Distribution Protocol"), or simply (MP LSPs) that has been built by "Multipoint Label Distribution
mLDP. In order to protect a node N, the Point of Local Repair (PLR) Protocol"(mLDP). In order to protect a node N, the Point of Local
LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node
traffic can be redirected to them in case node N fails. Redirecting N such that traffic can be redirected to them in case node N fails.
the traffic around the failed node N depends on existing P2P LSPs Redirecting the traffic around the failed node N depends on existing
originated from the PLR LSR to the MPT LSRs while bypassing LSR node P2P LSPs. The pre-established LSPs originate from the PLR LSR and
N. terminate on the MPT LSRs while bypassing LSR N.
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 May 17, 2015. This Internet-Draft will expire on August 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. PLR Determination . . . . . . . . . . . . . . . . . . . . . . 4 2. PLR Determination . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transit node procedure . . . . . . . . . . . . . . . . . . 4 2.1. Transit node procedure . . . . . . . . . . . . . . . . . . 4
2.2. MP2MP root node procedure . . . . . . . . . . . . . . . . 5 2.2. MP2MP root node procedure . . . . . . . . . . . . . . . . 5
2.3. PLR information encoding . . . . . . . . . . . . . . . . . 5 2.3. PLR information encoding . . . . . . . . . . . . . . . . . 5
3. Using the tLDP session . . . . . . . . . . . . . . . . . . . . 7 3. Using the tLDP session . . . . . . . . . . . . . . . . . . . . 7
4. Link or node failure . . . . . . . . . . . . . . . . . . . . . 9 4. Link or node failure . . . . . . . . . . . . . . . . . . . . . 9
4.1. Re-convergence after node/link failure . . . . . . . . . . 10 4.1. Re-convergence after node/link failure . . . . . . . . . . 10
4.1.1. Node failure . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Node failure . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Link failure . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Link failure . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Switching to new primary path . . . . . . . . . . . . 11 4.1.3. Switching to new primary path . . . . . . . . . . . . 11
5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 11 5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 11
5.1. PLR capability . . . . . . . . . . . . . . . . . . . . . . 12 5.1. PLR capability . . . . . . . . . . . . . . . . . . . . . . 12
5.2. MPT capability . . . . . . . . . . . . . . . . . . . . . . 12 5.2. MPT capability . . . . . . . . . . . . . . . . . . . . . . 12
5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 12 5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 12
5.4. The Node Protection Capability . . . . . . . . . . . . . . 13 5.4. The Node Protection Capability . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes procedures to support node protection for This document describes procedures to support node protection for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
(MP-LSPs) built by LDP ("Label Distribution Protocol"), or simply (MP LSPs) that has been built by "Multipoint Label Distribution
mLDP. In order to protect a node N, the Point of Local Repair (PLR) Protocol"(mLDP). In order to protect a node N, the Point of Local
of N must learn the Merge Point (MPT) LSR(s) of node N such that Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node
traffic can be redirected to them in case node N fails. Redirecting N such that traffic can be redirected to them in case node N fails.
the traffic around the failed node N depends on existing P2P LSPs Redirecting the traffic around the failed node N depends on existing
originating from the PLR LSR to the MPT LSR(s) while bypassing node P2P LSPs. The pre-established LSPs originate from the PLR LSR and
N. The procedures to setup these P2P LSPs are outside the scope of terminate on the MPT LSRs while bypassing LSR N. The procedures to
this document, but one can imagine using RSVP-TE or LDP LFA based setup these P2P LSPs are outside the scope of this document, but one
techniques to accomplish this. can imagine using RSVP-TE or LDP LFA based techniques to accomplish
this.
The solution described in this document signals the MPT LSR(s) to the The solution described in this document notifies the PLR(s) of the
PLR LSR(s) via a Targeted LDP (tLDP) session [RFC5036]. By having a MPT LST(s) via signalling using a Targetted LDP (tLDP) session
tLDP session with the PLR, most of the (m)LDP features currently [RFC5036]. By having a tLDP session with the PLR, most of the (m)LDP
defined should just work, like Make-Before-Break (MBB), Graceful features currently defined should just work, like Make-Before-Break
Restart (GR), Typed Wildcard FEC support, etc. All this is achieved (MBB), Graceful Restart (GR), Typed Wildcard FEC support, etc. All
at the expense of having an additional tLDP session between an MPT this is achieved at the expense of having additional tLDP sessions
and PLR LSR. between each MPT and PLR LSR.
1.1. Conventions used in this document 1.1. Conventions used in this document
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms "node" is used to refer to an LSR and used interchangeably. The terms "node" is used to refer to an LSR and used interchangeably.
The terms "PLR" and "MPT" are used as shorthand to refer to "PLR LSR" The terms "PLR" and "MPT" are used as shorthand to refer to "PLR LSR"
and "MPT LSR" respectively. and "MPT LSR" respectively.
skipping to change at page 3, line 48 skipping to change at page 3, line 49
mLDP: Multipoint extensions to LDP. mLDP: Multipoint extensions to LDP.
PLR: Point of Local Repair (the LSR that redirects the traffic to PLR: Point of Local Repair (the LSR that redirects the traffic to
one or more Merge Point LSRs). one or more Merge Point LSRs).
MPT: Merge Point (the LSR that merges the backup LSP with primary MPT: Merge Point (the LSR that merges the backup LSP with primary
LSP. Note, there can be multiple MPT LSRs for a single MP-LSP LSP. Note, there can be multiple MPT LSRs for a single MP-LSP
node protection). node protection).
tLDP: Targeted LDP session. tLDP: Targeted LDP.
MP LSP: Multi-Point LSP (either a P2MP or MP2MP LSP). MP LSP: Multi-Point LSP (either a P2MP or MP2MP LSP).
2. PLR Determination 2. PLR Determination
In order for a MPT to establish a tLDP session with the PLR, it first In order for a MPT to establish a tLDP session with a PLR, it first
has to learn the PLR for a particular MP LSP. It is the has to learn the PLR for a particular MP LSP. It is the
responsibility of the protected node N to advertise the PLR address responsibility of the protected node N to advertise the address of
to the MPT. The PLR address for a MP LSP on node N is the address of the PLR to the MPT. The PLR address for a MP LSP on node N is the
the upstream LDP peer, but only when node N is NOT the root node of address of the upstream LDP peer, but only when node N is NOT the
the MP2MP LSP. If node N is the root node, the procedures are root node of the MP2MP LSP. If the upstream LDP peer is unable to
function as PLR, the procedures in this document do not apply and are
out of the scope. If node N is the root node, the procedures are
slightly different as described in Section 2.2. The procedures that slightly different as described in Section 2.2. The procedures that
follow assume that all the participating nodes (N, PLRs, MPTs) are follow assume that all the participating nodes (N, PLRs, MPTs) are
enabled (e.g. by a user configuration) to support and implement this enabled (e.g. by a user configuration) to support and implement the
feature. PLR determination feature.
2.1. Transit node procedure 2.1. Transit node procedure
Below we are describing the procedures when the protected node is a Below we are describing the procedures when the protected node is a
transit node along the path to the root. transit node along the path to the root.
root root
^ ^
| |
(LSR1) (LSR1)
skipping to change at page 5, line 48 skipping to change at page 5, line 50
It should be noted that the MP2MP root node protection mechanism It should be noted that the MP2MP root node protection mechanism
don't replace the Root Node Redundancy (RNR) procedures as described don't replace the Root Node Redundancy (RNR) procedures as described
in [RFC6388] section 7. The node protection procedures in this draft in [RFC6388] section 7. The node protection procedures in this draft
will help restoring traffic for the existing MP2MP LSPs after node will help restoring traffic for the existing MP2MP LSPs after node
failure, but a new root node has to be elected eventually in order to failure, but a new root node has to be elected eventually in order to
allow new MP2MP LSPs to be created. allow new MP2MP LSPs to be created.
2.3. PLR information encoding 2.3. PLR information encoding
The upstream LSR address is conveyed via an LDP Notification message The upstream LSR address is conveyed via an LDP Notification message
with MP Status, where the MP status contains a new "PLR Status Value with MP Status TLV, where the MP status TLV contains a new "PLR
Element" that specifies the address of the PLR. Status Value Element" that specifies the address of the PLR.
The new "PLR Status Value Element" is encoded as follows; The new "PLR Status Value Element" is encoded as follows;
PLR Status Element: PLR Status Element:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA-1 | Length | Addr Family | | Type = TBA-1 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Num PLR entry | | | Addr Fam cont | Num PLR entry | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
| PLR entry (0 or more) ~ | PLR entry (1 or more) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Where
Type: PLR Status Value Element (Type TBA-1 to be assigned by IANA) Type: PLR Status Value Element (Type TBA-1 to be assigned by IANA)
Length: The Length field encodes the length of the Status Value Length: The Length field encodes the length of the Status Value
following the Length field. The encoded Length varies based on following the Length field. The encoded Length varies based on
the Address Family and the number of PLR entries. the Address Family and the number of PLR entries.
skipping to change at page 7, line 4 skipping to change at page 7, line 6
|A| Reserved | PLR address | |A| Reserved | PLR address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR address (cont) ~ ~ PLR address (cont) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Where
A bit: 0 = Withdraw, 1 = Add. A bit: 0 = Withdraw, 1 = Add.
Reserved: 15 bits, must be zero on transmit and ignored on receipt Reserved: 15 bits, must be zero on transmit and ignored on receipt
PLR address: PLR Address encoded according to Address Family field PLR address: PLR Address encoded according to Address Family field
encoded in the PLR Status Value Element. encoded in the PLR Status Value Element. Note, the length of the
PLR address field is specific to the Address Family that is
encoded.
The size of a "PLR Entry" is the 2 octets ("A bit + Reserved") + PLR The size of a "PLR Entry" is the 2 octets ("A bit + Reserved") + PLR
address length. The length of the PLR address is depending on the address length. The length of the PLR address is depending on the
Address Family as encoded in the PLR Status Value Element. The size Address Family as encoded in the PLR Status Value Element. The size
of a "PLR entry" is 6 octets and 18 octets respectively for an IPv4 of a "PLR entry" is 6 octets and 18 octets respectively for an IPv4
PLR address and an IPv6 PLR address. PLR address and an IPv6 PLR address.
If the PLR address on N changes for a given MP LSP, N needs to If the PLR address on N changes for a given MP LSP, N needs to
trigger a new PLR Status to update the MPT(s). A node N can trigger a new PLR Status to update the MPT(s). A node N can
advertise or withdraw a given PLR from its PLR set by setting "A bit" advertise or withdraw a given PLR from its PLR set by setting "A bit"
skipping to change at page 8, line 19 skipping to change at page 8, line 23
MP Status including a new LDP MP status Value Element called the MP Status including a new LDP MP status Value Element called the
"Protected Node Status Value Element". This new value element is "Protected Node Status Value Element". This new value element is
used to specify the address of the node being protected. The used to specify the address of the node being protected. The
"Protected Node Status Value Element" has the following format; "Protected Node Status Value Element" has the following format;
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA-2 | Length | Addr Family | | Type = TBA-2 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Node address | | Addr Fam cont | Node address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Protected Node Status Value Element (Type TBA-2 to be Type : Protected Node Status Value Element (Type TBA-2 to be
assigned by IANA) assigned by IANA)
Length: The Length field encodes the length of the Status Value Length: The Length field encodes the length of the Status Value
following the Length field. The encoded Length varies based on following the Length field. The encoded Length varies based on
the Address Family and is 6 octets (for Address Family + IPv4 the Address Family and is 6 octets (for Address Family + IPv4
address and 18 octets for Address Family + IPv6 address. address and 18 octets for Address Family + IPv6 address.
skipping to change at page 14, line 12 skipping to change at page 14, line 15
An LSR that supports the PLR functionality LSR MAY send this An LSR that supports the PLR functionality LSR MAY send this
capability to its downstream MP peers with "P" bit set; whereas, an capability to its downstream MP peers with "P" bit set; whereas, an
LSR that supports an the MPT functionality MAY send this capability LSR that supports an the MPT functionality MAY send this capability
to its upstream peer with "M" bit set. Moreover, an LSR that to its upstream peer with "M" bit set. Moreover, an LSR that
supports both the PLR and MPT functionality MAY sent this capability supports both the PLR and MPT functionality MAY sent this capability
to its peers with both "P" and "M" bit set. to its peers with both "P" and "M" bit set.
6. Security Considerations 6. Security Considerations
The same security considerations apply as those for the base mLDP The same security considerations apply as those for the base mLDP
specification, as described in [RFC6388]. specification, as described in [RFC6388] and [RFC5920].
7. IANA considerations 7. IANA considerations
IANA is requested to allocate two new code points from the "LDP MP IANA is requested to allocate two new code points from the "LDP MP
Status Value Element type" registry within the Label Distribution Status Value Element type" registry within the Label Distribution
Protocol (LDP) Parameters; Protocol (LDP) Parameters;
Value | Name | Reference Value | Name | Reference
------+----------------------------------------+----------- ------+----------------------------------------+-----------
TBA-1 | PLR Status Value Element | this doc TBA-1 | PLR Status Value Element | this doc
skipping to change at page 14, line 43 skipping to change at page 15, line 4
------+-------------------------------+-----------+--------------- ------+-------------------------------+-----------+---------------
TBA-3 | MP Node Protection Capability | This doc | TBA-3 | MP Node Protection Capability | This doc |
8. Acknowledgments 8. Acknowledgments
The authors like to thank Nagendra Kumar, Duan Hong, Martin The authors like to thank Nagendra Kumar, Duan Hong, Martin
Vigoureux, Kenji Fujihira and Loa Andersson for their comments on Vigoureux, Kenji Fujihira and Loa Andersson for their comments on
this draft. this draft.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
[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, July 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[I-D.ietf-mpls-targeted-mldp] [I-D.ietf-mpls-targeted-mldp]
Napierala, M. and E. Rosen, "Using LDP Multipoint Napierala, M. and E. Rosen, "Using LDP Multipoint
Extensions on Targeted LDP Sessions", Extensions on Targeted LDP Sessions",
draft-ietf-mpls-targeted-mldp-01 (work in progress), draft-ietf-mpls-targeted-mldp-01 (work in progress),
January 2013. January 2013.
9.2. Informative References 9.2. Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
 End of changes. 23 change blocks. 
48 lines changed or deleted 55 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/