draft-ietf-teas-lsp-diversity-08.txt   draft-ietf-teas-lsp-diversity-09.txt 
TEAS Working Group Zafar Ali, Ed. TEAS Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed. Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems Intended status: Standard Track Cisco Systems
Updates RFC4874 F. Zhang, Ed. Updates RFC4874 F. Zhang, Ed.
Expires: January 3, 2018 Huawei Expires: May 17, 2018 Huawei
D. Beller, Ed. D. Beller, Ed.
Nokia Nokia
July 2, 2017 November 13, 2017
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route Diversity using Exclude Route
draft-ietf-teas-lsp-diversity-08.txt draft-ietf-teas-lsp-diversity-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
(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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
Resource ReserVation Protocol-Traffic Engineering provides support Resource ReSerVation Protocol-Traffic Engineering provides support
for the communication of exclusion information during label switched for the communication of exclusion information during label switched
path (LSP) setup. This document specifies two new diversity path (LSP) setup. This document specifies two new diversity
subobjects for the RSVP XRO and EXRS subobjects. Three different subobjects for the RSVP eXclude Route Object (XRO) and the Explicit
mechanisms are supported how LSP diversity can be accomplished in Exclusion Route Subobject (EXRS). Three different mechanisms are
the provider or core network: the signaled diversity type, indicates defined to accomplish LSP diversity in the provider or core network:
whether diversity is based on client, path computation engine (PCE), the signaled diversity type indicates whether diversity is based on
or network assigned identifiers. client, path computation engine (PCE), or network assigned
identifiers.
The solution described in this document is based on the assumption The solution described in this document is based on the assumption
that LSPs are requested sequentially, i.e., the time period between that LSPs are requested sequentially, i.e., the time period between
the LSP setup requests for the two LSPs may be longer (days, weeks, the LSP setup requests for the two LSPs may be relatively long (in
months). Re-routing the first LSP that may have existed for a longer the order of days, weeks, months). Re-routing the LSP that was
period of time is not considered. established first and may have existed for some time is not
considered.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1. Client-Initiated Identifier..............................5 1.1. Client-Initiated Identifier..............................5
1.2. PCE-allocated Identifier.................................6 1.2. PCE-allocated Identifier.................................6
1.3. Network-Assigned Identifier..............................7 1.3. Network-Assigned Identifier..............................7
2. RSVP-TE signaling extensions..................................9 2. RSVP-TE signaling extensions..................................9
2.1. Diversity XRO Subobject..................................9 2.1. Diversity XRO Subobject..................................9
2.2. Diversity EXRS Subobject................................15 2.2. Diversity EXRS Subobject................................16
2.3. Processing rules for the Diversity XRO and EXRS 2.3. Processing rules for the Diversity XRO and EXRS
subobjects..............................................16 subobjects..............................................16
3. Security Considerations......................................20 3. Security Considerations......................................20
4. IANA Considerations..........................................20 4. IANA Considerations..........................................20
4.1. New XRO subobject types.................................20 4.1. New XRO subobject types.................................20
4.2. New EXRS subobject types................................21 4.2. New EXRS subobject types................................21
4.3. New RSVP error sub-codes................................21 4.3. New RSVP error sub-codes................................21
5. Acknowledgements.............................................22 5. Acknowledgements.............................................22
6. References...................................................22 6. References...................................................22
6.1. Normative References....................................22 6.1. Normative References....................................22
skipping to change at page 6, line 19 skipping to change at page 6, line 19
network, the core network SHOULD implement Crankback Signaling network, the core network SHOULD implement Crankback Signaling
[RFC4920]. Note that crankback signaling is known to lead to [RFC4920]. Note that crankback signaling is known to lead to
slower setup times and sub-optimal paths under some circumstances slower setup times and sub-optimal paths under some circumstances
as described by [RFC4920]. as described by [RFC4920].
1.2. PCE-allocated Identifier 1.2. PCE-allocated Identifier
In scenarios where a PCE is deployed and used to perform path In scenarios where a PCE is deployed and used to perform path
computation, the core edge node (e.g., node CN1 in Figure 1) computation, the core edge node (e.g., node CN1 in Figure 1)
could consult a PCE to allocate identifiers, which are used to could consult a PCE to allocate identifiers, which are used to
signal path diversity constraints. In other scenarios a PCE is signal path diversity constraints. In other scenarios, a PCE is
deployed at network node(s) or a PCE is part of a Network deployed at network node(s) or a PCE is part of a Network
Management System (NMS). In all these cases, the Path Key as Management System (NMS). In all these cases, the Path Key as
defined in [RFC5520] can be used in RSVP signaling as the defined in [RFC5520] can be used in RSVP signaling as the
identifier to ensure diversity. identifier to ensure diversity.
An example of specifying LSP diversity using a Path Key is shown An example of specifying LSP diversity using a Path Key is shown
in Figure 2, where a simple network with two domains is shown. It in Figure 2, where a simple network with two domains is shown. It
is desired to set up a pair of path-disjoint LSPs from the source is desired to set up a pair of path-disjoint LSPs from the source
in Domain 1 to the destination in Domain 2, but the domains keep in Domain 1 to the destination in Domain 2, but the domains keep
strict confidentiality about all path and topology information. strict confidentiality about all path and topology information.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
XRO Type XRO Type
The value is set to TBA1 for the IPv4 diversity XRO The value is set to TBA1 for the IPv4 diversity XRO
subobject (value to be assigned by IANA). Similarly, the subobject (value to be assigned by IANA). Similarly, the
value is set to TBA2 for the IPv6 diversity XRO subobject value is set to TBA2 for the IPv6 diversity XRO subobject
(value to be assigned by IANA). (value to be assigned by IANA).
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 Type and IPv4/IPv6 subobject in bytes, including the Type and
Length fields. The Length is variable, depending on the Length fields. The Length is variable, depending on the
diversity identifier value. diversity identifier value.
Diversity Identifier Type (DI Type) Diversity Identifier Type (DI Type)
Diversity Identifier Type (DI Type) indicates the way the Diversity Identifier Type (DI Type) indicates the way the
reference LSP(s) or route(s) with which diversity is reference LSP(s) or route(s) with which diversity is
required is identified in the IPv4/ IPv6 Diversity required is identified in the IPv4/IPv6 Diversity
subobjects. The following three DI type values are defined subobjects. The following three DI type values are defined
in this document: 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):
skipping to change at page 12, line 5 skipping to change at page 11, line 47
node(s) performing ERO expansion for the LSP being node(s) performing ERO expansion for the LSP being
signaled. An ingress UNI-N node is an example of such a signaled. An ingress UNI-N node is an example of such a
node. node.
0x04 = Penultimate node exception 0x04 = Penultimate node exception
Indicates that the penultimate node of the LSP being Indicates that the penultimate node of the LSP being
signaled MAY be shared with the excluded path even when signaled MAY be shared with the excluded path even when
this violates the exclusion flags. this violates the exclusion flags.
The penultimate node exception flag is typically set
when the destination node is single homed (e.g. EN1 or
EN4 in Figure 1). In such a case, LSP diversity can only
be accomplished inside the core network up to the egress
node and 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 level exclusion. This flag is used to indicate tunnel level exclusion.
Specifically, this flag is used to indicate that if Specifically, this flag is used to indicate that if
diversity identifier contains lsp-id field, the lsp-id diversity identifier contains lsp-id field, the lsp-id
is to be ignored and the exclusion applies to any LSP is to be ignored and the exclusion applies to any LSP
matching the rest of the diversity identifier. matching the rest of the diversity identifier.
Exclusion Flags (E-Flags): Exclusion Flags (E-Flags):
The Exclusion-Flags are used to communicate the desired The Exclusion-Flags are used to communicate the desired
type(s) of exclusion requested in the IPv4/ IPv6 diversity type(s) of exclusion requested in the IPv4/IPv6 diversity
subobjects. The following flags are defined. Any subobjects. The following flags are defined. Any
combination of these flags is permitted. Please note that combination of these flags is permitted. Please note that
the exclusion specified by these flags may be modified by the exclusion specified by these flags may be modified by
the value of the Attribute-flags. For example, node the value of the Attribute-flags. For example, node
exclusion flag is ignored for the "Penultimate node" if exclusion flag is ignored for the "Penultimate node" if
the "Penultimate node exception" flag of the Attribute- the "Penultimate node exception" flag of the Attribute-
flags is set. flags is set.
0x01 = SRLG exclusion 0x01 = SRLG exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be SRLG-diverse from the excluded path requested to be SRLG-diverse from the excluded path
specified by the IPv4/ IPv6 Diversity XRO subobject. specified by the IPv4/IPv6 Diversity XRO subobject.
0x02 = Node exclusion 0x02 = Node exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be node-diverse from the excluded path requested to be node-diverse from the excluded path
specified by the IPv4/ IPv6 Diversity XRO subobject. specified by the IPv4/IPv6 Diversity XRO subobject.
0x04 = Link exclusion 0x04 = Link exclusion
Indicates that the path of the LSP being signaled is Indicates that the path of the LSP being signaled is
requested to be link-diverse from the path specified requested to be link-diverse from the path specified
by the IPv4/ IPv6 Diversity XRO subobject. by the IPv4/IPv6 Diversity XRO subobject.
0x08 = reserved
This flag is reserved. It MUST be set to zero on
transmission, and MUST be ignored on receipt for both
IPv4/IPv6 Diversity XRO 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, and MUST be ignored on receipt for both transmission, and MUST be ignored on receipt for both
IPv4/ IPv6 Diversity XRO subobjects. IPv4/IPv6 Diversity XRO subobjects.
IPv4 / IPv6 Diversity Identifier source address: IPv4 / IPv6 Diversity Identifier source address:
This field MUST be set to the IPv4/ IPv6 address of the This field MUST be set to the IPv4/IPv6 address of the node
node that assigns the diversity identifier. Depending on that assigns the diversity identifier. Depending on the
the diversity identifier type, the diversity identifier diversity identifier type, the diversity identifier source
source may be a client node, PCE entity or network node. may be a client node, PCE entity or network node.
Specifically: Specifically:
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/IPv6
Client Initiated Identifier", the value MUST be set to Client Initiated Identifier", the value MUST be set to
IPv4/ IPv6 tunnel sender address of the reference LSP IPv4/IPv6 tunnel sender address of the reference LSP
against which diversity is desired. IPv4/ IPv6 tunnel against which diversity is desired. IPv4/IPv6 tunnel
sender address is as defined in [RFC3209]. sender address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/IPv6
PCE Allocated Identifier", the value MUST be set to the PCE Allocated Identifier", the value MUST be set to the
IPv4/ IPv6 address of the node that assigned the Path Key IPv4/IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. The computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Identifier Source Address field PCE-ID is carried in the Identifier Source Address field
of the subobject. of the subobject.
o When the diversity identifier type is set to "IPv4/ IPv6 o When the diversity identifier type is set to "IPv4/IPv6
Network Assigned Identifier", the value MUST be set to the Network Assigned Identifier", the value MUST be set to the
IPv4/ IPv6 address of the node allocating the Path IPv4/IPv6 address of the node allocating the Path Affinity
Affinity Set (PAS). Set (PAS).
Diversity Identifier Value: Diversity Identifier Value:
Encoding for this field depends on the diversity identifier Encoding for this field depends on the diversity identifier
type, as defined in the following. type, as defined in the following.
When the diversity identifier type is set to "Client When the diversity identifier type is set to "Client
Initiated Identifier" in IPv4 Diversity XRO subobject, the Initiated Identifier" in the IPv4 Diversity XRO subobject,
diversity identifier value MUST be encoded as follows: the diversity identifier value MUST be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address | | IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 tunnel end point address, Tunnel ID, Extended The IPv4 tunnel end point address, Tunnel ID, Extended
Tunnel ID and LSP ID are as defined in [RFC3209]. Tunnel ID and LSP ID are as defined in [RFC3209].
When the diversity identifier type is set to "IPv6 Client When the diversity identifier type is set to "Client
Initiated Identifier" in IPv6 Diversity XRO subobject, the Initiated Identifier" in the IPv6 Diversity XRO subobject,
diversity identifier value MUST be encoded as follows: the diversity identifier value MUST be encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 34 skipping to change at page 15, line 41
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier | | Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Affinity Set (PAS) identifier field is a 32-bit The Path Affinity Set (PAS) identifier field is a 32-bit
value that is scoped by, i.e., is only meaningful when value that is scoped by, i.e., is only meaningful when
used in combination with, the Diversity Identifier source used in combination with, the Diversity Identifier source
address field. There are no restrictions on how a node address field. There are no restrictions on how a node
selects a PAS identifier value. Section 1.3 defines the selects a PAS identifier value. Section 1.3 defines the
PAS term and provides context on how values may be PAS term and provides context on how values may be
selected. selected.
2.2. Diversity EXRS Subobject 2.2. Diversity EXRS Subobject
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to [RFC4874] defines the EXRS ERO subobject. An EXRS is used to
identify abstract nodes or resources that must not or should not identify abstract nodes or resources that must not or should not
be used on the path between two inclusive abstract nodes or be used on the path between two inclusive abstract nodes or
resources in the explicit route. An EXRS contains one or more resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874]. subobjects of its own, called EXRS subobjects [RFC4874].
skipping to change at page 19, line 26 skipping to change at page 19, line 37
sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be
assigned by IANA) to the source node. assigned by IANA) to the source node.
If, subsequent to the initial signaling of a diverse LSP, an If, subsequent to the initial signaling of a diverse LSP, an
excluded path referenced in the XRO subobject becomes known to excluded path referenced in the XRO subobject becomes known to
the processing node, or a change in the excluded path becomes the processing node, or a change in the excluded path becomes
known to the processing node, the processing node MUST re- known to the processing node, the processing node MUST re-
evaluate the exclusion and diversity constraints requested by the evaluate the exclusion and diversity constraints requested by the
diverse LSP to determine whether they are still satisfied. diverse LSP to determine whether they are still satisfied.
If, subsequent to the initial signaling of a diverse LSP, the - In case the L-flag was not set in the initial setup message,
requested exclusion constraints for the diverse LSP are no longer the exclusion and diversity constraints were satisfied at the
satisfied and an alternative path for the diverse LSP that can time of the initial setup. If the processing node re-evaluating
satisfy those constraints exists, then: the exclusion and diversity constraints for a diverse LSP
detects that the exclusion and diversity constraints are no
- If the L-flag was not set in the original exclusion, the longer met, it MUST send a PathErr message for the diverse LSP
processing node 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
flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a flag (PSR) [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 to migrate to a compliant path. SHOULD take appropriate actions and move the diverse LSP to a
new path that meets the original constraints.
- If the L-flag was set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP
with the error code "Notify Error" (25) and a new error sub-
code TBA6 "Compliant path exists" (value: to be assigned by
IANA). The PSR flag MUST NOT be set. A source node receiving a
PathErr message with this error code and sub-code combination
MAY signal a new LSP to migrate the compliant path.
If, subsequent to the initial signaling of a diverse LSP, the
requested exclusion constraints for the diverse LSP are no longer
satisfied and no alternative path for the diverse LSP that can
satisfy those constraints exists, then:
- If the L-flag was not set in the original exclusion, the
processing node MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The PSR flag MUST be
set.
- If the L-flag was set in the original exclusion, the - In case the L-flag was set in the initial setup message, the
processing node MUST send a PathErr message for the diverse LSP exclusion and diversity constraints may or may not be satisfied
with the error code error code "Notify Error" (25) and error at any given time. If the exclusion constraints for a diverse
sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be LSP were satisfied before and if the processing node re-
assigned by IANA). The PSR flag MUST NOT be set. The source evaluating the exclusion and diversity constraints for a
node MAY take no action and keep the LSP along the non- diverse LSP detects that exclusion and diversity constraints
compliant path. are no longer met, it MUST send a PathErr message for the
diverse LSP with the error code error code "Notify Error" (25)
and error sub-code TBA5 "Failed to satisfy Exclude Route"
(value: to be assigned by IANA). The PSR flag MUST NOT be set.
The source node MAY take no consequent action and keep the LSP
along the path that does not meet the original constraints.
Similarly, if the exclusion constraints for a diverse LSP were
not satisfied before and if the processing node re-evaluating
the exclusion and diversity constraints for a diverse LSP
detects that the exclusion constraints are met, it MUST send a
PathErr message for the diverse LSP with the error code "Notify
Error" (25) and a new error sub- code TBA6 "Compliant path
exists" (value: to be assigned by IANA). The PSR flag MUST NOT
be set. A source node receiving a PathErr message with this
error code and sub-code combination MAY move the diverse LSP to
a new path that meets the original constraints.
3. Security Considerations 3. Security Considerations
This document does not introduce any additional security issues This document does not introduce any additional security issues
above those identified in [RFC5920], [RFC2205], [RFC3209], above those identified in [RFC5920], [RFC2205], [RFC3209],
[RFC3473] and [RFC4874]. [RFC3473] and [RFC4874].
The diversity mechanism defined in this document, relies on the The diversity mechanism defined in this document, relies on the
new diversity subobject that is carried in the XRO or EXRS, new diversity subobject that is carried in the XRO or EXRS,
respectively. In section 7 of [RFC4874], it is stated that the respectively. In section 7 of [RFC4874], it is stated that the
skipping to change at page 22, line 41 skipping to change at page 22, line 45
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol- Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for "Resource Reservation Protocol (RSVP) Extensions for
Path Key Support", RFC 5553, May 2009. Path Key Support", RFC 5553, May 2009.
6.2. Informative References 6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005. Overlay Model", RFC 4208, October 2005.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain "Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009. 5520, April 2009.
[RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria, [RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria,
"RSVP-TE Extensions for Collecting SRLG Information", "RSVP-TE Extensions for Collecting SRLG Information",
RFC 8001, January 2017. RFC 8001, January 2017.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
skipping to change at page 23, line 46 skipping to change at page 24, line 4
Contributors' Addresses Contributors' Addresses
Igor Bryskin Igor Bryskin
Huawei Technologies Huawei Technologies
Email: Igor.Bryskin@huawei.com Email: Igor.Bryskin@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Email: Daniele.Ceccarelli@ericsson.com Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica I+D Telefonica I+D
Email: ogondio@tid.es Email: ogondio@tid.es
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard Enterprise
Email: don.fedyk@hp.com Email: don.fedyk@hpe.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Gabriele Maria Galimberti Gabriele Maria Galimberti
Cisco Systems Cisco Systems
Email: ggalimbe@cisco.com Email: ggalimbe@cisco.com
Ori Gerstel Ori Gerstel
 End of changes. 34 change blocks. 
80 lines changed or deleted 91 lines changed or added

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