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/