< draft-ietf-mpls-mldp-node-protection-06.txt   draft-ietf-mpls-mldp-node-protection-07.txt >
Network Working Group IJ. Wijnands, Ed. Network Working Group IJ. Wijnands, Ed.
Internet-Draft K. Raza Internet-Draft K. Raza
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: March 18, 2016 A. Atlas Expires: March 19, 2016 A. Atlas
Juniper Networks, Inc. Juniper Networks, Inc.
J. Tantsura J. Tantsura
Ericsson Ericsson
Q. Zhao Q. Zhao
Huawei Technology Huawei Technology
September 15, 2015 September 16, 2015
mLDP Node Protection mLDP Node Protection
draft-ietf-mpls-mldp-node-protection-06 draft-ietf-mpls-mldp-node-protection-07
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) that have been built by the "Multipoint Label Distribution (MP LSPs) that have been built by the "Multipoint Label Distribution
Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point
of Local Repair (PLR) Label Switched Router (LSR) of N must learn the of Local Repair (PLR) Label Switched Router (LSR) of N must learn the
Merge Point (MPT) LSR(s) of node N such that traffic can be Merge Point (MPT) LSR(s) of node N such that traffic can be
redirected to them in case node N fails. Redirecting the traffic redirected to them in case node N fails. Redirecting the traffic
around the failed node N depends on existing P2P LSPs. The pre- around the failed node N depends on existing Point-to-Point (P2P)
established LSPs originate from the PLR LSR and terminate on the MPT Label Switched Paths (LSPs). The pre-established LSPs originate from
LSRs while bypassing LSR N. the PLR LSR and 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 March 18, 2016. This Internet-Draft will expire on March 19, 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 38 skipping to change at page 2, line 38
4.1.1. Node failure . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Node failure . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Link failure . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Link failure . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Switching to new primary path . . . . . . . . . . . . 12 4.1.3. Switching to new primary path . . . . . . . . . . . . 12
5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 12 5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 12
5.1. PLR capability . . . . . . . . . . . . . . . . . . . . . . 13 5.1. PLR capability . . . . . . . . . . . . . . . . . . . . . . 13
5.2. MPT capability . . . . . . . . . . . . . . . . . . . . . . 13 5.2. MPT capability . . . . . . . . . . . . . . . . . . . . . . 13
5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 13 5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 13
5.4. The Node Protection Capability . . . . . . . . . . . . . . 14 5.4. The Node Protection Capability . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16 9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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) that have been built by the "Multipoint Label Distribution (MP LSPs) that have been built by the "Multipoint Label Distribution
Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point Protocol"(mLDP) [RFC6388]. In order to protect a node N, the Point
of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) of Local Repair (PLR) LSR of N must learn the Merge Point (MPT)
LSR(s) of node N such that traffic can be redirected to them in case LSR(s) of node N such that traffic can be redirected to them in case
skipping to change at page 3, line 30 skipping to change at page 3, line 30
to accomplish this. to accomplish this.
The solution described in this document notifies the PLR(s) of the The solution described in this document notifies the PLR(s) of the
MPT LST(s) via signalling using a Targeted LDP (tLDP) session MPT LST(s) via signalling using a Targeted LDP (tLDP) session
[RFC7060]. By having a tLDP session with the PLR, no additional [RFC7060]. By having a tLDP session with the PLR, no additional
procedures need to be defined in order to support Make-Before-Break procedures need to be defined in order to support Make-Before-Break
(MBB), Graceful Restart (GR) and Typed Wildcard FEC support. All (MBB), Graceful Restart (GR) and Typed Wildcard FEC support. All
this is achieved at the expense of having additional tLDP sessions this is achieved at the expense of having additional tLDP sessions
between each MPT and PLR LSR. between each MPT and PLR LSR.
In order for a node to be protected, the protecterd node, the PLR and In order to allow a node to be protected against failure, the LSRs
the MPT MUST support the procedures as described in this draft. providing the PLR and the MPT functionality as well as the protected
Detecting the protected node, PLR and MPT support these procedures is node MUST support the functionality described in this document. LDP
done using [RFC5561]. capability negotiation [RFC5561] is used to signal the availability
of the functionality between the participating nodes; these nodes
MUST support capability negotiation.
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 4, line 31 skipping to change at page 4, line 35
the PLR to the MPT. The PLR address for a MP LSP on node N is the the PLR to the MPT. The PLR address for a MP LSP on node N is the
address of the upstream LDP peer, but only when node N is NOT the address of the upstream LDP peer, but only when node N is NOT the
root node of the MP2MP LSP. If the upstream LDP peer is unable to 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 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 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 the enabled (e.g., by a user configuration) to support and implement the
PLR determination feature. PLR determination feature.
The procedures as documented in this draft requires the protected The procedures as documented in this document requires the protected
node to be directly connected to the PLR and MPT nodes. This because node to be directly connected to the PLR and MPT nodes. This is
mLDP depends on unicast routing to determine the upstream LSR and because mLDP depends on unicast routing to determine the upstream LSR
unicast routing (by default) only has information about the next-hop and unicast routing (by default) only has information about the next-
and not beyond that. Support for non-directly connected PLR and MPT hop and not beyond that. Support for non-directly connected PLR and
nodes is outside the scope of this document. MPT nodes is outside the scope of this document.
2.1. Transit node procedure 2.1. Transit node procedure
Find below the procedures for when the protected node is a transit Find below the procedures for when the protected node is a transit
node along the path to the root. node along the path to the root.
root root
^ ^
| |
(LSR1) (LSR1)
skipping to change at page 5, line 26 skipping to change at page 5, line 26
Figure 1. Figure 1.
N: The node being protected, N: The node being protected,
...: Backup LSPs from LSR1 to LSR2 and LSR3. ...: Backup LSPs from LSR1 to LSR2 and LSR3.
Node N uses the root address of the MP LSP to determine the upstream Node N uses the root address of the MP LSP to determine the upstream
LSR for a given MP LSP following the procedures as documented in LSR for a given MP LSP following the procedures as documented in
[RFC6388] section 2.4.1.1. The upstream LSR in figure 1 is LSR1 [RFC6388] section 2.4.1.1. The upstream LSR in figure 1 is LSR1
because it is the first hop along the shortest path to reach the root because it is the first hop along the shortest path to reach the root
address. After determining the upstream LSR, node N (which has the address. After determining the upstream LSR, node N (which has the
node protection feature enabled), MUST advertise the address of LSR1 node protection feature enabled) MUST advertise the address of LSR1
as the PLR address to the downstream members of the MP LSP (i.e., as the PLR address to the downstream members of the MP LSP (i.e.,
LSR2 and LSR3) if the given downstream member has announced support LSR2 and LSR3) if the given downstream member has announced support
for node protection (see Section 5) during Capability negotiation). for node protection (see Section 5 during Capability negotiation).
For the format and encoding of PLR address information, see For the format and encoding of PLR address information, see
Section 2.3. Section 2.3.
Note, in order for the protected traffic to reach nodes LSR2 and Note, in order for the protected traffic to reach nodes LSR2 and
LSR3, LSR1 MUST have two unidirectinal LSPs to LSR2 and LSR3, LSR3, LSR1 MUST have two unidirectinal LSPs to LSR2 and LSR3,
bypassing node N. Procedures how to setup these LSPs are outside the bypassing node N. The procedures for setting up these LSPs are
scope of this documemnt. outside the scope of this documemnt.
2.2. MP2MP root node procedure 2.2. MP2MP root node procedure
Find below the procedures for when the protected node is the root of Find below the procedures for when the protected node is the root of
a MP2MP LSP. Consider figure 2 below; a MP2MP LSP. Consider figure 2 below;
| |
(LSR1) (LSR1)
. | . . | .
. | . . | .
. (N) . root . (N) . root
skipping to change at page 6, line 35 skipping to change at page 6, line 35
other LSR(s). Since node N knows the members of the MP2MP LSP, it other LSR(s). Since node N knows the members of the MP2MP LSP, it
will advertise the member list to its directly connected members, will advertise the member list to its directly connected members,
excluding the member it is sending to. For example, node N will excluding the member it is sending to. For example, node N will
advertise {LSR3,LSR1} list to LSR2 excluding LSR2 from it. Instead advertise {LSR3,LSR1} list to LSR2 excluding LSR2 from it. Instead
of advertising a single PLR when node N is not the root, a list of of advertising a single PLR when node N is not the root, a list of
PLRs is advertised using the procedures documented in Section 2.3. PLRs is advertised using the procedures documented in Section 2.3.
It should be noted that the MP2MP root node protection mechanism It should be noted that the MP2MP root node protection mechanism
doesn't replace the Root Node Redundancy (RNR) procedures as doesn't replace the Root Node Redundancy (RNR) procedures as
described in [RFC6388] section 7. The node protection procedures in described in [RFC6388] section 7. The node protection procedures in
this draft will help in restoring traffic for the existing MP2MP LSPs this document will help in restoring traffic for the existing MP2MP
after node failure, but a new root node has to be elected eventually LSPs after node failure, but a new root node has to be elected
in order to allow new MP2MP LSPs to be created. eventually in order to allow new MP2MP LSPs to be created.
Note, in order for the protected traffic to be exchanged between Note, in order for the protected traffic to be exchanged between
nodes LSR1, LSR2 and LSR3, bidirectional LSPs have to exist between nodes LSR1, LSR2 and LSR3, bidirectional LSPs have to exist between
the LSRs, bypassing node N. Procedures how to setup these LSPs are the LSRs, bypassing node N. The procedures for setting up these LSPs
outside the scope of this documemnt. are outside the scope of this documemnt.
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 an MP Status TLV, where the MP status TLV contains a new "PLR with an MP Status TLV, where the MP status TLV contains a new "PLR
Status Value 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:
skipping to change at page 7, line 31 skipping to change at page 7, line 31
Length: The Length field is an unsigned integer that encodes the Length: The Length field is an unsigned integer that encodes the
length of the Status Value following the Length field. The length of the Status Value following the Length field. The
encoded Length varies based on the Addr Family and the number of encoded Length varies based on the Addr Family and the number of
PLR entries. PLR entries.
Addr Family: Two octet quantity containing a value from IANA's Addr Family: Two octet quantity containing a value from IANA's
[AFI] registry that encodes the address family for the PLR Address [AFI] registry that encodes the address family for the PLR Address
encoded in the PLR entry. encoded in the PLR entry.
Num PLR entry: Element as an unsigned, non-zero integer followed Num PLR entry: Element as an unsigned, integer followed by that
by that number of "PLR entry" fields in the format specified number of "PLR entry" fields in the format specified below.
below.
The format of a "PLR Entry" is as follows: The format of a "PLR Entry" is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | PLR address | |A| Reserved | PLR address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR address (cont) ~ ~ PLR address (cont) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 16 skipping to change at page 8, line 16
PLR address field is specific to the Address Family that is PLR address field is specific to the Address Family that is
encoded. 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 dependent on the address length. The length of the PLR address is dependent 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). Node N can advertise
advertise or withdraw a given PLR from its PLR set by setting the "A or withdraw a given PLR from its PLR set by setting the "A bit" to 1
bit" to 1 or 0 respectively in the corresponding PLR entry. Removing or 0 respectively in the corresponding PLR entry. Removing a PLR
a PLR address is likely due to a link failure, see the procedures as address is likely due to a link failure; see the procedures as
documented in Section 4.1. To remove all PLR addresses belonging to documented in Section 4.1. To remove all PLR addresses belonging to
the encoded Address Family, an LSR N MUST encode PLR Status Value the encoded Address Family, an LSR N MUST encode PLR Status Value
Element with no PLR entry and "Num PLR entry" field MUST be set to Element with no PLR entry and "Num PLR entry" field MUST be set to
zero. zero.
Along with the PLR Status a MP FEC TLV [RFC5036] MUST be included in Along with the PLR Status a MP FEC TLV [RFC5036] MUST be included in
the LDP Notification message so that a receiver is able to associate the LDP Notification message so that a receiver is able to associate
the PLR Status with the MP LSP. the PLR Status with the MP LSP.
3. Using the tLDP session 3. Using the tLDP session
skipping to change at page 8, line 45 skipping to change at page 8, line 45
[RFC7060]. [RFC7060].
Using Figure 1 as the reference topology, let us assume that both Using Figure 1 as the reference topology, let us assume that both
LSR2 and LSR3 are MPTs and have established a tLDP session with the LSR2 and LSR3 are MPTs and have established a tLDP session with the
PLR being LSR1. Assume that both LSR2 and LSR3 have a FEC <R,X> with PLR being LSR1. Assume that both LSR2 and LSR3 have a FEC <R,X> with
a upstream LSR N and label Ln assigned to FEC towards N. The MPTs a upstream LSR N and label Ln assigned to FEC towards N. The MPTs
will create a secondary upstream LSR (using the received PLR address) will create a secondary upstream LSR (using the received PLR address)
and assigned a Label Lpx to FEC <R,X> towards PLR for it. The MPTs and assigned a Label Lpx to FEC <R,X> towards PLR for it. The MPTs
will do that for each PLR address that was learned for the MP LSP. will do that for each PLR address that was learned for the MP LSP.
In this example, the MPTs will have a FEC <R,X> with two local labels In this example, the MPTs will have a FEC <R,X> with two local labels
associated with it. Ln that was assigned to N via the normal mLDP associated with it. Label Ln that was assigned to N using the the
procedures, and Label Lpx that was assigned for PLR (LSR1) for the normal mLDP procedures, and Label Lpx that was assigned to PLR (LSR1)
purpose of node protecting MP LSP via node N. Note, when the for the purpose of node protection. Note, when the protected node is
protected node is a MP2MP root node, there will be an upstream LSR a MP2MP root node, there will be an upstream LSR for each PLR address
for each PLR address that was advertised along with a unique Label that was advertised along with a unique Label Lpx.
Lpx.
The receipt of a FEC Label Mapping alone over the tLDP session from The receipt of a FEC Label Mapping alone over the tLDP session from
MPT on a PLR conveys the label information but does not convey the MPT on a PLR conveys the label information but does not convey the
node being protected. The information about a protected node is node being protected. The information about a protected node is
known to the MPT LSR and needs to be communicated to the PLR as well. known to the MPT LSR and needs to be communicated to the PLR as well.
For this reason, the FEC Label Mapping (FEC <R,X> : Lpx) sent by the For this reason, the FEC Label Mapping (FEC <R,X> : Lpx) sent by the
MPT over the tLDP session to the PLR MUST include a Status TLV with MPT over the tLDP session to the PLR MUST include a Status TLV with
MP Status including a new LDP MP status Value Element called the MP Status and a new LDP MP status Value Element called the "Protected
"Protected Node Status Value Element". This new value element is Node Status Value Element". This new value element is used to
used to specify the address of the node being protected. The specify the address of the node being protected. The "Protected Node
"Protected Node Status Value Element" has the following format; 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Protected Node Status Value Element (Type TBA-2 to be Type : Protected Node Status Value Element (Type TBA-2 to be
skipping to change at page 9, line 49 skipping to change at page 9, line 49
When a PLR receives a Label Mapping for FEC <R,X> that includes a When a PLR receives a Label Mapping for FEC <R,X> that includes a
Protected Node Status, it will only use that label binding once the Protected Node Status, it will only use that label binding once the
Node advertised in the Status value becomes unreachable. If the LSP Node advertised in the Status value becomes unreachable. If the LSP
is a MP2MP LSP, the PLR would have assigned a Label Mapping for the is a MP2MP LSP, the PLR would have assigned a Label Mapping for the
upstream MP2MP FEC Element to the MPT ([RFC6388] section 3) for FEC upstream MP2MP FEC Element to the MPT ([RFC6388] section 3) for FEC
<R,X>. This label binding on the MPT MUST only be used once node N <R,X>. This label binding on the MPT MUST only be used once node N
becomes unreachable. becomes unreachable.
The procedures to determine if a node is unreachable is a local The procedures to determine if a node is unreachable is a local
decision and not spelled out in this draft. Typically link failure decision and not spelled out in this document. Typically link
or Bidirectional Forwarding Detection (BFD) can be used to determine failure or Bidirectional Forwarding Detection (BFD) can be used to
and detect node unreachability. determine and detect node unreachability.
4. Link or node failure 4. Link or node failure
Consider the following topology; Consider the following topology;
root root
^ ^
| |
. (LSR1) . (LSR1)
. / | . . / | .
skipping to change at page 10, line 48 skipping to change at page 10, line 48
duplicate packets being forwarded to the receivers on the tree, LSR2 duplicate packets being forwarded to the receivers on the tree, LSR2
and LSR3 need to determine from which upstream node they should and LSR3 need to determine from which upstream node they should
accept the packets. This can be either from the primary upstream LSR accept the packets. This can be either from the primary upstream LSR
N or from the secondary upstream LSR1, but never both at the same N or from the secondary upstream LSR1, but never both at the same
time. The selection between the primary upstream LSR or (one or time. The selection between the primary upstream LSR or (one or
more) secondary upstream LSRs (on LSR2 and LSR3) is based on the more) secondary upstream LSRs (on LSR2 and LSR3) is based on the
reachability of the protected node N. As long as N is reachable from reachability of the protected node N. As long as N is reachable from
an MPT, the MPT should accept and forward the MPLS packets from N. an MPT, the MPT should accept and forward the MPLS packets from N.
Once N becomes unreachable, the LSPs from secondary upstream PLR LSRs Once N becomes unreachable, the LSPs from secondary upstream PLR LSRs
(LSR1 in our example) are activated. Note that detecting if N is (LSR1 in our example) are activated. Note that detecting if N is
unreachable is a local decision and not spelled out in this draft. unreachable is a local decision and not spelled out in this document.
Typically link failure or Bidirectional Forwarding Detection (BFD) Typically link failure or Bidirectional Forwarding Detection (BFD)
can be used to determine and detect node unreachability. can be used to determine and detect node unreachability.
4.1. Re-convergence after node/link failure 4.1. Re-convergence after node/link failure
Consider the following topology; Consider the following topology;
root root
^ ^
skipping to change at page 15, line 16 skipping to change at page 15, line 16
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 procedures in this document add two new TLVs to existing LDP
specification, as described in [RFC6388] and [RFC5920]. messages. Those TLVs can be protected by the mechanisms that are
used to protect LDP messages as described in [RFC6388] and [RFC5920].
If it were possible to attack the mechanisms described in this
document an LSR (a PLR or a MPT) could be induced to support a large
number of tLDP sessions and set up an even larger number of LSPs.
The security mechanisms in [RFC6388] and [RFC5920] are believed to be
adequate, but an implementation could provide additional protection
by counting such protection sessions and LSPs and producing a log
message to the operator if a threshold is crossed.
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 15, line 44 skipping to change at page 16, line 8
Parameters. The lowest available new code point after 0x0970 should Parameters. The lowest available new code point after 0x0970 should
be used. be used.
Value | Description | Reference | Notes/Reg Date Value | Description | Reference | Notes/Reg Date
------+-------------------------------+-----------+--------------- ------+-------------------------------+-----------+---------------
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, Loa Andersson for their comments and Elwyn Vigoureux, Kenji Fujihira, Loa Andersson for their comments on this
Davies for his great review of this document. document. Also, many thanks to Elwyn Davies and Adrian Farrel for
the detailed review and contribution to this document.
9. Contributor Addresses 9. Contributor Addresses
Below is a list of other contributing authors in alphabetical order: Below is a list of other contributing authors in alphabetical order:
Eric Rosen Eric Rosen
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford Westford
MA 01886 MA 01886
USA USA
erosen@juniper.net erosen@juniper.net
10. References 10. References
10.1. Normative References 10.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.
 End of changes. 23 change blocks. 
60 lines changed or deleted 69 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/