draft-ietf-pce-local-protection-enforcement-09.txt | draft-ietf-pce-local-protection-enforcement-10.txt | |||
---|---|---|---|---|
Network Working Group A. Stone | Network Working Group A. Stone | |||
Internet-Draft M. Aissaoui | Internet-Draft M. Aissaoui | |||
Updates: 5440 (if approved) Nokia | Updates: 5440 (if approved) Nokia | |||
Intended status: Standards Track S. Sidor | Intended status: Standards Track S. Sidor | |||
Expires: 9 November 2023 Cisco Systems, Inc. | Expires: 20 November 2023 Cisco Systems, Inc. | |||
S. Sivabalan | S. Sivabalan | |||
Ciena Coroporation | Ciena Coroporation | |||
8 May 2023 | 19 May 2023 | |||
Local Protection Enforcement in PCEP | Local Protection Enforcement in PCEP | |||
draft-ietf-pce-local-protection-enforcement-09 | draft-ietf-pce-local-protection-enforcement-10 | |||
Abstract | Abstract | |||
This document extends the base specification to clarify usage of the | This document extends the base specification to clarify usage of the | |||
local protection desired bit signalled in the Path Computation | local protection desired bit signalled in the Path Computation | |||
Element Protocol (PCEP). This document also introduces a new flag | Element Protocol (PCEP). This document also introduces a new flag | |||
for signalling protection strictness in PCEP. | for signalling protection strictness in PCEP. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
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 9 November 2023. | This Internet-Draft will expire on 20 November 2023. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2023 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Implementation differences . . . . . . . . . . . . . . . 4 | 4.1. Implementation differences . . . . . . . . . . . . . . . 4 | |||
4.2. SLA Enforcement . . . . . . . . . . . . . . . . . . . . . 4 | 4.2. SLA Enforcement . . . . . . . . . . . . . . . . . . . . . 4 | |||
5. Protection Enforcement Flag (E flag) . . . . . . . . . . . . 5 | 5. Protection Enforcement Flag (E flag) . . . . . . . . . . . . 5 | |||
5.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 | 5.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 | |||
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 | 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 | |||
6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8 | 6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8 | |||
6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 9 | 6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 9 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 11 | 9.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
The Path Computation Element (PCE) Communication Protocol (PCEP) | The Path Computation Element (PCE) Communication Protocol (PCEP) | |||
[RFC5440] enables the communication between a Path Computation Client | [RFC5440] enables the communication between a Path Computation Client | |||
(PCC) and a PCE, or between two PCEs based on the PCE architecture | (PCC) and a PCE, or between two PCEs based on the PCE architecture | |||
skipping to change at page 3, line 20 ¶ | skipping to change at page 3, line 20 ¶ | |||
RSVP, this flag signals to downstream routers that they may use a | RSVP, this flag signals to downstream routers that they may use a | |||
local repair mechanism. The headend router calculating the path does | local repair mechanism. The headend router calculating the path does | |||
not know whether a downstream router will or will not protect a hop | not know whether a downstream router will or will not protect a hop | |||
during its calculation. Therefore, a local protection desired does | during its calculation. Therefore, a local protection desired does | |||
not require the transit router to satisfy protection in order to | not require the transit router to satisfy protection in order to | |||
establish the RSVP signalled path. This flag is signalled in PCEP as | establish the RSVP signalled path. This flag is signalled in PCEP as | |||
an attribute of the LSP via the LSP Attributes object. | an attribute of the LSP via the LSP Attributes object. | |||
PCEP Extensions for Segment Routing ([RFC8664]) extends support in | PCEP Extensions for Segment Routing ([RFC8664]) extends support in | |||
PCEP for Segment Routed paths. The path list is encoded with Segment | PCEP for Segment Routed paths. The path list is encoded with Segment | |||
Identifiers, each of which offer local protection. The PCE may | Identifiers, each of which might offer local protection. The PCE may | |||
discover the protection eligibility for a Segment Identifier (SID) | discover the protection eligibility for a Segment Identifier (SID) | |||
via BGP-LS [RFC9085] and take the protection into consideration as a | via BGP-LS [RFC9085] and take the protection into consideration as a | |||
path constraint. | path constraint. | |||
It is desirable for an operator to be able to define the enforcement, | It is desirable for an operator to be able to define the enforcement, | |||
or strictness of the protection requirement. | or strictness of the protection requirement. | |||
This document updates [RFC5440] by further describing the behaviour | This document updates [RFC5440] by further describing the behaviour | |||
with the Local Protection Desired Flag (L flag) and extends on it | with the Local Protection Desired Flag (L flag) and extends on it | |||
with the introduction of the Enforcement Flag (E flag). | with the introduction of the Enforcement Flag (E flag). | |||
skipping to change at page 4, line 5 ¶ | skipping to change at page 4, line 5 ¶ | |||
3. Terminology | 3. Terminology | |||
This document uses the following terminology: | This document uses the following terminology: | |||
PROTECTION MANDATORY: The Path MUST have protection eligibility on | PROTECTION MANDATORY: The Path MUST have protection eligibility on | |||
all links. | all links. | |||
UNPROTECTED MANDATORY: The Path MUST NOT have protection eligibility | UNPROTECTED MANDATORY: The Path MUST NOT have protection eligibility | |||
on all links. | on all links. | |||
PROTECTION PREFERRED: The Path SHOULD have protection eligibility on | PROTECTION PREFERRED: The Path should have protection eligibility on | |||
all links but MAY contain links which do not have protection | all links but might contain links which do not have protection | |||
eligibility. | eligibility. | |||
UNPROTECTED PREFERRED: The Path SHOULD NOT have protection | UNPROTECTED PREFERRED: The Path should not have protection | |||
eligibility on all links but MAY contain links which have protection | eligibility on all links but might contain links which have | |||
eligibility. | protection eligibility. | |||
PCC: Path Computation Client. Any client application requesting a | PCC: Path Computation Client. Any client application requesting a | |||
path computation to be performed by a Path Computation Element. | path computation to be performed by a Path Computation Element. | |||
PCE: Path Computation Element. An entity (component, application, or | PCE: Path Computation Element. An entity (component, application, or | |||
network node) that is capable of computing a network path or route | network node) that is capable of computing a network path or route | |||
based on a network graph and applying computational constraints. | based on a network graph and applying computational constraints. | |||
PCEP: Path Computation Element Protocol. | PCEP: Path Computation Element Protocol. | |||
skipping to change at page 7, line 12 ¶ | skipping to change at page 7, line 12 ¶ | |||
consider the protection eligibility as a PROTECTION MANDATORY | consider the protection eligibility as a PROTECTION MANDATORY | |||
constraint. | constraint. | |||
When the L flag is set to 1 and the E flag is set to 0, then the PCE | When the L flag is set to 1 and the E flag is set to 0, then the PCE | |||
MUST consider the protection eligibility as a PROTECTION PREFERRED | MUST consider the protection eligibility as a PROTECTION PREFERRED | |||
constraint. | constraint. | |||
When both L flag and E flag are set to 0, then the PCE SHOULD | When both L flag and E flag are set to 0, then the PCE SHOULD | |||
consider the protection eligibility as an UNPROTECTED PREFERRED | consider the protection eligibility as an UNPROTECTED PREFERRED | |||
constraint but MAY consider protection eligibility as an UNPROTECTED | constraint but MAY consider protection eligibility as an UNPROTECTED | |||
MANDATORY constraint. | MANDATORY constraint. An example of when the latter behavior might | |||
be chosen is if the PCE has some means (outside the scope of this | ||||
document) to detect that it’s interacting with a legacy PCC that | ||||
expects the legacy behavior. | ||||
When L flag is set to 0 and E flag is set to 1, then the PCE MUST | When L flag is set to 0 and E flag is set to 1, then the PCE MUST | |||
consider the protection eligibility as an UNPROTECTED MANDATORY | consider the protection eligibility as an UNPROTECTED MANDATORY | |||
constraint. | constraint. | |||
If a PCE is unable to infer protection status of a resource, PCE MAY | If a PCE is unable to infer the protection status of a resource, the | |||
use local policy to define protected status assumptions. When | PCE MAY use local policy to define protected status assumptions. | |||
computing a Segment Routed path, It is RECOMMENDED that a PCE assume | When computing a Segment Routed path, It is RECOMMENDED that a PCE | |||
a Node SID is protected. It is also RECOMMENDED that a PCE assume an | assume a Node SID is protected. It is also RECOMMENDED that a PCE | |||
Adjacency SID is protected if the backup flag advertised with the | assume an Adjacency SID is protected if the backup flag advertised | |||
Adjacency SID is set. | with the Adjacency SID is set. | |||
5.1. Backwards Compatibility | 5.1. Backwards Compatibility | |||
Considerations in the message passing between the PCC and the PCE for | Considerations in the message passing between the PCC and the PCE for | |||
the E flag bit which are not supported by the entity are outlined in | the E flag bit which are not supported by the entity are outlined in | |||
this section, with requirements for the PCE and the PCC implementing | this section, with requirements for the PCE and the PCC implementing | |||
this document described at the end. | this document described at the end. | |||
For a PCC or PCE which does not yet support this document, the E flag | For a PCC or PCE which does not yet support this document, the E flag | |||
is ignored and set to zero in PCRpt and/or PCUpd as per [RFC5440] for | is ignored and set to zero in PCRpt and/or PCUpd as per [RFC5440] for | |||
skipping to change at page 8, line 4 ¶ | skipping to change at page 8, line 8 ¶ | |||
the E flag set to 0 for PCC-initated LSPs even if set to 1 in the | the E flag set to 0 for PCC-initated LSPs even if set to 1 in the | |||
prior PCReq or PCRpt. | prior PCReq or PCRpt. | |||
A PCC which does not support this document sends PCRpt messages with | A PCC which does not support this document sends PCRpt messages with | |||
the E flag set to 0 for PCE-initiated LSPs even if set to 1 in the | the E flag set to 0 for PCE-initiated LSPs even if set to 1 in the | |||
prior PCInitiate or PCUpd. | prior PCInitiate or PCUpd. | |||
For a PCC which does support this document, it MAY set the E flag to | For a PCC which does support this document, it MAY set the E flag to | |||
1 depending on local configuration. If communicating with a PCE | 1 depending on local configuration. If communicating with a PCE | |||
which does not yet support this document, the PCE follows the | which does not yet support this document, the PCE follows the | |||
behaviour specified in [RFC5440] and will ignore the E flag. Thus, | behaviour specified in [RFC5440] and will ignore the E flag. Thus, a | |||
it may compute a path which may not respect the enforcement | computed path might not respect the enforcement constraint. | |||
constraint. | ||||
For PCC-initiated LSPs, the PCC SHOULD ignore the E flag value | For PCC-initiated LSPs, the PCC SHOULD ignore the E flag value | |||
received from the PCE in a PCUpd message as it may be communicating | received from the PCE in a PCUpd message as it may be communicating | |||
with a PCE which does not support this document. | with a PCE which does not support this document. | |||
For PCE-initiated LSPs, the PCC MAY process the E flag value received | For PCE-initiated LSPs, the PCC MAY process the E flag value received | |||
from the PCE in a PCUpd message. The PCE SHOULD ignore the E flag | from the PCE in a PCUpd message. The PCE SHOULD ignore the E flag | |||
value received from the PCC in a PCRpt message as it may be | value received from the PCC in a PCRpt message as it may be | |||
communicating with a PCC which does not support this document. | communicating with a PCC which does not support this document. | |||
skipping to change at page 11, line 37 ¶ | skipping to change at page 11, line 37 ¶ | |||
<https://www.rfc-editor.org/info/rfc8664>. | <https://www.rfc-editor.org/info/rfc8664>. | |||
[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, | [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, | |||
H., and M. Chen, "Border Gateway Protocol - Link State | H., and M. Chen, "Border Gateway Protocol - Link State | |||
(BGP-LS) Extensions for Segment Routing", RFC 9085, | (BGP-LS) Extensions for Segment Routing", RFC 9085, | |||
DOI 10.17487/RFC9085, August 2021, | DOI 10.17487/RFC9085, August 2021, | |||
<https://www.rfc-editor.org/info/rfc9085>. | <https://www.rfc-editor.org/info/rfc9085>. | |||
Acknowledgements | Acknowledgements | |||
Thanks to Dhruv Dhody and Mike Koldychev for reviewing and providing | Thanks to Dhruv Dhody, Mike Koldychev, and John Scudder for reviewing | |||
very valuable feedback and discussions on this document. | and providing very valuable feedback and discussions on this | |||
document. | ||||
Thanks to Julien Meuric for shepherding this document. | Thanks to Julien Meuric for shepherding this document. | |||
Authors' Addresses | Authors' Addresses | |||
Andrew Stone | Andrew Stone | |||
Nokia | Nokia | |||
600 March Road | 600 March Road | |||
Kanata Ontario K2K 2T6 | Kanata Ontario K2K 2T6 | |||
Canada | Canada | |||
End of changes. 12 change blocks. | ||||
23 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |