< draft-chandra-mpls-rsvp-shared-labels-np-01.txt   draft-chandra-mpls-rsvp-shared-labels-np-02.txt >
MPLS Working Group C. Ramachandran MPLS Working Group C. Ramachandran
Internet-Draft V. Beeram Internet-Draft V. Beeram
Intended status: Standards Track H. Sitaraman Intended status: Standards Track Juniper Networks
Expires: July 7, 2019 Juniper Networks Expires: January 9, 2020 H. Sitaraman
January 3, 2019 Individual
July 8, 2019
Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane
draft-chandra-mpls-rsvp-shared-labels-np-01 draft-chandra-mpls-rsvp-shared-labels-np-02
Abstract Abstract
Segment Routed RSVP-TE tunnels provide the ability to use a shared Segment Routed RSVP-TE tunnels provide the ability to use a shared
MPLS forwarding plane at every hop of the Label Switched Path (LSP). MPLS forwarding plane at every hop of the Label Switched Path (LSP).
The shared forwarding plane is realized with the use of 'Traffic The shared forwarding plane is realized with the use of 'Traffic
Engineering (TE) link labels' that get shared by LSPs traversing Engineering (TE) link labels' that get shared by LSPs traversing
these TE links. This paradigm helps significantly reduce the these TE links. This paradigm helps significantly reduce the
forwarding plane state required to support a large number of LSPs on forwarding plane state required to support a large number of LSPs on
a Label Switching Router (LSR). Segment Routed RSVP-TE tunnels a Label Switching Router (LSR). These tunnels require the ingress
require the ingress Label Edge Router (LER) to impose a stack of Label Edge Router (LER) to impose a stack of labels. If the ingress
labels. If the ingress LER cannot impose the full label stack, it LER cannot impose the full label stack, it can use the assistance of
can use the assistance of one or more delegation hops along the path one or more delegation hops along the path of the LSP to impose parts
of the LSP to impose parts of the label stack. of the label stack.
The procedures for a Point of Local Repair (PLR) to provide local The procedures for a Point of Local Repair (PLR) to provide local
protection against link failures using facility backup for Segment protection against link failures using facility backup for Segment
Routed RSVP-TE tunnels are well defined and do not require specific Routed RSVP-TE tunnels are well defined and do not require specific
protocol extensions. This document defines the procedures for a PLR protocol extensions. This document defines the procedures for a PLR
to provide local protection against transit node failures using to provide local protection against transit node failures using
facility backup for these tunnels. The procedures defined in this facility backup for these tunnels. The procedures defined in this
document include protection against delegation hop failures. document include protection against delegation hop failures.
Requirements Language Requirements Language
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 July 7, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Node protection specific procedures . . . . . . . . . . . . . 4 3. Node Protection Specific Procedures . . . . . . . . . . . . . 4
3.1. Applicability of this document . . . . . . . . . . . . . 4 3.1. Applicability of this Document . . . . . . . . . . . . . 4
3.2. PLR procedures for protecting non-delegation next-hop LSR 4 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR 4
3.3. PLR procedures for protecting a delegation next-hop LSR . 6 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR . . 5
3.3.1. Label Allocation and Stacking . . . . . . . . . . . . 7 3.3.1. Label Allocation and Stacking . . . . . . . . . . . . 7
3.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 8 3.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 7
3.4.1. LSR does not support node protection for Shared 3.4.1. LSR does not Support Node Protection for Shared
Labels . . . . . . . . . . . . . . . . . . . . . . . 8 Labels . . . . . . . . . . . . . . . . . . . . . . . 7
3.4.2. PLR procedures for protecting a hop not supporting 3.4.2. Protected Hop does not Support Shared Labels . . . . 9
shared Labels . . . . . . . . . . . . . . . . . . . . 9 3.4.3. PLR does not Support Shared Labels . . . . . . . . . 9
3.4.3. PLR not supporting shared Labels . . . . . . . . . . 10 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 10 4.1. DHLD Encoding in ETLD Attributes TLV . . . . . . . . . . 9
4.1. DHLD encoding in ETLD Attributes TLV . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
With the advent of Traffic Engineering (TE) link labels and Segment With the advent of Traffic Engineering (TE) link labels and Segment
Routed RSVP-TE Tunnels [I-D.ietf-mpls-rsvp-shared-labels], Routed RSVP-TE Tunnels [RFC8577], a shared MPLS forwarding plane can
[I-D.ietf-mpls-rsvp-shared-labels], a shared MPLS forwarding plane be realized by allowing the TE link label to be shared by MPLS RSVP-
can be realized by allowing the TE link label to be shared by MPLS TE Label Switched Paths (LSPs) traversing the link. The shared
RSVP-TE Label Switched Paths (LSPs) traversing the link. The shared
forwarding plane behavior helps reduce the amount of forwarding plane forwarding plane behavior helps reduce the amount of forwarding plane
state required to support a large number of LSPs on a Label Switching state required to support a large number of LSPs on a Label Switching
Router (LSR). This prevents the size of the platform specific label Router (LSR).
space on an LSR from being a constraint to pushing the limits of
RSVP-TE control plane scaling on that node.
Segment Routed RSVP-TE tunnels request the use of a shared forwarding Segment Routed RSVP-TE tunnels request the use of a shared forwarding
plane at every hop of the LSP. The TE link label used at each hop is plane at every hop of the LSP. The TE link label used at each hop is
recorded in the Record Route object (RRO) of the Resv message. The recorded in the Record Route object (RRO) of the Resv message. The
ingress Label Edge Router (LER) uses this recorded information to ingress Label Edge Router (LER) uses this recorded information to
construct a stack of labels that can be imposed on the packets construct a stack of labels that can be imposed on the packets
steered on to the tunnel. In the scenario where the ingress LER steered on to the tunnel. In the scenario where the ingress LER
cannot impose the full label stack, it can use the assistance of one cannot impose the full label stack, it can use the assistance of one
or more delegation hops along the path of the LSP to impose parts of or more delegation hops along the path of the LSP to impose parts of
the label stack. the label stack.
Facility backup is a local repair method [RFC4090] in which a bypass Facility backup is a local repair method [RFC4090] in which a bypass
tunnel is used to provide protection against link or node failures tunnel is used to provide protection against link or node failures
for MPLS RSVP-TE LSPs at the Point of Local Repair (PLR). The for MPLS RSVP-TE LSPs at the Point of Local Repair (PLR). The
facility backup procedures that provide protection against link facility backup procedures that provide protection against link
failures for Segment Routed RSVP-TE LSPs are defined in failures for Segment Routed RSVP-TE LSPs are defined in [RFC8577].
[I-D.ietf-mpls-rsvp-shared-labels]. This document defines the This document defines the facility backup procedures that provide
facility back procedures that provide protection against node protection against node failures for these LSPs. These procedures
failures for Segment Routed RSVP-TE LSPs. These procedures include include protection against delegation hop failures. The document
protection against delegation hop failures. The document also also discusses the procedures for handling backwards compatibility
discusses the procedures for handling backwards compatibility
scenarios where a node along the path of the LSP does not support the scenarios where a node along the path of the LSP does not support the
protocol extensions defined in this document. procedures defined in this document.
The procedures discussed in this document do not cover protection The procedures discussed in this document do not cover protection
against ingress/egress node failures. They also do not apply to against ingress/egress node failures. They also do not apply to
Point to Multipoint (P2MP) RSVP-TE Tunnels. Point to Multipoint (P2MP) RSVP-TE Tunnels.
2. Terminology 2. Terminology
The reader is expected to be familiar with the terminology specified The reader is expected to be familiar with the terminology specified
in [RFC3209], [RFC4090] and [I-D.ietf-mpls-rsvp-shared-labels]. in [RFC3209], [RFC4090] and [RFC8577]. Unless otherwise stated, the
Unless otherwise stated, the term LSPs in this document refer to term LSPs in this document refer to Segment Routed RSVP-TE LSPs. The
Segment Routed RSVP-TE LSPs. The following additional terms are used following additional terms are used in this document:
in this document:
Primary forwarding action: The outbound label forwarding action Primary forwarding action: The outbound label forwarding action
performed at a PLR for a protected LSP before the occurrence of performed at a PLR for a protected LSP before the occurrence of
local failure. local failure.
Backup forwarding action: The outbound label forwarding action Backup forwarding action: The outbound label forwarding action
performed at a PLR for a protected LSP after the occurrence of performed at a PLR for a protected LSP after the occurrence of
local failure. local failure.
3. Node protection specific procedures 3. Node Protection Specific Procedures
A set of Segment Routed RSVP-TE LSPs can share a TE link label on an A set of Segment Routed RSVP-TE LSPs can share a TE link label on an
LSR only if all the LSPs in the set share the same outbound label LSR only if all the LSPs in the set share the same outbound label
forwarding action. For protected LSPs, having the same outbound forwarding action. For protected LSPs, having the same outbound
label forwarding action means having the same primary forwarding label forwarding action means having the same primary forwarding
action and the same backup forwarding action. In the case of LSPs action and the same backup forwarding action. In the case of LSPs
that do not request local protection or LSPs that request only link that do not request local protection or LSPs that request only link
protection, they can use the same outbound label forwarding action if protection, they can use the same outbound label forwarding action if
they reach a common next-hop LSR via a common outgoing TE link. they reach a common next-hop LSR via a common outgoing TE link.
However, in the case of LSPs that request node protection, they can However, in the case of LSPs that request node protection, they can
use the same outbound label forwarding action only if they reach a use the same outbound label forwarding action only if they reach a
common next-next-hop LSR via a common outgoing TE link and a common common next-next-hop LSR via a common outgoing TE link and a common
next-hop LSR. next-hop LSR.
3.1. Applicability of this document 3.1. Applicability of this Document
The label allocation and signaling procedures defined in The label allocation and signaling procedures defined in [RFC8577]
[I-D.ietf-mpls-rsvp-shared-labels] can sufficiently cater to the can sufficiently cater to the following scenarios on an LSR:
following scenarios on an LSR:
(a) Offer no protection to LSPs that do not request local protection (a) Offer no protection to LSPs that do not request local protection
(b) Offer no protection or link protection to LSPs that request link (b) Offer no protection or link protection to LSPs that request link
protection protection
(c) Offer no protection or link protection to LSPs that request node (c) Offer no protection or link protection to LSPs that request node
protection protection
The label allocation and signaling procedures defined in this The label allocation and signaling procedures defined in this
document are meant to enable LSRs to offer node protection to LSPs document are meant to enable LSRs to offer node protection to LSPs
that request node protection. that request node protection.
3.2. PLR procedures for protecting non-delegation next-hop LSR 3.2. PLR Procedures for Protecting Next-Hop Non-Delegation LSR
If the protected next-hop LSR signals a TE link label for the LSP but If the protected next-hop LSR signals a TE link label for the LSP but
does not set the Delegation Label flag in the RRO Label Subobject does not set the Delegation Label flag in the RRO Label Subobject
carried in Resv message, then the PLR SHOULD allocate multiple shared carried in Resv message, then the PLR SHOULD allocate multiple shared
labels for the same TE link such that a unique label is allocated for labels for the same TE link such that a unique label is allocated for
every unique next-next-hop LSR that is reachable via the protected every unique next-next-hop LSR that is reachable via the protected
next-hop LSR. next-hop LSR.
326 348 326 348
+---+ +---+ 321+---+345 +---+ +---+ +---+ +---+ 321+---+345 +---+ +---+
skipping to change at page 5, line 23 skipping to change at page 5, line 21
| | | | | | | | | |
| +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+
+-------| F |-----|G |-----|H |-----|I | +-------| F |-----|G |-----|H |-----|I |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Figure 1: Per-nhop-nnhop label allocation Figure 1: Per-nhop-nnhop label allocation
In the example shown in Figure 1, LSR C has allocated the following In the example shown in Figure 1, LSR C has allocated the following
TE link labels: TE link labels:
321 for the TE link neighbor B to reach the next-next-hop LSR A 321 for the TE link C-B to reach the next-next-hop LSR A
326 for the TE link neighbor B to reach the next-next-hop LSR F 326 for the TE link C-B to reach the next-next-hop LSR F
345 for the TE link neighbor D to reach the next-next-hop LSR E 345 for the TE link C-D to reach the next-next-hop LSR E
348 for the TE link neighbor D to reach the next-next-hop LSR H 348 for the TE link C-D to reach the next-next-hop LSR H
376 for the TE link neighbor G to reach the next-next-hop LSR F 376 for the TE link C-G to reach the next-next-hop LSR F
378 for the TE link neighbor G to reach the next-next-hop LSR H 378 for the TE link C-G to reach the next-next-hop LSR H
If a LSP requesting node protection transits PLR C and if the If a LSP requesting node protection transits PLR C and if the
protected next-hop LSR after C along the LSP path is not a delegation protected next-hop LSR after C along the LSP path is not a delegation
hop, then LSR C signals the respective TE link label depending on the hop, then LSR C signals the respective TE link label depending on the
next-next-hop LSR on the LSP path. next-next-hop LSR on the LSP path.
LSP path: A -> B -> C -> D -> E : Label = 345 LSP path: A -> B -> C -> D -> E : Label = 345
LSP path: A -> B -> C -> D -> H : Label = 348 LSP path: A -> B -> C -> D -> H : Label = 348
LSP path: A -> B -> C -> G -> H : Label = 378 LSP path: A -> B -> C -> G -> H : Label = 378
In all LSP paths above, at PLR C, the protected next-hop LSRs D and G In all LSP paths above, at PLR C, the protected next-hop LSRs D and G
along the LSP paths signal TE link labels but are not delegation hops along the LSP paths signal TE link labels but are not delegation
[I-D.ietf-mpls-rsvp-shared-labels]. hops.
If the primary TE link is operational, LSR C will pop the TE link If the primary TE link is operational, LSR C will pop the TE link
label and forward the packet to the corresponding next-hop LSR over label and forward the packet to the corresponding next-hop LSR over
that TE link. During local repair, LSR C will pop the TE link label that TE link. During local repair, LSR C will pop the TE link label
and also the label beneath the top label, and forward the packet over and also the label beneath the top label, and forward the packet over
the node protecting bypass tunnel to the appropriate next-next-hop the node protecting bypass tunnel to the appropriate next-next-hop
LSR, which is the Merge Point (MP). LSR, which is the Merge Point (MP).
3.3. PLR procedures for protecting a delegation next-hop LSR 3.3. PLR Procedures for Protecting Next-Hop Delegation LSR
The outgoing backup label forwarding action corresponding to a label The outgoing backup label forwarding action corresponding to a label
shared by LSPs requesting node protection MUST bypass the protected shared by LSPs requesting node protection MUST bypass the protected
next-hop LSR. The PLR MUST push the label stack on behalf of the next-hop LSR. The PLR MUST push the label stack on behalf of the
delegation next-hop LSR. Hence, the number of labels that a next-hop delegation LSR. Hence, the number of labels that a
delegation hop chooses to push also depends on the number of labels delegation hop chooses to push also depends on the number of labels
that the upstream hop (acting as PLR) along the primary LSP can push. that the upstream hop (acting as PLR) along the primary LSP can push.
This section extends the Effective Transport Label-Stack Depth (ETLD) This section extends the Effective Transport Label-Stack Depth (ETLD)
signaling procedure specified in [I-D.ietf-mpls-rsvp-shared-labels] signaling procedure specified in [RFC8577] for LSPs requesting node
for LSPs requesting node protection. protection.
Considering Figure 2, assume LER A and LSR B can push a maximum of 3 Considering Figure 2, assume LER A and LSR B can push a maximum of 3
labels on an MPLS packet while the remaining nodes can push a maximum labels on an MPLS packet while the remaining nodes can push a maximum
of 5 labels. LER A originates a Path message with an ETLD of 2 after of 5 labels. LER A originates a Path message with an ETLD of 2 after
reserving space for the bypass tunnel label that should be pushed for reserving space for the bypass tunnel label that should be pushed for
backup forwarding action. In addition to setting the ETLD, LER A backup forwarding action. In addition to setting the ETLD, LER A
also sets the Delegation Helper Label Depth (DHLD) to 2 in the Path also sets the Delegation Helper Label Depth (DHLD) to 2 in the Path
message. The DHLD is computed as the maximum number of labels that message. The DHLD is computed as the maximum number of labels that
the node can push after reserving space for the NNHOP bypass tunnel the node can push after reserving space for the NNHOP bypass tunnel
label that should be pushed for backup forwarding action. The ETLD label that should be pushed for backup forwarding action. The ETLD
skipping to change at page 7, line 28 skipping to change at page 7, line 6
DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4 DHLD:4
ETLD:2 ETLD:3 ETLD:4 ETLD:1 ETLD:2 ETLD:2 ETLD:3 ETLD:4 ETLD:1 ETLD:2
<----- <----- <----- <----- <----- <----- <----- <----- <----- <-----
Notation : <Label>d - delegation label Notation : <Label>d - delegation label
Figure 2: ETLD and DHLD signaling for node protection Figure 2: ETLD and DHLD signaling for node protection
As shown in Figure 2, delegation hop LSR C does not set outgoing ETLD As shown in Figure 2, delegation hop LSR C does not set outgoing ETLD
to 4 that it would normally have set given that LSR C can push a to 4 that it would have normally set given that LSR C can push a
maximum of 5 labels on an outgoing packet. Instead, LSR C sets the maximum of 5 labels on an outgoing packet. Instead, LSR C sets the
outgoing ETLD to the minimum of the ETLD that it computes and the outgoing ETLD to the minimum of the ETLD that it computes and the
DHLD value of its previous hop i.e. minimum(computed ETLD = 4, DHLD value of its previous hop i.e. minimum(computed ETLD = 4,
previous hop DHLD = 2). previous hop DHLD = 2).
The extension for signaling the DHLD in the Path message is defined The extension for signaling the DHLD in the Path message is defined
in Section 4.1. in Section 4.1.
3.3.1. Label Allocation and Stacking 3.3.1. Label Allocation and Stacking
An LSR that decides, based on the modified ETLD procedure, to become An LSR that decides to become a delegation hop for one or more LSPs
a delegation hop for one or more LSPs requesting node protection MUST requesting node protection MUST allocate a delegation label separate
allocate a delegation label separate from delegation label assigned from delegation label assigned for LSPs that are offered no
for LSPs that are offered no protection or link protection - even protection or link protection - even though the delegation segments
though the delegation segments share the same hops. In the example share the same hops. In the example shown in Figure 2, the
shown in Figure 2, the delegation hops LSRs C, E and I will set the delegation hops LSRs C, E and I will set the Delegation Label flag in
delegation flag in the Label sub-object that they add to the Resv the Label sub-object that they add to the Resv message.
message.
A PLR node that offers node protection to a delegation hop SHOULD be A PLR node that offers node protection to a delegation hop SHOULD be
capable of helping the downstream delegation when the primary TE link capable of helping the downstream delegation when the primary TE link
to the delegation hop goes down. In the example shown in Figure 1, to the delegation hop goes down. In the example shown in Figure 1,
the LSRs B, D and H act as helpers for their respective downstream the LSRs B, D and H act as helpers for their respective downstream
delegation hops. The PLR nodes that are delegation helpers along the delegation hops. The PLR nodes that are delegation helpers along the
path of LSPs requesting node protection SHOULD allocate an unique path of LSPs requesting node protection SHOULD allocate a unique
delegation helper label for every delegation label signaled by the label for every delegation label signaled by the protected delegation
protected delegation node. node.
Before primary TE link failure, the PLR playing the role of a Before primary TE link failure, the PLR playing the role of a
delegation helper pops the incoming label and forwards the packet on delegation helper pops the incoming label and forwards the packet on
the primary TE link. During local repair, the delegation helper PLR the primary TE link. During local repair, the delegation helper PLR
pops the incoming label and also the label beneath it and pushes the pops the incoming label and also the label beneath it and pushes the
label stack on behalf of the protected or next hop delegation node. label stack on behalf of the next hop delegation LSR and forwards the
packet over the bypass tunnel.
Any LSR that creates label stack upstream of the delegation helper Any LSR that creates label stack upstream of the delegation helper
MUST include the label signaled by the delegation helper onto the MUST include the label signaled by the delegation helper onto the
outgoing label stack just as it uses the TE link label to construct outgoing label stack just as it uses the TE link label to construct
outgoing label stack. outgoing label stack.
3.4. Backwards Compatibility 3.4. Backwards Compatibility
3.4.1. LSR does not support node protection for Shared Labels 3.4.1. LSR does not Support Node Protection for Shared Labels
As defined in Section 3.1, any LSR along the path of an LSP As defined in Section 3.1, any LSR along the path of an LSP
requesting node protection may choose to instead offer no protection requesting node protection may choose to instead offer no protection
or link protection. Hence, it must be possible to build an LSP where or link protection. Hence, it must be possible to build an LSP where
some LSRs along the path support the node protection extensions some LSRs along the path support the node protection extensions
defined in this document whereas the rest of the LSRs support only defined in this document whereas the rest of the LSRs support only
[I-D.ietf-mpls-rsvp-shared-labels]. Any PLR along the LSP path that [RFC8577]. Any PLR along the LSP path that does not support the
does not support the procedures defined in this document MUST provide procedures defined in this document MUST provide either no protection
either no protection or link protection for the LSPs requesting node or link protection for the LSPs requesting node protection.
protection.
Any PLR along the LSP path that is protecting a delegation hop where
both nodes support the extensions defined in this document must
determine whether it can push the label stack on behalf of the next-
hop delegation hop during local repair. If the PLR cannot push the
label stack, then it SHOULD provide link protection or no local
protection for the next-hop LSR.
ETLD:2 ETLD:1 ETLD:4 ETLD:3 ETLD:2 ETLD:2 ETLD:1 ETLD:4 ETLD:3 ETLD:2
DHLD:2 DHLD:2 - DHLD:4 DHLD:4 DHLD:2 DHLD:2 - DHLD:4 DHLD:4
-----> -----> -----> -----> -----> -----> -----> -----> -----> ----->
1300d 1300d
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:1 | A |-----| B |-----| C |-----| D |-----| E |-----| F | ETLD:1
+---+ +---+ +---+ +---+ +---+ +---+ DHLD:4 +---+ +---+ +---+ +---+ +---+ +---+ DHLD:4
| | | | | | | |
| | | | | | | |
skipping to change at page 9, line 30 skipping to change at page 8, line 35
ETLD:4 ETLD:1 ETLD:2 ETLD:3 ETLD:4 ETLD:4 ETLD:1 ETLD:2 ETLD:3 ETLD:4
<----- <----- <----- <----- <----- <----- <----- <----- <----- <-----
Notation : <Label>d - delegation label Notation : <Label>d - delegation label
Figure 3: Delegation node does not support signaling DHLD Figure 3: Delegation node does not support signaling DHLD
In Figure 3, assume LER A and LSR B can push a maximum of 3 labels to In Figure 3, assume LER A and LSR B can push a maximum of 3 labels to
the MPLS packet while the remaining nodes can push a maximum of 5 the MPLS packet while the remaining nodes can push a maximum of 5
labels. Also assume that LSR C supports the extensions defined in labels. Also assume that LSR C supports the extensions defined in
[I-D.ietf-mpls-rsvp-shared-labels] but does not support the [RFC8577] but does not support the extensions defined in this
extensions defined in this document. Based on ETLD signaling document. Based on ETLD signaling procedure, LSR C will become a
procedure, LSR C will become a delegation hop. However, as LSR C delegation hop. However, as LSR C cannot understand the DHLD
cannot understand the DHLD signaled by the previous hop LSR B, LSR C signaled by the previous hop LSR B, LSR C will set outgoing ETLD to
will set outgoing ETLD to 4. If LSR C had supported the DHLD 4. If LSR C had supported the DHLD signaling, it would have set
signaling, it would have set outgoing ETLD to 2 (see Section 3.3). outgoing ETLD to 2 (see Section 3.3). When PLR B receives shared
When PLR B receives shared label from the protected next-hop LSR C in label from the protected next-hop LSR C in the Resv message, it must
the Resv message, it must determine the number of labels it has to determine the number of labels it has to push in order to offer node
push in order to offer node protection from the RRO sub-object protection from the RRO sub-object carried in Resv. As the label
carried in Resv. As the label stack depth of the delegation hop C is stack depth of the delegation hop C is greater than the number of
greater than the number of labels LSR C can push, it must either not labels LSR C can push, it must either not provide local protection or
provide local protection or provide only link protection for the LSP. provide only link protection for the LSP.
3.4.2. PLR procedures for protecting a hop not supporting shared Labels 3.4.2. Protected Hop does not Support Shared Labels
If the ingress LER has requested label stacking to reach delegation If the ingress LER has requested label stacking to reach delegation
hop for the LSP requesting node protection, and if the next-hop LSR hop for the LSP requesting node protection, and if the next-hop LSR
allocates a regular label for the LSP, then the LSR MUST also allocates a regular label for the LSP, then the LSR MUST also
allocate a regular label for the LSP. allocate a regular label for the LSP.
If the ingress LER has requested label stacking to reach the egress If the ingress LER has requested label stacking to reach the egress
LER for the LSP requesting node protection, and if the next-hop LSR LER for the LSP requesting node protection, and if the next-hop LSR
has allocated a regular label for the LSP, then the PLR MUST become a has allocated a regular label for the LSP, then the PLR MUST become a
delegation hop and set the RRO Label Subobject delegation label flag delegation hop and set the RRO Label Subobject delegation label flag
in the RRO carried in Resv message. The PLR MUST set ETLD to 1 in in the RRO carried in Resv message. The PLR MUST set ETLD to 1 in
its outgoing Path message. its outgoing Path message.
3.4.3. PLR not supporting shared Labels 3.4.3. PLR does not Support Shared Labels
If an LSR determines that its immediate upstream LSR has not included If an LSR determines that its immediate upstream LSR (PLR) has not
an ETLD in the incoming Path message, then the LSR MUST become a included an ETLD in the incoming Path message, then the LSR MUST
delegation hop and set the ETLD to 1 in the outgoing Path message. become a delegation hop and set the ETLD to 1 in the outgoing Path
The outgoing ETLD is set to 1 because the upstream LSR does not message. The outgoing ETLD is set to 1 because the upstream LSR does
support shared labels and cannot push the label stack on behalf of not support shared labels and cannot push the label stack on behalf
this LSR. of this LSR.
4. Protocol Extensions 4. Protocol Extensions
This section introduces a protocol extension to support the This section discusses the protocol extension required to support the
procedures in Section 3.3 procedures in Section 3.3
4.1. DHLD encoding in ETLD Attributes TLV 4.1. DHLD Encoding in ETLD Attributes TLV
Delegation Helper Label Depth (DHLD) is defined as the number of Delegation Helper Label Depth (DHLD) is defined as the number of
labels that an LSR has the capability to push while performing local labels that an LSR has the capability to push while performing local
repair protecting the next-hop delegation LSR. This document updates repair protecting the next-hop delegation LSR. This document updates
the ETLD Attributes TLV defined in the ETLD Attributes TLV defined in [RFC8577]. The encoding of DHLD
[I-D.ietf-mpls-rsvp-shared-labels]. The encoding of DHLD in the ETLD in the ETLD Attributes TLV is shown in Figure 4
Attributes TLV is shown in Figure 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | DHLD | ETLD | | Reserved | DHLD | ETLD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The ETLD Attributes TLV Figure 4: The ETLD Attributes TLV
The presence of ETLD Attributes TLV in the HOP_ATTRIBUTES sub-object The presence of ETLD Attributes TLV in the HOP_ATTRIBUTES sub-object
[RFC7570] of the RRO object carried in Path message indicates that [RFC7570] of the RRO object carried in Path message indicates that
the hop identified by the preceding IPv4 or IPv6 or Unnumbered the hop identified by the preceding IPv4 or IPv6 or Unnumbered
Interface ID sub-object supports automatic delegation defined in Interface ID sub-object supports automatic delegation [RFC8577].
[I-D.ietf-mpls-rsvp-shared-labels].
An implementation that supports this document MUST set the 8 bits An implementation that supports this document MUST set the 8 bits
from bit number 16 to bit number 23 with its DHLD value as indicated from bit number 16 to bit number 23 with its DHLD value as indicated
in Figure 4 when signaling Path message for an LSP for which node in Figure 4 when signaling Path message for an LSP for which node
protection has been requested. protection has been requested.
When processing the ETLD Attributes TLV of the previous hop LSR in When processing the ETLD Attributes TLV of the previous hop LSR in
the received Path message, the LSR checks whether it has to be the the received Path message, the LSR checks whether it has to be the
delegation hop based on the ETLD algorithm defined in delegation hop based on the ETLD algorithm defined in [RFC8577].
[I-D.ietf-mpls-rsvp-shared-labels].
If the LSR does not become a delegation hop along the LSP path, then If the LSR does not become a delegation hop along the LSP path, then
no further action is required based on the DHLD value set by the no further action is required based on the DHLD value set by the
previous hop. previous hop.
If the LSR does become a delegation hop along the LSP path, then it If the LSR does become a delegation hop along the LSP path, then it
MUST decode the 8 bit unsigned value from bit number 16 to bit number MUST decode the 8 bit unsigned value from bit number 16 to bit number
23 as indicated in Figure 4. If the 8 bit value is zero, then the 23 as indicated in Figure 4. If the 8 bit value is zero, then the
LSR MUST infer that the previous hop has not included DHLD in the LSR MUST infer that the previous hop has not included DHLD in the
ETLD Attributes TLV. If the 8 bit value is non-zero, then the LSR ETLD Attributes TLV. If the 8 bit value is non-zero, then the LSR
skipping to change at page 11, line 38 skipping to change at page 10, line 44
This document includes no requests to IANA. This document includes no requests to IANA.
7. Security Considerations 7. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] and considerations pertaining to the original RSVP protocol [RFC2205] and
RSVP-TE [RFC3209] and those that are described in [RFC5920] remain RSVP-TE [RFC3209] and those that are described in [RFC5920] remain
relevant. relevant.
8. Normative References 8. References
[I-D.ietf-mpls-rsvp-shared-labels] 8.1. Normative References
Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE tunnels on a shared MPLS forwarding
plane", draft-ietf-mpls-rsvp-shared-labels-07 (work in
progress), December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[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,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B.
Wright, "Label Switched Path (LSP) Attribute in the Wright, "Label Switched Path (LSP) Attribute in the
Explicit Route Object (ERO)", RFC 7570, Explicit Route Object (ERO)", RFC 7570,
DOI 10.17487/RFC7570, July 2015, DOI 10.17487/RFC7570, July 2015,
<https://www.rfc-editor.org/info/rfc7570>. <https://www.rfc-editor.org/info/rfc7570>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8577] Sitaraman, H., Beeram, V., Parikh, T., and T. Saad,
"Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding
Plane", RFC 8577, DOI 10.17487/RFC8577, April 2019,
<https://www.rfc-editor.org/info/rfc8577>.
8.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses Authors' Addresses
Chandra Ramachandran Chandra Ramachandran
Juniper Networks Juniper Networks
Email: csekar@juniper.net Email: csekar@juniper.net
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
10 Technology Park Drive
Westford, MA 01886
US
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Harish Sitaraman Harish Sitaraman
Juniper Networks Individual
1133 Innovation Way
Sunnyvale, CA 94089
US
Email: hsitaraman@juniper.net Email: harish.ietf@gmail.com
 End of changes. 45 change blocks. 
133 lines changed or deleted 123 lines changed or added

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