draft-ietf-mpls-rsvp-shared-labels-03.txt   draft-ietf-mpls-rsvp-shared-labels-04.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: March 14, 2019 T. Parikh Expires: April 11, 2019 T. Parikh
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
September 10, 2018 October 8, 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-03.txt draft-ietf-mpls-rsvp-shared-labels-04.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 March 14, 2019. This Internet-Draft will expire on April 11, 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 2, line 50 skipping to change at page 2, line 50
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 5 3. Allocation of TE Link Labels . . . . . . . . . . . . . . . . 5
4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 5 4. Segment Routed RSVP-TE Tunnel Setup . . . . . . . . . . . . . 5
5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7 5. Delegating Label Stack Imposition . . . . . . . . . . . . . . 7
5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8 5.1. Stacking at the Ingress . . . . . . . . . . . . . . . . . 8
5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8 5.1.1. Stack to Reach Delegation Hop . . . . . . . . . . . . 8
5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 9 5.1.2. Stack to Reach Egress . . . . . . . . . . . . . . . . 9
5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 10 5.2. Explicit Delegation . . . . . . . . . . . . . . . . . . . 10
5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 10 5.3. Automatic Delegation . . . . . . . . . . . . . . . . . . 10
5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 10 5.3.1. Effective Transport Label-Stack Depth (ETLD) . . . . 10
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 11 6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 12
7. Construction of Label Stacks . . . . . . . . . . . . . . . . 12 7. Construction of Label Stacks . . . . . . . . . . . . . . . . 12
8. Facility Backup Protection . . . . . . . . . . . . . . . . . 13 8. Facility Backup Protection . . . . . . . . . . . . . . . . . 13
8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 13
9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 14 9. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 14
9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 15 9.2. Attribute Flags TLV: TE Link Label . . . . . . . . . . . 15
9.3. RRO Label Subobject Flag: TE Link Label . . . . . . . . . 15 9.3. RRO Label Subobject Flag: TE Link Label . . . . . . . . . 15
9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 15 9.4. Attribute Flags TLV: LSI-D . . . . . . . . . . . . . . . 15
9.5. RRO Label Subobject Flag: Delegation Label . . . . . . . 16 9.5. RRO Label Subobject Flag: Delegation Label . . . . . . . 16
9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 16 9.6. Attributes Flags TLV: LSI-D-S2E . . . . . . . . . . . . . 16
9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 16 9.7. Attributes TLV: ETLD . . . . . . . . . . . . . . . . . . 16
10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 17 13.1. Attribute Flags: TE Link Label, LSI-D, LSI-D-S2E . . . . 18
13.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 18 13.2. Attribute TLV: ETLD . . . . . . . . . . . . . . . . . . 18
13.3. Record Route Label Sub-object Flags: TE Link Label, 13.3. Record Route Label Sub-object Flags: TE Link Label,
Delegation Label . . . . . . . . . . . . . . . . . . . . 18 Delegation Label . . . . . . . . . . . . . . . . . . . . 18
13.4. Error Codes and Error Values . . . . . . . . . . . . . . 19 13.4. Error Codes and Error Values . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
15.1. Normative References . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . 19
15.2. Informative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 41 skipping to change at page 4, line 41
so makes MBB events faster. Periodic MBB events are relatively so makes MBB events faster. Periodic MBB events are relatively
common in networks that deploy the 'auto-bandwidth' feature on common in networks that deploy the 'auto-bandwidth' feature on
RSVP-TE LSPs to monitor bandwidth utilization and periodically RSVP-TE LSPs to monitor bandwidth utilization and periodically
adjust LSP bandwidth. adjust LSP bandwidth.
4. Mix and match labels: Both 'TE link labels' and regular labels 4. Mix and match labels: Both 'TE link labels' and regular labels
can be used on transit hops for a single RSVP-TE tunnel (see can be used on transit hops for a single RSVP-TE tunnel (see
Section 6). This allows backward compatibility with transit LSRs Section 6). This allows backward compatibility with transit LSRs
that provide regular labels in Resv messages. that provide regular labels in Resv messages.
No additional extensions are required to routing protocols in order No additional extensions to routing protocols are required in order
to support this shared MPLS forwarding plane. Functionalities such to support key functionalities such as bandwidth admission control,
as bandwidth admission control, LSP priorities, preemption, auto- LSP priorities, preemption and auto-bandwidth on this shared MPLS
bandwidth and Fast Reroute continue to work with this forwarding forwarding plane. This document also discusses how Fast Reroute
plane. [RFC4090] via facility backup link protection using regular bypass
tunnels can be supported on this forwarding plane.
The signaling procedures and extensions discussed in this document do The signaling procedures and extensions discussed in this document do
not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels. not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels.
2. Terminology 2. Terminology
The following terms are used in this document: The following terms are used in this document:
TE link label: An incoming label at an LSR that will be popped by TE link label: An incoming label at an LSR that will be popped by
the LSR with the packet being forwarded over a specific outgoing the LSR with the packet being forwarded over a specific outgoing
skipping to change at page 7, line 15 skipping to change at page 7, line 15
If, in this example, there was another RSVP-TE tunnel T3 from F to I If, in this example, there was another RSVP-TE tunnel T3 from F to I
on path F-B-C-D-E-I, then this would also share the TE links B-C, on path F-B-C-D-E-I, then this would also share the TE links B-C,
C-D, and D-E and additionally traverse link E-I. The label stack C-D, and D-E and additionally traverse link E-I. The label stack
used by F would be {150, 200, 250, 850}. Hence, regardless of the used by F would be {150, 200, 250, 850}. Hence, regardless of the
ingress and egress LERs from where the LSPs start and end, they will ingress and egress LERs from where the LSPs start and end, they will
share LSR labels at shared hops in the shared MPLS forwarding plane. share LSR labels at shared hops in the shared MPLS forwarding plane.
There MAY be local operator policy at the ingress LER that influences There MAY be local operator policy at the ingress LER that influences
the maximum depth of the label stack that can be pushed for a Segment the maximum depth of the label stack that can be pushed for a Segment
Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER Routed RSVP-TE tunnel. Prior to signaling the LSP, the ingress LER
may decide that it would be unable to push a label stack containing may determine that it would be unable to push a label stack
one label for each hop along the path. In this case the LER can containing one label for each hop along the path. In some scenarios,
choose either to not signal a Segment Routed RSVP-TE tunnel (using the ingress LER may not have sufficient information to make that
normal LSP signaling instead), or can adopt the techniques described determination. In these cases the LER SHOULD adopt the techniques
in Section 5 or Section 6. described in Section 5.
5. Delegating Label Stack Imposition 5. Delegating Label Stack Imposition
One or more transit LSRs can assist the ingress LER by imposing part One or more transit LSRs can assist the ingress LER by imposing part
of the label stack required for the path. Consider the example in of the label stack required for the path. Consider the example in
Figure 2 with an RSVP-TE tunnel from A to L on path Figure 2 with an RSVP-TE tunnel from A to L on path
A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A A-B-C-D-E-F-G-H-I-J-K-L. In this case, the LSP is too long for LER A
to impose the full label stack, so it uses the assistance of to impose the full label stack, so it uses the assistance of
delegation hops LSR D and LSR I to impose parts of the label stack. delegation hops LSR D and LSR I to impose parts of the label stack.
skipping to change at page 10, line 26 skipping to change at page 10, line 26
The signaling extension required for the ingress LER to explicitly The signaling extension required for the ingress LER to explicitly
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. The of the label stack depth push limit of each of the transit LSRs.
delegation hops are picked based on a per-hop signaled attribute This approach SHOULD be used if there are loose hops in the explicit
called the Effective Transport Label-Stack Depth (ETLD) as described route. The delegation hops are picked based on a per-hop signaled
in the next section. attribute called the Effective Transport Label-Stack Depth (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 attribute in the Path message The ETLD is signaled as a per-hop recorded attribute in the Path
[RFC7570]. When automatic delegation is requested, the ingress MUST message [RFC7570]. When automatic delegation is requested, the
populate the ETLD with the maximum number of transport labels that it ingress MUST populate the ETLD with the maximum number of transport
can potentially send to its downstream hop. This value is then labels that it can potentially send to its downstream hop. This
decremented at each successive hop. If a node is reached where the value is then decremented at each successive hop. If a node is
ETLD set from the previous hop is 1, then that node MUST select reached and it is determined that this hop cannot support automatic
itself as the delegation hop. If a node is reached and it is delegation, then it MUST act as if it does not support TE link
determined that this hop cannot receive more than one transport labels. If a node is reached where the ETLD set from the previous
label, then that node MUST select itself as the delegation hop. If hop is 1, then that node MUST select itself as the delegation hop.
there is a node or a sequence of nodes along the path of the LSP that If a node is reached and it is determined that this hop cannot
do not support ETLD, then the immediate hop that supports ETLD MUST receive more than one transport label, then that node MUST select
select itself as the delegation hop. The ETLD MUST be decremented at itself as the delegation hop. If there is a node or a sequence of
each non-delegation transit hop by either 1 or some appropriate nodes along the path of the LSP that do not support ETLD, then the
number based on the limitations at that hop. At each delegation hop, immediate hop that supports ETLD MUST select itself as the delegation
the ETLD MUST be reset to the maximum number of transport labels that hop. The ETLD MUST be decremented at each non-delegation transit hop
the hop can send and the ETLD decrements start again at each by either 1 or some appropriate number based on the limitations at
successive hop until either a new delegation hop is selected or the that hop. At each delegation hop, the ETLD MUST be reset to the
egress is reached. The net result is that by the time the Path maximum number of transport labels that the hop can send and the ETLD
message reaches the egress, all delegation hops are selected. During decrements start again at each successive hop until either a new
the Resv processing, at each delegation hop, a suitable delegation delegation hop is selected or the egress is reached. The net result
label is selected (either an existing label is reused or a new label is that by the time the Path message reaches the egress, all
is allocated) and recorded in the Resv message. delegation hops are selected. During the Resv processing, at each
delegation hop, a suitable delegation label is selected (either an
existing label is reused or a new label is allocated) and recorded in
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 11, line 35 skipping to change at page 11, line 39
| L |-----| K |-----| J |-----| I |-----| H |-----+ G + | L |-----| K |-----| J |-----| I |-----| H |-----+ G +
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2 ETLD:3 ETLD:4 ETLD:5 ETLD:1 ETLD:2
<----- <----- <----- <----- <----- <----- <----- <----- <----- <-----
Figure 5: ETLD Figure 5: ETLD
When an LSP that requests automatic delegation also requests facility When an LSP that requests automatic delegation also requests facility
backup protection [RFC4090], the ingress or the delegation hop MUST backup protection [RFC4090], the ingress or the delegation hop MUST
account for the bypass tunnel's label when populating the ETLD. So, account for the bypass tunnel's label(s) when populating the ETLD.
Hence, when a regular bypass tunnel is used to protect the facility,
the ETLD that gets populated on these nodes is one less than what the ETLD that gets populated on these nodes is one less than what
gets populated for a corresponding unprotected LSP. gets populated for a corresponding unprotected LSP.
Signaling extension for the ingress LER to request automatic Signaling extension for the ingress LER to request automatic
delegation is defined in Section 9.4. The extension for signaling delegation is defined in Section 9.4. The extension for signaling
the ETLD is defined in Section 9.7. The extension required for the the ETLD is defined in Section 9.7. The extension required for the
delegation hop to indicate that the recorded label is a delegation delegation hop to indicate that the recorded label is a delegation
label is defined in Section 9.5. label is defined in Section 9.5.
6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel 6. Mixing TE Link Labels and Regular Labels in an RSVP-TE Tunnel
skipping to change at page 12, line 51 skipping to change at page 13, line 13
stack: stack:
Each RRO label sub-object SHOULD be processed starting with the Each RRO label sub-object SHOULD be processed starting with the
label sub-object from the first downstream hop. Any label label sub-object from the first downstream hop. Any label
provided by the first downstream hop MUST always be pushed on the provided by the first downstream hop MUST always be pushed on the
label stack regardless of the label type. If the label type is a label stack regardless of the label type. If the label type is a
TE link label, then any label from the next downstream hop MUST TE link label, then any label from the next downstream hop MUST
also be pushed on the constructed label stack. If the label type also be pushed on the constructed label stack. If the label type
is a regular label, then any label from the next downstream hop is a regular label, then any label from the next downstream hop
MUST NOT be pushed on the constructed label stack. If the label MUST NOT be pushed on the constructed label stack. If the label
type is a delegation label, then the stacking procedure stops at type is a delegation label, then the type of stacking approach
that delegation hop. Approaches in Section 5.1 SHOULD be used to chosen by the ingress for this LSP (Section 5.1) MUST be used to
determine how the delegation labels are pushed in the label stack. determine how the delegation labels are pushed in the label stack.
8. Facility Backup Protection 8. Facility Backup Protection
The following section describes how link protection works with The following section describes how link protection works with
facility backup protection [RFC4090] for the Segment Routed RSVP-TE facility backup protection [RFC4090] using regular bypass tunnels for
tunnels. The procedures for supporting node protection are not the Segment Routed RSVP-TE tunnels. The procedures for supporting
discussed in this document. node protection are not discussed in this document. The use of
Segment Routed bypass tunnels for providing facility protection is
left for further study.
8.1. Link Protection 8.1. Link Protection
To provide link protection at a Point of Local Repair (PLR) with a To provide link protection at a Point of Local Repair (PLR) with a
shared MPLS forwarding plane, the LSR SHOULD allocate a separate TE shared MPLS forwarding plane, the LSR SHOULD allocate a separate TE
link label for the TE link that will be used for RSVP-TE tunnels that link label for the TE link that will be used for RSVP-TE tunnels that
request link protection from the ingress. No signaling extensions request link protection from the ingress. No signaling extensions
are required to support link protection for RSVP-TE tunnels over the are required to support link protection for RSVP-TE tunnels over the
shared MPLS forwarding plane. shared MPLS forwarding plane.
skipping to change at page 15, line 16 skipping to change at page 15, line 16
Bit Number 16 (Early allocation by IANA): TE Link Label Bit Number 16 (Early allocation by IANA): TE Link Label
The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
object of a Path message indicates that the ingress has requested/ object of a Path message indicates that the ingress has requested/
mandated the use and recording of TE link labels at all hops along mandated the use and recording of TE link labels at all hops along
the path of this LSP. When a node that does not cater to the mandate the path of this LSP. When a node that does not cater to the mandate
receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object
with this flag set, it MUST send a PathErr message with an error code with this flag set, it MUST send a PathErr message with an error code
of 'Routing Problem (24)' and an error value of 'TE link label usage of 'Routing Problem (24)' and an error value of 'TE link label usage
failure (TBD3)'. failure (TBD3)'. A transit hop that caters to this request/mandate
MUST also check for the presence of other Attribute Flags introduced
in this document (Section 9.4 and Section 9.6) and process them as
specified. An ingress LER that sets this bit MUST also set the
"label recording desired" flag [RFC3209] in the SESSION_ATTRIBUTE
object.
9.3. RRO Label Subobject Flag: TE Link Label 9.3. RRO Label Subobject Flag: TE Link Label
Bit Number (TBD1): TE Link Label Bit Number (TBD1): TE Link Label
The presence of this flag indicates that the recorded label is a TE The presence of this flag indicates that the recorded label is a TE
link label. This flag MUST be used by a node only if the use and link label. This flag MUST be used by a node only if the use and
recording of TE link labels is requested/mandated for the LSP. recording of TE link labels is requested/mandated for the LSP.
9.4. Attribute Flags TLV: LSI-D 9.4. Attribute Flags TLV: LSI-D
Bit Number 17 (Early allocation by IANA): Label Stack Imposition - Bit Number 17 (Early allocation by IANA): Label Stack Imposition -
Delegation (LSI-D) Delegation (LSI-D)
Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES Automatic Delegation: The presence of this flag in the LSP_ATTRIBUTES
object of a Path message indicates that the ingress has requested object of a Path message indicates that the ingress has requested
automatic delegation of label stack imposition. This flag MUST be automatic delegation of label stack imposition. This flag MUST be
set in the LSP_ATTRIBUTES object of a Path message only if the use set in the LSP_ATTRIBUTES object of a Path message only if the use
and recording of TE link labels is requested/mandated for this LSP. and recording of TE link labels is requested/mandated for this LSP.
If the transit hop does not support this flag, it MUST act as if it
does not support TE link labels. If the use of TE link labels was
mandated in the LSP_REQUIRED_ATTRIBUTES object, it MUST send a
PathErr message with an error code of 'Routing Problem (24)' and an
error value of 'TE link label usage failure (TBD3)'.
Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES Explicit Delegation: The presence of this flag in the HOP_ATTRIBUTES
subobject [RFC7570] of an Explicit Route Object (ERO) in the Path subobject [RFC7570] of an Explicit Route Object (ERO) in the Path
message indicates that the hop identified by the preceding IPv4 or message indicates that the hop identified by the preceding IPv4 or
IPv6 or Unnumbered Interface ID subobject has been picked as an IPv6 or Unnumbered Interface ID subobject has been picked as an
explicit delegation hop. The HOP_ATTRIBUTES subobject carrying this explicit delegation hop. The HOP_ATTRIBUTES subobject carrying this
flag MUST have the R (Required) bit set. This flag MUST be set in flag MUST have the R (Required) bit set. This flag MUST be set in
the HOP_ATTRIBUTES subobject of an ERO object in the Path message the HOP_ATTRIBUTES subobject of an ERO object in the Path message
only if the use and recording of TE link labels is requested/mandated only if the use and recording of TE link labels is requested/mandated
for this LSP. If the hop is not able to comply with this mandate, it for this LSP. If the hop is not able to comply with this mandate, it
skipping to change at page 17, line 5 skipping to change at page 17, line 12
Figure 8: The ETLD Attributes TLV Figure 8: The ETLD Attributes TLV
The presence of this TLV in the HOP_ATTRIBUTES subobject of an RRO The presence of this TLV in the HOP_ATTRIBUTES subobject of an RRO
object in the Path message indicates that the hop identified by the object in the Path message indicates that the hop identified by the
preceding IPv4 or IPv6 or Unnumbered Interface ID subobject supports preceding IPv4 or IPv6 or Unnumbered Interface ID subobject supports
automatic delegation. This attribute MUST be used only if the use automatic delegation. This attribute MUST be used only if the use
and recording of TE link labels is requested/mandated and automatic and recording of TE link labels is requested/mandated and automatic
delegation is requested for the LSP. delegation is requested for the LSP.
The ETLD field specifies the maximum number of transport labels that The ETLD field specifies the effective number of transport labels
this hop can potentially send to its downstream hop. It MUST be set that this hop (in relation to its position in the path) can
to a non-zero value. potentially send to its downstream hop. It MUST be set to a non-zero
value.
The Reserved field is for future specification. It SHOULD be set to The Reserved field is for future specification. It SHOULD be set to
zero on transmission and MUST be ignored on receipt to ensure future zero on transmission and MUST be ignored on receipt to ensure future
compatibility. compatibility.
10. OAM Considerations 10. OAM Considerations
MPLS LSP ping and traceroute [RFC8029] are applicable for Segment MPLS LSP ping and traceroute [RFC8029] are applicable for Segment
Routed RSVP-TE tunnels. The existing procedures allow for the label Routed RSVP-TE tunnels. The existing procedures allow for the label
stack imposed at a delegation hop to be reported back in the Label stack imposed at a delegation hop to be reported back in the Label
 End of changes. 16 change blocks. 
53 lines changed or deleted 72 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/