rfc8390.txt   test8390.v2v3.txt 
Internet Engineering Task Force (IETF) Z. Ali, Ed. Internet Engineering Task Force Z. Ali, Ed.
Request for Comments: 8390 Cisco Systems Request for Comments: 8390 Cisco Systems
Updates: 4874 G. Swallow, Ed. Updates: 4874 G. Swallow, Ed.
Category: Standards Track SETC Category: Standards Track SETC
ISSN: 2070-1721 F. Zhang, Ed. ISSN: 2070-1721 F. Zhang, Ed.
Huawei Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
July 2018 July 2018
RSVP-TE Path Diversity Using Exclude Route RSVP-TE Path Diversity Using Exclude Route
skipping to change at page 2, line 16 skipping to change at line 48
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at https://www.rfc-
https://www.rfc-editor.org/info/rfc8390. editor.org/info/rfc8390.
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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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
1.1. Conventions Used in This Document . . . . . . . . . . . . 6 1.1. Conventions Used in This Document
1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 6 1.2. Terms and Abbreviations
1.3. Client-Initiated Identifier . . . . . . . . . . . . . . . 7 1.3. Client-Initiated Identifier
1.4. PCE-Allocated Identifier . . . . . . . . . . . . . . . . 7 1.4. PCE-Allocated Identifier
1.5. Network-Assigned Identifier . . . . . . . . . . . . . . . 9 1.5. Network-Assigned Identifier
2. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . 10 2. RSVP-TE Signaling Extensions
2.1. Diversity XRO Subobject . . . . . . . . . . . . . . . . . 10 2.1. Diversity XRO Subobject
2.2. Diversity EXRS Subobject . . . . . . . . . . . . . . . . 16 2.2. Diversity EXRS Subobject
2.3. Processing Rules for the Diversity XRO and EXRS 2.3. Processing Rules for the Diversity XRO and EXRS
Subobjects . . . . . . . . . . . . . . . . . . . . . . . 16 Subobjects
3. Security Considerations . . . . . . . . . . . . . . . . . . . 20 3. Security Considerations
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. IANA Considerations
4.1. New XRO Subobject Types . . . . . . . . . . . . . . . . . 21 4.1. New XRO Subobject Types
4.2. New EXRS Subobject Types . . . . . . . . . . . . . . . . 21 4.2. New EXRS Subobject Types
4.3. New RSVP Error Sub-codes . . . . . . . . . . . . . . . . 22 4.3. New RSVP Error Sub-codes
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. References
5.1. Normative References . . . . . . . . . . . . . . . . . . 22 5.1. Normative References
5.2. Informative References . . . . . . . . . . . . . . . . . 23 5.2. Informative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgements
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses
1. Introduction 1. Introduction
Path diversity for multiple connections is a well-known operational Path diversity for multiple connections is a well-known operational
requirement. Diversity constraints ensure that Label Switched Paths requirement. Diversity constraints ensure that Label Switched Paths
(LSPs) can be established without sharing network resources, thus (LSPs) can be established without sharing network resources, thus
greatly reducing the probability of simultaneous connection failures. greatly reducing the probability of simultaneous connection failures.
The source node can compute diverse paths for LSPs when it has full The source node can compute diverse paths for LSPs when it has full
knowledge of the network topology and is permitted to signal an knowledge of the network topology and is permitted to signal an
Explicit Route Object (ERO). However, there are scenarios where Explicit Route Object (ERO). However, there are scenarios where
different nodes perform path computations, and therefore there is a different nodes perform path computations, and therefore there is a
need for relevant diversity constraints to be signaled to those need for relevant diversity constraints to be signaled to those
nodes. These include (but are not limited to): nodes. These include (but are not limited to):
o LSPs with loose hops in the Explicit Route Object, e.g., inter- * LSPs with loose hops in the Explicit Route Object, e.g., inter-
domain LSPs; and domain LSPs; and
o Generalized Multiprotocol Label Switching (GMPLS) User-Network * Generalized Multiprotocol Label Switching (GMPLS) User-Network
Interface (UNI), where the core node may perform path computation Interface (UNI), where the core node may perform path computation
[RFC4208]. [RFC4208].
[RFC4874] introduced a means of specifying nodes and resources to be [RFC4874] introduced a means of specifying nodes and resources to be
excluded from a route using the eXclude Route Object (XRO) and excluded from a route using the eXclude Route Object (XRO) and
Explicit Exclusion Route Subobject (EXRS). It facilitates the Explicit Exclusion Route Subobject (EXRS). It facilitates the
calculation of diverse paths for LSPs based on known properties of calculation of diverse paths for LSPs based on known properties of
those paths including addresses of links and nodes traversed and those paths including addresses of links and nodes traversed and
Shared Risk Link Groups (SRLGs) of traversed links. Employing these Shared Risk Link Groups (SRLGs) of traversed links. Employing these
mechanisms requires that the source node that initiates signaling mechanisms requires that the source node that initiates signaling
knows the relevant properties of the path(s) from which diversity is knows the relevant properties of the path(s) from which diversity is
desired. However, there are circumstances under which this may not desired. However, there are circumstances under which this may not
be possible or desirable, including (but not limited to): be possible or desirable, including (but not limited to):
o Exclusion of a path that does not originate, terminate, or * Exclusion of a path that does not originate, terminate, or
traverse the source node of the diverse LSP, in which case the traverse the source node of the diverse LSP, in which case the
addresses of links and SRLGs of the path from which diversity is addresses of links and SRLGs of the path from which diversity is
required are unknown to the source node. required are unknown to the source node.
o Exclusion of a path that is known to the source node of the * Exclusion of a path that is known to the source node of the
diverse LSP for which the node has incomplete or no path diverse LSP for which the node has incomplete or no path
information, e.g., due to operator policy. In this case, the information, e.g., due to operator policy. In this case, the
source node is aware of the existence of the reference path, but source node is aware of the existence of the reference path, but
the information required to construct an XRO object to guarantee the information required to construct an XRO object to guarantee
diversity from the reference path is not fully known. Inter- diversity from the reference path is not fully known. Inter-
domain and GMPLS overlay networks can impose such restrictions. domain and GMPLS overlay networks can impose such restrictions.
This is illustrated in Figure 1, where the overlay reference model This is illustrated in Figure 1, where the overlay reference model
from [RFC4208] is shown. from [RFC4208] is shown.
skipping to change at page 11, line 25 skipping to change at line 442
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) | | IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier Source Address (cont.) | | IPv6 Diversity Identifier Source Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value | | Diversity Identifier Value |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: L: The L flag is used in the same way as for the XRO subobjects
The L flag is used in the same way as for the XRO subobjects
defined in [RFC4874], that is: defined in [RFC4874], that is:
0 indicates that the diversity constraints MUST be satisfied, and 0 indicates that the diversity constraints MUST be satisfied, and
1 indicates that the diversity constraints SHOULD be satisfied. 1 indicates that the diversity constraints SHOULD be satisfied.
XRO Type: XRO Type: The value is set to 38 for the IPv4 Diversity XRO
The value is set to 38 for the IPv4 Diversity XRO subobject. The subobject. The value is set to 39 for the IPv6 Diversity XRO
value is set to 39 for the IPv6 Diversity XRO subobject. subobject.
Length: Length: Per [RFC4874], the Length contains the total length of the
Per [RFC4874], the Length contains the total length of the
IPv4/IPv6 subobject in bytes, including the XRO Type and Length IPv4/IPv6 subobject in bytes, including the XRO Type and Length
fields. The Length is variable, depending on the Diversity fields. The Length is variable, depending on the Diversity
Identifier Value. Identifier Value.
Diversity Identifier Type (DI Type): Diversity Identifier Type (DI Type): Diversity Identifier Type (DI
Diversity Identifier Type (DI Type) indicates the way the Type) indicates the way the reference LSP(s) or route(s) with
reference LSP(s) or route(s) with which diversity is required is which diversity is required is identified in the IPv4/IPv6
identified in the IPv4/IPv6 Diversity subobjects. The following Diversity subobjects. The following three DI Type values are
three DI Type values are defined in this document: defined in this document:
DI Type value Definition DI Type value Definition
------------- -------------------------------- ------------- --------------------------------
1 Client-Initiated Identifier 1 Client-Initiated Identifier
2 PCE-Allocated Identifier 2 PCE-Allocated Identifier
3 Network-Assigned Identifier 3 Network-Assigned Identifier
Attribute Flags (A-Flags): Attribute Flags (A-Flags): The Attribute Flags (A-Flags) are used to
The Attribute Flags (A-Flags) are used to communicate desirable communicate desirable attributes of the LSP being signaled in the
attributes of the LSP being signaled in the IPv4/IPv6 Diversity IPv4/IPv6 Diversity subobjects. Each flag acts independently.
subobjects. Each flag acts independently. Any combination of Any combination of flags is permitted.
flags is permitted.
0x01 = Destination node exception 0x01 = Destination node exception Indicates that the exclusion
Indicates that the exclusion does not apply to the destination does not apply to the destination node of the LSP being
node of the LSP being signaled. signaled.
0x02 = Processing node exception 0x02 = Processing node exception Indicates that the exclusion
Indicates that the exclusion does not apply to the node(s) does not apply to the node(s) performing ERO expansion for the
performing ERO expansion for the LSP being signaled. An LSP being signaled. An ingress UNI-N node is an example of
ingress UNI-N node is an example of such a node. such a node.
0x04 = Penultimate node exception 0x04 = Penultimate node exception Indicates that the penultimate
Indicates that the penultimate node of the LSP being signaled node of the LSP being signaled MAY be shared with the excluded
MAY be shared with the excluded path even when this violates path even when this violates the exclusion flags. This flag is
the exclusion flags. This flag is useful, for example, when an useful, for example, when an EN is not dual homed (like EN4 in
EN is not dual homed (like EN4 in Figure 1, where all LSPs have Figure 1, where all LSPs have to go through CN5).
to go through CN5).
The "Penultimate node exception" flag is typically set when the The "Penultimate node exception" flag is typically set when the
destination node is single homed (e.g., EN1 or EN4 in destination node is single homed (e.g., EN1 or EN4 in
Figure 2). In such a case, LSP diversity can only be Figure 2). In such a case, LSP diversity can only be
accomplished inside the core network up to the egress node and accomplished inside the core network up to the egress node and
the penultimate hop must be the same for the LSPs. the penultimate hop must be the same for the LSPs.
0x08 = LSP ID to be ignored 0x08 = LSP ID to be ignored This flag is used to indicate tunnel-
This flag is used to indicate tunnel-level exclusion. level exclusion. Specifically, this flag is used to indicate
Specifically, this flag is used to indicate that if the that if the diversity identifier contains an LSP ID field, then
diversity identifier contains an LSP ID field, then the LSP ID the LSP ID is to be ignored, and the exclusion applies to any
is to be ignored, and the exclusion applies to any LSP matching LSP matching the rest of the diversity identifier.
the rest of the diversity identifier.
Exclusion Flags (E-Flags): Exclusion Flags (E-Flags): The Exclusion Flags are used to
The Exclusion Flags are used to communicate the desired type(s) of communicate the desired type(s) of exclusion requested in the
exclusion requested in the IPv4/IPv6 Diversity subobjects. The IPv4/IPv6 Diversity subobjects. The following flags are defined.
following flags are defined. Any combination of these flags is Any combination of these flags is permitted. Please note that the
permitted. Please note that the exclusion specified by these exclusion specified by these flags may be modified by the value of
flags may be modified by the value of the A-Flags. For example, the A-Flags. For example, the node exclusion flag is ignored for
the node exclusion flag is ignored for the penultimate node if the the penultimate node if the "Penultimate node exception" flag of
"Penultimate node exception" flag of the A-Flags is set. the A-Flags is set.
0x01 = SRLG exclusion 0x01 = SRLG exclusion Indicates that the path of the LSP being
Indicates that the path of the LSP being signaled is requested signaled is requested to be SRLG disjoint with respect to the
to be SRLG disjoint with respect to the excluded path specified excluded path specified by the IPv4/IPv6 Diversity XRO
by the IPv4/IPv6 Diversity XRO subobject. subobject.
0x02 = Node exclusion 0x02 = Node exclusion Indicates that the path of the LSP being
Indicates that the path of the LSP being signaled is requested signaled is requested to be "node diverse" from the excluded
to be "node diverse" from the excluded path specified by the path specified by the IPv4/IPv6 Diversity XRO subobject.
IPv4/IPv6 Diversity XRO subobject.
0x04 = Link exclusion 0x04 = Link exclusion Indicates that the path of the LSP being
Indicates that the path of the LSP being signaled is requested signaled is requested to be "link diverse" from the path
to be "link diverse" from the path specified by the IPv4/IPv6 specified by the IPv4/IPv6 Diversity XRO subobject.
Diversity XRO subobject.
0x08 = Reserved 0x08 = Reserved This flag is reserved. It MUST be set to zero on
This flag is reserved. It MUST be set to zero on transmission transmission and MUST be ignored on receipt for both IPv4/IPv6
and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO Diversity XRO subobjects.
subobjects.
Resvd: Resvd: This field is reserved. It MUST be set to zero on
This field is reserved. It MUST be set to zero on transmission transmission and MUST be ignored on receipt for both IPv4/IPv6
and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO Diversity XRO subobjects.
subobjects.
IPv4/IPv6 Diversity Identifier Source Address: IPv4/IPv6 Diversity Identifier Source
This field MUST be set to the IPv4/IPv6 address of the node that Address: This field MUST be set to the
assigns the diversity identifier. Depending on the Diversity IPv4/IPv6 address of the node that assigns the diversity
Identifier Type, the diversity identifier source may be a client identifier. Depending on the Diversity Identifier Type, the
node, PCE entity, or network node. Specifically: diversity identifier source may be a client node, PCE entity, or
network node. Specifically:
* When the Diversity Identifier Type is set to the "Client- * When the Diversity Identifier Type is set to the "Client-
Initiated Identifier", the value MUST be set to IPv4/IPv6 Initiated Identifier", the value MUST be set to IPv4/IPv6
tunnel sender address of the reference LSP against which tunnel sender address of the reference LSP against which
diversity is desired. The IPv4/IPv6 tunnel sender address is diversity is desired. The IPv4/IPv6 tunnel sender address is
as defined in [RFC3209]. as defined in [RFC3209].
* When the Diversity Identifier Type is set to "PCE-Allocated * When the Diversity Identifier Type is set to "PCE-Allocated
Identifier", the value MUST be set to the IPv4/IPv6 address of Identifier", the value MUST be set to the IPv4/IPv6 address of
the node that assigned the Path Key identifier and that can the node that assigned the Path Key identifier and that can
skipping to change at page 17, line 44 skipping to change at line 710
performed. performed.
While processing the EXRS object, if a loose hop expansion results in While processing the EXRS object, if a loose hop expansion results in
the creation of another loose hop in the outgoing ERO, the processing the creation of another loose hop in the outgoing ERO, the processing
node MAY include the EXRS in the newly created loose hop for further node MAY include the EXRS in the newly created loose hop for further
processing by downstream nodes. processing by downstream nodes.
The A-Flags affect the processing of the Diversity XRO/EXRS subobject The A-Flags affect the processing of the Diversity XRO/EXRS subobject
as follows: as follows:
o When the "Processing node exception" flag is set, the exclusion * When the "Processing node exception" flag is set, the exclusion
MUST be ignored for the node processing the XRO or EXRS subobject. MUST be ignored for the node processing the XRO or EXRS subobject.
o When the "Destination node exception" flag is set, the exclusion * When the "Destination node exception" flag is set, the exclusion
MUST be ignored for the destination node in processing the XRO MUST be ignored for the destination node in processing the XRO
subobject. The destination node exception for the EXRS subobject subobject. The destination node exception for the EXRS subobject
applies to the explicit node identified by the ERO subobject that applies to the explicit node identified by the ERO subobject that
identifies the next abstract node. When the "Destination node identifies the next abstract node. When the "Destination node
exception" flag is set in the EXRS subobject, exclusion MUST be exception" flag is set in the EXRS subobject, exclusion MUST be
ignored for said node (i.e., the next abstract node). ignored for said node (i.e., the next abstract node).
o When the "Penultimate node exception" flag is set in the XRO * When the "Penultimate node exception" flag is set in the XRO
subobject, the exclusion MUST be ignored for the penultimate node subobject, the exclusion MUST be ignored for the penultimate node
on the path of the LSP being established. on the path of the LSP being established.
The penultimate node exception for the EXRS subobject applies to The penultimate node exception for the EXRS subobject applies to
the node before the explicit node identified by the ERO subobject the node before the explicit node identified by the ERO subobject
that identifies the next abstract node. When the "Penultimate that identifies the next abstract node. When the "Penultimate
node exception" flag is set in the EXRS subobject, the exclusion node exception" flag is set in the EXRS subobject, the exclusion
MUST be ignored for said node (i.e., the node before the next MUST be ignored for said node (i.e., the node before the next
abstract node). abstract node).
If the L-flag of the Diversity XRO subobject or Diversity EXRS If the L-flag of the Diversity XRO subobject or Diversity EXRS
subobject is not set, the processing node proceeds as follows. subobject is not set, the processing node proceeds as follows.
o If the Diversity Identifier Type is set to "Client-Initiated * If the Diversity Identifier Type is set to "Client-Initiated
Identifier", the processing node MUST ensure that the path Identifier", the processing node MUST ensure that the path
calculated/expanded for the signaled LSP is diverse from the route calculated/expanded for the signaled LSP is diverse from the route
taken by the LSP identified in the Diversity Identifier Value taken by the LSP identified in the Diversity Identifier Value
field. field.
o If the Diversity Identifier Type is set to "PCE-Allocated * If the Diversity Identifier Type is set to "PCE-Allocated
Identifier", the processing node MUST ensure that any path Identifier", the processing node MUST ensure that any path
calculated for the signaled LSP is diverse from the route calculated for the signaled LSP is diverse from the route
identified by the Path Key. The processing node MAY use the PCE identified by the Path Key. The processing node MAY use the PCE
identified by the Diversity Identifier Source Address in the identified by the Diversity Identifier Source Address in the
subobject for route computation. The processing node MAY use the subobject for route computation. The processing node MAY use the
Path Key resolution mechanisms described in [RFC5553]. Path Key resolution mechanisms described in [RFC5553].
o If the Diversity Identifier Type is set to "Network-Assigned * If the Diversity Identifier Type is set to "Network-Assigned
Identifier", the processing node MUST ensure that the path Identifier", the processing node MUST ensure that the path
calculated for the signaled LSP is diverse with respect to the calculated for the signaled LSP is diverse with respect to the
values associated with the PAS Identifier and Diversity Identifier values associated with the PAS Identifier and Diversity Identifier
Source Address fields. Source Address fields.
o Regardless of whether the path computation is performed locally or * Regardless of whether the path computation is performed locally or
at a remote node (e.g., PCE), the processing node MUST ensure that at a remote node (e.g., PCE), the processing node MUST ensure that
any path calculated for the signaled LSP is diverse from the any path calculated for the signaled LSP is diverse from the
requested Exclusion Flags. requested Exclusion Flags.
o If the excluded path referenced in the XRO subobject is unknown to * If the excluded path referenced in the XRO subobject is unknown to
the processing node, the processing node SHOULD ignore the the processing node, the processing node SHOULD ignore the
Diversity XRO subobject and SHOULD proceed with the signaling Diversity XRO subobject and SHOULD proceed with the signaling
request. After sending the Resv for the signaled LSP, the request. After sending the Resv for the signaled LSP, the
processing node MUST return a PathErr with the error code "Notify processing node MUST return a PathErr with the error code "Notify
Error" (25) and error sub-code "Route of XRO LSP identifier Error" (25) and error sub-code "Route of XRO LSP identifier
unknown" (14) for the signaled LSP. unknown" (14) for the signaled LSP.
o If the processing node fails to find a path that meets the * If the processing node fails to find a path that meets the
requested constraint, the processing node MUST return a PathErr requested constraint, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). "Route blocked by Exclude Route" (67).
If the L-flag of the Diversity XRO subobject or Diversity EXRS If the L-flag of the Diversity XRO subobject or Diversity EXRS
subobject is set, the processing node proceeds as follows: subobject is set, the processing node proceeds as follows:
o If the Diversity Identifier Type is set to "Client-Initiated * If the Diversity Identifier Type is set to "Client-Initiated
Identifier", the processing node SHOULD ensure that the path Identifier", the processing node SHOULD ensure that the path
calculated/expended for the signaled LSP is diverse from the route calculated/expended for the signaled LSP is diverse from the route
taken by the LSP identified in the Diversity Identifier Value taken by the LSP identified in the Diversity Identifier Value
field. field.
o If the Diversity Identifier Type is set to "PCE-Allocated * If the Diversity Identifier Type is set to "PCE-Allocated
Identifier", the processing node SHOULD ensure that the path Identifier", the processing node SHOULD ensure that the path
calculated for the signaled LSP is diverse from the route calculated for the signaled LSP is diverse from the route
identified by the Path Key. identified by the Path Key.
o If the Diversity Identifier Type is set to "Network-Assigned * If the Diversity Identifier Type is set to "Network-Assigned
Identifier", the processing node SHOULD ensure that the path Identifier", the processing node SHOULD ensure that the path
calculated for the signaled LSP is diverse with respect to the calculated for the signaled LSP is diverse with respect to the
values associated with the PAS Identifier and Diversity Identifier values associated with the PAS Identifier and Diversity Identifier
Source Address fields. Source Address fields.
o If the processing node fails to find a path that meets the * If the processing node fails to find a path that meets the
requested constraint, it SHOULD proceed with signaling using a requested constraint, it SHOULD proceed with signaling using a
suitable path that meets the constraint as far as possible. After suitable path that meets the constraint as far as possible. After
sending the Resv for the signaled LSP, it MUST return a PathErr sending the Resv for the signaled LSP, it MUST return a PathErr
message with error code "Notify Error" (25) and error sub-code message with error code "Notify Error" (25) and error sub-code
"Failed to satisfy Exclude Route" (15) to the source node. "Failed to satisfy Exclude Route" (15) to the source node.
If, subsequent to the initial signaling of a diverse LSP, an excluded If, subsequent to the initial signaling of a diverse LSP, an excluded
path referenced in the XRO subobject becomes known to the processing path referenced in the XRO subobject becomes known to the processing
node or a change in the excluded path becomes known to the processing node or a change in the excluded path becomes known to the processing
node, the processing node MUST re-evaluate the exclusion and node, the processing node MUST re-evaluate the exclusion and
diversity constraints requested by the diverse LSP to determine diversity constraints requested by the diverse LSP to determine
whether they are still satisfied. whether they are still satisfied.
o In the case where the L-flag was not set in the initial setup * In the case where the L-flag was not set in the initial setup
message, the exclusion and diversity constraints were satisfied at message, the exclusion and diversity constraints were satisfied at
the time of the initial setup. If the processing node re- the time of the initial setup. If the processing node re-
evaluating the exclusion and diversity constraints for a diverse evaluating the exclusion and diversity constraints for a diverse
LSP detects that the exclusion and diversity constraints are no LSP detects that the exclusion and diversity constraints are no
longer met, it MUST send a PathErr message for the diverse LSP longer met, it MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The Path_State_Removed "Route blocked by Exclude Route" (67). The Path_State_Removed
(PSR) flag [RFC3473] MUST NOT be set. A source node receiving a (PSR) flag [RFC3473] MUST NOT be set. A source node receiving a
PathErr message with this error code and sub-code combination PathErr message with this error code and sub-code combination
SHOULD take appropriate actions and move the diverse LSP to a new SHOULD take appropriate actions and move the diverse LSP to a new
path that meets the original constraints. path that meets the original constraints.
o In the case where the L-flag was set in the initial setup message, * In the case where the L-flag was set in the initial setup message,
the exclusion and diversity constraints may or may not be the exclusion and diversity constraints may or may not be
satisfied at any given time. If the exclusion constraints for a satisfied at any given time. If the exclusion constraints for a
diverse LSP were satisfied before, and if the processing node re- diverse LSP were satisfied before, and if the processing node re-
evaluating the exclusion and diversity constraints for a diverse evaluating the exclusion and diversity constraints for a diverse
LSP detects that exclusion and diversity constraints are no longer LSP detects that exclusion and diversity constraints are no longer
met, it MUST send a PathErr message for the diverse LSP with the met, it MUST send a PathErr message for the diverse LSP with the
error code "Notify Error" (25) and error sub-code "Failed to error code "Notify Error" (25) and error sub-code "Failed to
satisfy Exclude Route" (15). The PSR flag MUST NOT be set. The satisfy Exclude Route" (15). The PSR flag MUST NOT be set. The
source node MAY take no consequent action and keep the LSP along source node MAY take no consequent action and keep the LSP along
the path that does not meet the original constraints. Similarly, the path that does not meet the original constraints. Similarly,
skipping to change at page 21, line 23 skipping to change at line 877
4.1. New XRO Subobject Types 4.1. New XRO Subobject Types
In the IANA registry for RSVP parameters, under "Class Names, Class In the IANA registry for RSVP parameters, under "Class Names, Class
Numbers, and Class Types", this document defines two new subobjects Numbers, and Class Types", this document defines two new subobjects
for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or for the EXCLUDE_ROUTE object [RFC4874], C-Type 1 (see "Class Types or
C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/ C-Types - 232 EXCLUDE_ROUTE" on <https://www.iana.org/assignments/
rsvp-parameters>). rsvp-parameters>).
+----------------+-------+ +----------------+-------+
| Description | Value | | Description | Value |
+----------------+-------+ +================+=======+
| IPv4 Diversity | 38 | | IPv4 Diversity | 38 |
+----------------+-------+
| IPv6 Diversity | 39 | | IPv6 Diversity | 39 |
+----------------+-------+ +----------------+-------+
Table 1
4.2. New EXRS Subobject Types 4.2. New EXRS Subobject Types
The Diversity XRO subobjects are also defined as new EXRS subobjects The Diversity XRO subobjects are also defined as new EXRS subobjects
(see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on (see "Class Types or C-Types - 20 EXPLICIT_ROUTE" on
<https://www.iana.org/assignments/rsvp-parameters>). The same <https://www.iana.org/assignments/rsvp-parameters>). The same
numeric values have been assigned: numeric values have been assigned:
+----------------+-------+ +----------------+-------+
| Description | Value | | Description | Value |
+----------------+-------+ +================+=======+
| IPv4 Diversity | 38 | | IPv4 Diversity | 38 |
+----------------+-------+
| IPv6 Diversity | 39 | | IPv6 Diversity | 39 |
+----------------+-------+ +----------------+-------+
Table 2
4.3. New RSVP Error Sub-codes 4.3. New RSVP Error Sub-codes
In the IANA registry for RSVP parameters, under "Error Codes and In the IANA registry for RSVP parameters, under "Error Codes and
Globally Defined Error Value Sub-Codes", for Error Code "Routing Globally Defined Error Value Sub-Codes", for Error Code "Routing
Problem" (24) (see [RFC3209]), the following sub-codes are defined Problem" (24) (see [RFC3209]), the following sub-codes are defined
(see "Sub-Codes - 24 Routing Problem" on (see "Sub-Codes - 24 Routing Problem" on
<https://www.iana.org/assignments/rsvp-parameters>). <https://www.iana.org/assignments/rsvp-parameters>).
+-------+---------------------------------------+-----------+ +-------+---------------------------------------+-----------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------------------+-----------+ +=======+=======================================+===========+
| 36 | Unsupported Diversity Identifier Type | RFC 8390 | | 36 | Unsupported Diversity Identifier Type | RFC 8390 |
+-------+---------------------------------------+-----------+ +-------+---------------------------------------+-----------+
Table 3
For Error Code "Notify Error" (25) (see [RFC3209]), the following For Error Code "Notify Error" (25) (see [RFC3209]), the following
sub-codes are defined (see "Sub-Codes - 25 Notify Error" on sub-codes are defined (see "Sub-Codes - 25 Notify Error" on
<https://www.iana.org/assignments/rsvp-parameters>). <https://www.iana.org/assignments/rsvp-parameters>).
+-------+-------------------------------------+-----------+ +-------+-------------------------------------+-----------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------------+-----------+ +=======+=====================================+===========+
| 14 | Route of XRO LSP identifier unknown | RFC 8390 | | 14 | Route of XRO LSP identifier unknown | RFC 8390 |
+-------+-------------------------------------+-----------+
| 15 | Failed to satisfy Exclude Route | RFC 8390 | | 15 | Failed to satisfy Exclude Route | RFC 8390 |
+-------+-------------------------------------+-----------+
| 16 | Compliant path exists | RFC 8390 | | 16 | Compliant path exists | RFC 8390 |
+-------+-------------------------------------+-----------+ +-------+-------------------------------------+-----------+
Table 4
5. References 5. References
5.1. Normative References 5.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, DOI 10.17487/RFC2747, January Authentication", RFC 2747, DOI 10.17487/RFC2747, January
2000, <https://www.rfc-editor.org/info/rfc2747>. 2000, <https://www.rfc-editor.org/info/rfc2747>.
[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>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol- Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3473>. editor.org/info/rfc3473>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>. <https://www.rfc-editor.org/info/rfc4202>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <https://www.rfc-editor.org/info/rfc4874>. April 2007, <https://www.rfc-editor.org/info/rfc4874>.
skipping to change at page 24, line 8 skipping to change at line 1004
<https://www.rfc-editor.org/info/rfc4208>. <https://www.rfc-editor.org/info/rfc4208>.
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode",
RFC 5251, DOI 10.17487/RFC5251, July 2008, RFC 5251, DOI 10.17487/RFC5251, July 2008,
<https://www.rfc-editor.org/info/rfc5251>. <https://www.rfc-editor.org/info/rfc5251>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain Path "Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Path-Key-Based Mechanism", RFC 5520, Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5520>. editor.org/info/rfc5520>.
[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>.
[RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C., [RFC8001] Zhang, F., Ed., Gonzalez de Dios, O., Ed., Margaria, C.,
Hartley, M., and Z. Ali, "RSVP-TE Extensions for Hartley, M., and Z. Ali, "RSVP-TE Extensions for
Collecting Shared Risk Link Group (SRLG) Information", Collecting Shared Risk Link Group (SRLG) Information",
RFC 8001, DOI 10.17487/RFC8001, January 2017, RFC 8001, DOI 10.17487/RFC8001, January 2017,
<https://www.rfc-editor.org/info/rfc8001>. <https://www.rfc-editor.org/info/rfc8001>.
skipping to change at page 26, line 9 skipping to change at line 1092
Email: tochio@jp.fujitsu.com Email: tochio@jp.fujitsu.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Authors' Addresses Authors' Addresses
Zafar Ali (editor) Zafar Ali (editor)
Cisco Systems. Cisco Systems.
EMail: zali@cisco.com
Email: zali@cisco.com
George Swallow (editor) George Swallow (editor)
Southend Technical Center Southend Technical Center
EMail: swallow.ietf@gmail.com
Email: swallow.ietf@gmail.com
Fatai Zhang (editor) Fatai Zhang (editor)
Huawei Technologies Huawei Technologies
EMail: zhangfatai@huawei.com
Email: zhangfatai@huawei.com
Dieter Beller (editor) Dieter Beller (editor)
Nokia Nokia
EMail: Dieter.Beller@nokia.com
Email: Dieter.Beller@nokia.com
 End of changes. 59 change blocks. 
142 lines changed or deleted 142 lines changed or added

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