< draft-ietf-pce-stateful-path-protection-10.txt | draft-ietf-pce-stateful-path-protection-11.txt > | |||
---|---|---|---|---|
PCE Working Group H. Ananthakrishnan | PCE Working Group H. Ananthakrishnan | |||
Internet-Draft Netflix | Internet-Draft Netflix | |||
Intended status: Standards Track S. Sivabalan | Intended status: Standards Track S. Sivabalan | |||
Expires: March 3, 2020 Cisco | Expires: March 19, 2020 Cisco | |||
C. Barth | C. Barth | |||
Juniper Networks | Juniper Networks | |||
I. Minei | I. Minei | |||
Google, Inc | Google, Inc | |||
M. Negi | M. Negi | |||
Huawei Technologies | Huawei Technologies | |||
August 31, 2019 | September 16, 2019 | |||
PCEP Extensions for Associating Working and Protection LSPs with | PCEP Extensions for Associating Working and Protection LSPs with | |||
Stateful PCE | Stateful PCE | |||
draft-ietf-pce-stateful-path-protection-10 | draft-ietf-pce-stateful-path-protection-11 | |||
Abstract | Abstract | |||
An active stateful Path Computation Element (PCE) is capable of | An active stateful Path Computation Element (PCE) is capable of | |||
computing as well as controlling via Path Computation Element | computing as well as controlling via Path Computation Element | |||
Communication Protocol (PCEP) Multiprotocol Label Switching Traffic | Communication Protocol (PCEP) Multiprotocol Label Switching Traffic | |||
Engineering Label Switched Paths (MPLS LSP). Furthermore, it is also | Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it | |||
possible for an active stateful PCE to create, maintain, and delete | is also possible for an active stateful PCE to create, maintain, and | |||
LSPs. This document defines the PCEP extension to associate two or | delete LSPs. This document defines the PCEP extension to associate | |||
more LSPs to provide end-to-end path protection. | two or more LSPs to provide end-to-end path protection. | |||
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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 3, 2020. | This Internet-Draft will expire on March 19, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 28 ¶ | skipping to change at page 2, line 28 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. Path Protection Association Type . . . . . . . . . . . . 5 | 3.1. Path Protection Association Type . . . . . . . . . . . . 5 | |||
3.2. Path Protection Association TLV . . . . . . . . . . . . . 5 | 3.2. Path Protection Association TLV . . . . . . . . . . . . . 5 | |||
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 | 4.1. State Synchronization . . . . . . . . . . . . . . . . . . 7 | |||
4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 | 4.2. PCC-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 | 4.3. PCE-Initiated LSPs . . . . . . . . . . . . . . . . . . . 7 | |||
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 7 | 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 7 | |||
4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 | 4.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 | |||
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 | 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Association Type . . . . . . . . . . . . . . . . . . . . 9 | |||
6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6.2. PPAG TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 10 | 6.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8. Manageability Considerations . . . . . . . . . . . . . . . . 11 | 8. Manageability Considerations . . . . . . . . . . . . . . . . 11 | |||
8.1. Control of Function and Policy . . . . . . . . . . . . . 11 | 8.1. Control of Function and Policy . . . . . . . . . . . . . 11 | |||
8.2. Information and Data Models . . . . . . . . . . . . . . . 11 | 8.2. Information and Data Models . . . . . . . . . . . . . . . 11 | |||
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 | 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 | |||
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 | 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 | |||
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 | 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 | |||
8.6. Impact On Network Operations . . . . . . . . . . . . . . 12 | 8.6. Impact On Network Operations . . . . . . . . . . . . . . 12 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 13 | 10.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 | Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
1. Introduction | 1. Introduction | |||
[RFC5440] describes PCEP for communication between a Path Computation | [RFC5440] describes Path Computation Element Communication Protocol | |||
Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655]. A | for communication between a Path Computation Client (PCC) and a PCE | |||
PCE computes paths for MPLS-TE LSPs based on various constraints and | or between a pair of PCEs as per [RFC4655]. A PCE computes paths for | |||
MPLS-TE Label Switched Paths (LSPs) based on various constraints and | ||||
optimization criteria. | optimization criteria. | |||
Stateful PCE [RFC8231] specifies a set of extensions to PCEP to | Stateful PCE [RFC8231] specifies a set of extensions to PCEP to | |||
enable stateful control of paths such as MPLS TE LSPs between and | enable stateful control of paths such as MPLS-TE LSPs between and | |||
across PCEP sessions in compliance with [RFC4657]. It includes | across PCEP sessions in compliance with [RFC4657]. It includes | |||
mechanisms to effect LSP state synchronization between PCCs and PCEs, | mechanisms to effect LSP state synchronization between PCCs and PCEs, | |||
delegation of control of LSPs to PCEs, and PCE control of timing and | delegation of control of LSPs to PCEs, and PCE control of timing and | |||
sequence of path computations within and across PCEP sessions and | sequence of path computations within and across PCEP sessions. The | |||
focuses on a model where LSPs are configured on the PCC and control | focus is on a model where LSPs are configured on the PCC and control | |||
over them is delegated to the PCE. Furthermore, a mechanism to | over them is delegated to the Stateful PCE. Furthermore, [RFC8281] | |||
dynamically instantiate LSPs on a PCC based on the requests from a | specifies a mechanism to dynamically instantiate LSPs on a PCC based | |||
stateful PCE or a controller using stateful PCE, is specified in | on the requests from a stateful PCE or a controller using stateful | |||
[RFC8281]. | PCE. | |||
Path protection [RFC4427] refers to a paradigm in which the working | Path protection [RFC4427] refers to a paradigm in which the working | |||
LSP is protected by one or more protection LSP(s). When the working | LSP is protected by one or more protection LSP(s). When the working | |||
LSP fails, protection LSP(s) is/are activated. When the working LSPs | LSP fails, protection LSP(s) is/are activated. When the working LSPs | |||
are computed and controlled by the PCE, there is benefit in a mode of | are computed and controlled by the PCE, there is benefit in a mode of | |||
operation where protection LSPs are as well. [RFC8051] describes | operation where protection LSPs are as well. [RFC8051] describes | |||
applicability of path protection in PCE deployments. | applicability of path protection in PCE deployments. | |||
This document specifies a stateful PCEP extension to associate two or | This document specifies a stateful PCEP extension to associate two or | |||
more LSPs for the purpose of setting up path protection. The | more LSPs for the purpose of setting up path protection. The | |||
skipping to change at page 3, line 45 ¶ | skipping to change at page 3, line 46 ¶ | |||
o A PCC initiates a protection LSP and retains the control of the | o A PCC initiates a protection LSP and retains the control of the | |||
LSP. The PCC computes the path itself or makes a request for path | LSP. The PCC computes the path itself or makes a request for path | |||
computation to a PCE. After the path setup, it reports the | computation to a PCE. After the path setup, it reports the | |||
information and state of the path to the PCE. This includes the | information and state of the path to the PCE. This includes the | |||
association group identifying the working and protection LSPs. | association group identifying the working and protection LSPs. | |||
This is the passive stateful mode [RFC8051]. | This is the passive stateful mode [RFC8051]. | |||
o A PCC initiates a protection LSP and delegates the control of the | o A PCC initiates a protection LSP and delegates the control of the | |||
LSP to a stateful PCE. During delegation the association group | LSP to a stateful PCE. During delegation the association group | |||
identifying the working and protection LSPs is included. The PCE | identifying the working and protection LSPs is included. The PCE | |||
computes the path for the protection LSP and update the PCC with | computes the path for the protection LSP and updates the PCC with | |||
the information about the path as long as it controls the LSP. | the information about the path as long as it controls the LSP. | |||
This is the active stateful mode [RFC8051]. | This is the active stateful mode [RFC8051]. | |||
o A protection LSP could be initiated by a stateful PCE, which | o A protection LSP could be initiated by a stateful PCE, which | |||
retains the control of the LSP. The PCE is responsible for | retains the control of the LSP. The PCE is responsible for | |||
computing the path of the LSP and updating to the PCC with the | computing the path of the LSP and updating to the PCC with the | |||
information about the path. This is the PCE-Initiated mode | information about the path. This is the PCE-Initiated mode | |||
[RFC8281]. | [RFC8281]. | |||
Note that protection LSP can be established (signaled) prior to the | Note that a protection LSP can be established (signaled) before the | |||
failure (in which case the LSP is said to be in standby mode | failure (in which case the LSP is said to be in standby mode | |||
[RFC4427] or a Primary LSP [RFC4872]) or post failure of the | [RFC4427] or a Primary LSP [RFC4872]) or after failure of the | |||
corresponding working LSP according to the operator choice/policy | corresponding working LSP (known as a secondary LSP [RFC4872]). | |||
(known as secondary LSP [RFC4872]). | Whether to establish it before or after failure is according to | |||
operator choice or policy. | ||||
[I-D.ietf-pce-association-group] introduces a generic mechanism to | [I-D.ietf-pce-association-group] introduces a generic mechanism to | |||
create a grouping of LSPs which can then be used to define | create a grouping of LSPs, which can then be used to define | |||
associations between a set of LSPs that is equally applicable to | associations between a set of LSPs. The mechanism is equally | |||
stateful PCE (active and passive modes) and stateless PCE. | applicable to stateful PCE (active and passive modes) and stateless | |||
PCE. | ||||
This document specifies a PCEP extension to associate one working LSP | This document specifies a PCEP extension to associate one working LSP | |||
with one or more protection LSPs using the generic association | with one or more protection LSPs using the generic association | |||
mechanism. | mechanism. | |||
This document describes a PCEP extension to associate protection LSPs | This document describes a PCEP extension to associate protection LSPs | |||
by creating Path Protection Association Group (PPAG) and encoding | by creating Path Protection Association Group (PPAG) and encoding | |||
this association in PCEP messages for stateful PCEP sessions. | this association in PCEP messages for stateful PCEP sessions. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
skipping to change at page 6, line 31 ¶ | skipping to change at page 6, line 33 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| PT | Unassigned Flags |S|P| | | PT | Unassigned Flags |S|P| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Path Protection Association TLV format | Figure 1: Path Protection Association TLV format | |||
Path Protection Association Flags (32 bits) - The following flags are | Path Protection Association Flags (32 bits) - The following flags are | |||
currently defined - | currently defined - | |||
Protecting (P): 1 bit - This bit is as defined in Section 14.1 of | Protecting (P): 1 bit - This bit is as defined in Section 14.1 of | |||
[RFC4872] to indicate if the LSP is working or protection LSP. | [RFC4872] to indicate if the LSP is a working (0) or protection | |||
(1) LSP. | ||||
Secondary (S): 1 bit - This bit is as defined in Section 14.1 of | Secondary (S): 1 bit - This bit is as defined in Section 14.1 of | |||
[RFC4872] to indicate if the LSP is primary or secondary LSP. The | [RFC4872] to indicate if the LSP is a primary (0) or secondary (1) | |||
S flag is ignored if the P flag is not set. | LSP. The S flag is ignored if the P flag is not set. | |||
Protection Type (PT): 6 bits - This field is as defined in | Protection Type (PT): 6 bits - This field is as defined in | |||
Section 14.1 of [RFC4872] to indicate the LSP protection type in | Section 14.1 of [RFC4872] to indicate the LSP protection type in | |||
use. | use. | |||
Unassigned bits are considered reserved. They MUST be set to 0 on | Unassigned bits are considered reserved. They MUST be set to 0 on | |||
transmission and MUST be ignored on receipt. | transmission and MUST be ignored on receipt. | |||
If the TLV is missing, it is considered that the LSP is the working | If the TLV is missing, it is considered that the LSP is a working LSP | |||
LSP (i.e. as if P bit is unset). | (i.e. as if the P bit is unset). | |||
4. Operation | 4. Operation | |||
An LSP is associated with other LSPs with which they interact by | An LSP is associated with other LSPs with which it interacts by | |||
adding them to a common association group via the ASSOCIATION object. | adding them to a common association group via the ASSOCIATION object. | |||
All procedures and error-handling for the ASSOCIATION object is as | All procedures and error-handling for the ASSOCIATION object is as | |||
per [I-D.ietf-pce-association-group]. | per [I-D.ietf-pce-association-group]. | |||
4.1. State Synchronization | 4.1. State Synchronization | |||
During state synchronization, a PCC reports all the existing LSP | During state synchronization, a PCC reports all the existing LSP | |||
states as described in [RFC8231]. The association group membership | states as described in [RFC8231]. The association group membership | |||
pertaining to an LSP is also reported as per | pertaining to an LSP is also reported as per | |||
[I-D.ietf-pce-association-group]. This includes PPAGs. | [I-D.ietf-pce-association-group]. This includes PPAGs. | |||
skipping to change at page 7, line 18 ¶ | skipping to change at page 7, line 22 ¶ | |||
4.1. State Synchronization | 4.1. State Synchronization | |||
During state synchronization, a PCC reports all the existing LSP | During state synchronization, a PCC reports all the existing LSP | |||
states as described in [RFC8231]. The association group membership | states as described in [RFC8231]. The association group membership | |||
pertaining to an LSP is also reported as per | pertaining to an LSP is also reported as per | |||
[I-D.ietf-pce-association-group]. This includes PPAGs. | [I-D.ietf-pce-association-group]. This includes PPAGs. | |||
4.2. PCC-Initiated LSPs | 4.2. PCC-Initiated LSPs | |||
A PCC can associate a set of LSPs under its control for path | A PCC can associate a set of LSPs under its control for path | |||
protection purpose. Similarly, the PCC can remove one or more LSPs | protection purposes. Similarly, the PCC can remove one or more LSPs | |||
under its control from the corresponding PPAG. In both cases, the | under its control from the corresponding PPAG. In both cases, the | |||
PCC reports the change in association to PCE(s) via Path Computation | PCC reports the change in association to PCE(s) via Path Computation | |||
Report (PCRpt) message. A PCC can also delegate the working and | Report (PCRpt) messages. A PCC can also delegate the working and | |||
protection LSPs to an active stateful PCE, where the PCE would | protection LSPs to an active stateful PCE, where the PCE would | |||
control the LSPs. The stateful PCE could update the paths and | control the LSPs. The stateful PCE could update the paths and | |||
attributes of the LSPs in the association group via Path Computation | attributes of the LSPs in the association group via Path Computation | |||
Update (PCUpd) message. A PCE could also update the association to | Update (PCUpd) message. A PCE could also update the association to | |||
the PCC via PCUpd message. These procedures are described in | the PCC via PCUpd message. These procedures are described in | |||
[I-D.ietf-pce-association-group]. | [I-D.ietf-pce-association-group]. | |||
It is expected that both working and protection LSP are delegated | It is expected that both working and protection LSPs are delegated | |||
together (and to the same PCE) to avoid any race conditions. Refer | together (and to the same PCE) to avoid any race conditions. Refer | |||
to [I-D.litkowski-pce-state-sync] for the problem description. | to [I-D.litkowski-pce-state-sync] for the problem description. | |||
4.3. PCE-Initiated LSPs | 4.3. PCE-Initiated LSPs | |||
A PCE can create/update working and protection LSPs independently. | A PCE can create/update working and protection LSPs independently. | |||
As specified in [I-D.ietf-pce-association-group], Association Groups | As specified in [I-D.ietf-pce-association-group], Association Groups | |||
can be created by both the PCE and the PCC. Further, a PCE can | can be created by both the PCE and the PCC. Further, a PCE can | |||
remove a protection LSP from a PPAG as specified in | remove a protection LSP from a PPAG as specified in | |||
[I-D.ietf-pce-association-group]. The PCE uses PCUpd or Path | [I-D.ietf-pce-association-group]. The PCE uses PCUpd or Path | |||
skipping to change at page 8, line 39 ¶ | skipping to change at page 8, line 42 ¶ | |||
the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) | the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) | |||
[I-D.ietf-pce-association-group] and Error-Value TBD5 (Protection | [I-D.ietf-pce-association-group] and Error-Value TBD5 (Protection | |||
type is not supported). | type is not supported). | |||
A given LSP MAY belong to more than one PPAG. If there is a conflict | A given LSP MAY belong to more than one PPAG. If there is a conflict | |||
between any of the two PPAGs, the PCEP peer MUST send PCErr with | between any of the two PPAGs, the PCEP peer MUST send PCErr with | |||
Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] | Error-Type 26 (Association Error) [I-D.ietf-pce-association-group] | |||
and Error-Value 6 (Association information mismatch) as per | and Error-Value 6 (Association information mismatch) as per | |||
[I-D.ietf-pce-association-group]. | [I-D.ietf-pce-association-group]. | |||
When the protection type is set to 1+1 or 1:N with N=1, there MUST be | When the protection type is set to 1+1 or 1:1 (1:N with N=1), there | |||
only one working LSP and one protection LSP within a PPAG. If a PCEP | MUST be only one working LSP and one protection LSP within a PPAG. | |||
speaker attempts to add another working/protection LSP, the PCEP peer | If a PCEP speaker attempts to add another working/protection LSP, the | |||
MUST send PCErr with Error-Type 26 (Association Error) | PCEP peer MUST send PCErr with Error-Type 26 (Association Error) | |||
[I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add | [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add | |||
another working/protection LSP for Path Protection Association). | another working/protection LSP for Path Protection Association). | |||
When the protection type is set to 1:N with N>1, there MUST be only | When the protection type is set to 1:N with N>1, there MUST be only | |||
one working LSP and number of protection LSPs MUST NOT be more than N | one working LSP and number of protection LSPs MUST NOT be more than N | |||
within a PPAG. If a PCEP speaker attempts to add another working/ | within a PPAG. If a PCEP speaker attempts to add another working/ | |||
protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 | protection LSP, the PCEP peer MUST send PCErr with Error-Type 26 | |||
(Association Error) [I-D.ietf-pce-association-group] and Error-Value | (Association Error) [I-D.ietf-pce-association-group] and Error-Value | |||
TBD4 (Attempt to add another working/protection LSP for Path | TBD4 (Attempt to add another working/protection LSP for Path | |||
Protection Association). | Protection Association). | |||
skipping to change at page 9, line 21 ¶ | skipping to change at page 9, line 25 ¶ | |||
(e.g., node, SRLG disjoint). This ensures that a single failure will | (e.g., node, SRLG disjoint). This ensures that a single failure will | |||
not affect both the working and protection LSPs. The disjoint | not affect both the working and protection LSPs. The disjoint | |||
requirement for a group of LSPs is handled via another Association | requirement for a group of LSPs is handled via another Association | |||
type called "Disjointness Association", as described in | type called "Disjointness Association", as described in | |||
[I-D.ietf-pce-association-diversity]. The diversity requirements for | [I-D.ietf-pce-association-diversity]. The diversity requirements for | |||
the protection LSP are also handled by including both ASSOCIATION | the protection LSP are also handled by including both ASSOCIATION | |||
objects identifying both the protection association group and the | objects identifying both the protection association group and the | |||
disjoint association group for the group of LSPs. | disjoint association group for the group of LSPs. | |||
[RFC4872] introduces the concept and mechanisms to support the | [RFC4872] introduces the concept and mechanisms to support the | |||
association of one LSP to another LSP across different RSVP - Traffic | association of one LSP to another LSP across different RSVP Traffic | |||
Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION | Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION | |||
object. The information in the PPAG TLV in PCEP as received from the | object. The information in the PPAG TLV in PCEP as received from the | |||
PCE, is used to trigger the signalling of working LSP and protection | PCE is used to trigger the signalling of working LSP and protection | |||
LSP, with the Path Protection Association Flags mapped to the | LSP, with the Path Protection Association Flags mapped to the | |||
corresponding fields in the PROTECTION Object in RSVP-TE. | corresponding fields in the PROTECTION Object in RSVP-TE. | |||
6. IANA Considerations | 6. IANA Considerations | |||
[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain | [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain | |||
"TBD1" through "TBD5" those should be replaced by the values that | "TBD1" through "TBD5" those should be replaced by the values that | |||
IANA assigns.] | IANA assigns.] | |||
6.1. Association Type | 6.1. Association Type | |||
skipping to change at page 12, line 33 ¶ | skipping to change at page 12, line 41 ¶ | |||
We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for | We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for | |||
their contributions to this document. | their contributions to this document. | |||
Thanks to Ines Robles for the RTGDIR review. | Thanks to Ines Robles for the RTGDIR review. | |||
Thanks to Pete Resnick for the GENART review. | Thanks to Pete Resnick for the GENART review. | |||
Thanks to Donald Eastlake for the SECDIR review. | Thanks to Donald Eastlake for the SECDIR review. | |||
Thanks to Barry Leiba for the IESG review. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.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-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | |||
skipping to change at page 14, line 43 ¶ | skipping to change at page 15, line 9 ¶ | |||
[I-D.ietf-pce-pcep-yang] | [I-D.ietf-pce-pcep-yang] | |||
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A | Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A | |||
YANG Data Model for Path Computation Element | YANG Data Model for Path Computation Element | |||
Communications Protocol (PCEP)", draft-ietf-pce-pcep- | Communications Protocol (PCEP)", draft-ietf-pce-pcep- | |||
yang-12 (work in progress), July 2019. | yang-12 (work in progress), July 2019. | |||
[I-D.ietf-pce-association-diversity] | [I-D.ietf-pce-association-diversity] | |||
Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, | Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, | |||
"Path Computation Element Communication Protocol (PCEP) | "Path Computation Element Communication Protocol (PCEP) | |||
Extension for LSP Diversity Constraint Signaling", draft- | Extension for LSP Diversity Constraint Signaling", draft- | |||
ietf-pce-association-diversity-09 (work in progress), | ietf-pce-association-diversity-10 (work in progress), | |||
August 2019. | August 2019. | |||
[I-D.ietf-pce-segment-routing] | [I-D.ietf-pce-segment-routing] | |||
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., | |||
and J. Hardwick, "PCEP Extensions for Segment Routing", | and J. Hardwick, "PCEP Extensions for Segment Routing", | |||
draft-ietf-pce-segment-routing-16 (work in progress), | draft-ietf-pce-segment-routing-16 (work in progress), | |||
March 2019. | March 2019. | |||
[I-D.litkowski-pce-state-sync] | [I-D.litkowski-pce-state-sync] | |||
Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter | Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter | |||
End of changes. 29 change blocks. | ||||
47 lines changed or deleted | 52 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/ |