draft-ietf-mpls-rsvp-shared-labels-06.txt   draft-ietf-mpls-rsvp-shared-labels-07.txt 
MPLS Working Group H. Sitaraman MPLS Working Group H. Sitaraman
Internet-Draft V. Beeram Internet-Draft V. Beeram
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: May 25, 2019 T. Parikh Expires: June 13, 2019 T. Parikh
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
November 21, 2018 December 10, 2018
Signaling RSVP-TE tunnels on a shared MPLS forwarding plane Signaling RSVP-TE tunnels on a shared MPLS forwarding plane
draft-ietf-mpls-rsvp-shared-labels-06.txt draft-ietf-mpls-rsvp-shared-labels-07.txt
Abstract Abstract
As the scale of MPLS RSVP-TE networks has grown, so the number of As the scale of MPLS RSVP-TE networks has grown, so the number of
Label Switched Paths (LSPs) supported by individual network elements Label Switched Paths (LSPs) supported by individual network elements
has increased. Various implementation recommendations have been has increased. Various implementation recommendations have been
proposed to manage the resulting increase in control plane state. proposed to manage the resulting increase in control plane state.
However, those changes have had no effect on the number of labels However, those changes have had no effect on the number of labels
that a transit Label Switching Router (LSR) has to support in the that a transit Label Switching Router (LSR) has to support in the
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 25, 2019. This Internet-Draft will expire on June 13, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 48 skipping to change at page 3, line 48
This document describes a mechanism that prevents the size of the This document describes a mechanism that prevents the size of the
platform specific label space on a Label Switching Router (LSR) from platform specific label space on a Label Switching Router (LSR) from
being a constraint to pushing the limits of control plane scaling on being a constraint to pushing the limits of control plane scaling on
that node. that node.
This work introduces the notion of pre-installed 'per Traffic This work introduces the notion of pre-installed 'per Traffic
Engineering (TE) link labels' that are allocated by an LSR. Each Engineering (TE) link labels' that are allocated by an LSR. Each
such label is installed in the MPLS forwarding plane with a 'pop' such label is installed in the MPLS forwarding plane with a 'pop'
operation and the instruction to forward the received packet over the operation and the instruction to forward the received packet over the
TE link. An LSR advertises this label in the Label object of a Resv TE link. An LSR advertises this label in the Label object of a Resv
message as LSPs are set up and they are recorded hop by hop in the message as LSPs are set up and they are recorded hop-by-hop in the
Record Route object (RRO) of the Resv message as it traverses the Record Route object (RRO) of the Resv message as it traverses the
network. To make use of this feature, the ingress Label Edge Router network. To make use of this feature, the ingress Label Edge Router
(LER) pushes a stack of labels [RFC3031] as received in the RRO. (LER) pushes a stack of labels [RFC3031] as received in the RRO.
These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that These 'TE link labels' can be shared by MPLS RSVP-TE LSPs that
traverse the same TE link. traverse the same TE link.
This forwarding plane behavior fits in the MPLS architecture This forwarding plane behavior fits in the MPLS architecture
[RFC3031] and is same as that exhibited by Segment Routing (SR) [RFC3031] and is same as that exhibited by Segment Routing (SR)
[RFC8402] when using an MPLS forwarding plane and a series of [RFC8402] when using an MPLS forwarding plane and a series of
skipping to change at page 10, line 27 skipping to change at page 10, line 27
delegate one or more specific transit hops is defined in Section 9.4. delegate one or more specific transit hops is defined in Section 9.4.
The extension required for the delegation hop to indicate that the The extension required for the delegation hop to indicate that the
recorded label is a delegation label is defined in Section 9.5. recorded label is a delegation label is defined in Section 9.5.
5.3. Automatic Delegation 5.3. Automatic Delegation
In this approach, the ingress LER lets the downstream LSRs In this approach, the ingress LER lets the downstream LSRs
automatically pick suitable delegation hops during the initial automatically pick suitable delegation hops during the initial
signaling sequence. The ingress does not need to be aware up front signaling sequence. The ingress does not need to be aware up front
of the label stack depth push limit of each of the transit LSRs. of the label stack depth push limit of each of the transit LSRs.
This approach SHOULD be used if there are loose hops in the explicit This approach SHOULD be used if there are loose hops [RFC3209] in the
route. The delegation hops are picked based on a per-hop signaled explicit route. The delegation hops are picked based on a per-hop
attribute called the Effective Transport Label-Stack Depth (ETLD) as signaled attribute called the Effective Transport Label-Stack Depth
described in the next section. (ETLD) as described in the next section.
5.3.1. Effective Transport Label-Stack Depth (ETLD) 5.3.1. Effective Transport Label-Stack Depth (ETLD)
The ETLD is signaled as a per-hop recorded attribute in the Path The ETLD is signaled as a per-hop recorded attribute in the Path
message [RFC7570]. When automatic delegation is requested, the message [RFC7570]. When automatic delegation is requested, the
ingress MUST populate the ETLD with the maximum number of transport ingress MUST populate the ETLD with the maximum number of transport
labels that it can potentially send to its downstream hop. This labels that it can potentially send to its downstream hop. This
value is then decremented at each successive hop. If a node is value is then decremented at each successive hop. If a node is
reached and it is determined that this hop cannot support automatic reached and it is determined that this hop cannot support automatic
delegation, then it MUST act as if it does not support TE link delegation, then it MUST act as if it does not support TE link
skipping to change at page 11, line 4 skipping to change at page 11, line 4
If a node is reached and it is determined that this hop cannot If a node is reached and it is determined that this hop cannot
receive more than one transport label, then that node MUST select receive more than one transport label, then that node MUST select
itself as the delegation hop. If there is a node or a sequence of itself as the delegation hop. If there is a node or a sequence of
nodes along the path of the LSP that do not support ETLD, then the nodes along the path of the LSP that do not support ETLD, then the
immediate hop that supports ETLD MUST select itself as the delegation immediate hop that supports ETLD MUST select itself as the delegation
hop. The ETLD MUST be decremented at each non-delegation transit hop hop. The ETLD MUST be decremented at each non-delegation transit hop
by either 1 or some appropriate number based on the limitations at by either 1 or some appropriate number based on the limitations at
that hop. At each delegation hop, the ETLD MUST be reset to the that hop. At each delegation hop, the ETLD MUST be reset to the
maximum number of transport labels that the hop can send and the ETLD maximum number of transport labels that the hop can send and the ETLD
decrements start again at each successive hop until either a new decrements start again at each successive hop until either a new
delegation hop is selected or the egress is reached. The net result delegation hop is selected or the egress is reached. As a result, by
is that by the time the Path message reaches the egress, all the time the Path message reaches the egress, all delegation hops are
delegation hops are selected. During the Resv processing, at each selected. During the Resv processing, at each delegation hop, a
delegation hop, a suitable delegation label is selected (either an suitable delegation label is selected (either an existing label is
existing label is reused or a new label is allocated) and recorded in reused or a new label is allocated) and recorded in the Resv message.
the Resv message.
Consider the example shown in Figure 5. Let's assume ingress LER A Consider the example shown in Figure 5. Let's assume ingress LER A
can push up to 3 transport labels while the remaining nodes can push can push up to 3 transport labels while the remaining nodes can push
up to 5 transport labels. The ingress LER A signals the initial Path up to 5 transport labels. The ingress LER A signals the initial Path
message with ETLD set to 3. The ETLD value is adjusted at each message with ETLD set to 3. The ETLD value is adjusted at each
successive hop and signaled downstream as shown. By the time the successive hop and signaled downstream as shown. By the time the
Path message reaches the egress LER L, LSRs D and I are automatically Path message reaches the egress LER L, LSRs D and I are automatically
selected as delegation hops. selected as delegation hops.
ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4 ETLD:3 ETLD:2 ETLD:1 ETLD:5 ETLD:4
skipping to change at page 20, line 46 skipping to change at page 20, line 46
[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>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-15 data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), October 2018. (work in progress), December 2018.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
and S. Molendini, "RSVP Refresh Overhead Reduction and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
<https://www.rfc-editor.org/info/rfc2961>. <https://www.rfc-editor.org/info/rfc2961>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
 End of changes. 8 change blocks. 
17 lines changed or deleted 16 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/