draft-ietf-pce-local-protection-enforcement-01.txt   draft-ietf-pce-local-protection-enforcement-02.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: July 17, 2021 Cisco Systems, Inc. Expires: August 7, 2021 Cisco Systems, Inc.
S. Sivabalan S. Sivabalan
Ciena Coroporation Ciena Coroporation
January 13, 2021 February 3, 2021
Local Protection Enforcement in PCEP Local Protection Enforcement in PCEP
draft-ietf-pce-local-protection-enforcement-01 draft-ietf-pce-local-protection-enforcement-02
Abstract Abstract
This document updates [RFC5440] to clarify usage of the local This document updates [RFC5440] to clarify usage of the local
protection desired bit signalled in Path Computation Element Protocol protection desired bit signalled in Path Computation Element Protocol
(PCEP). This document also introduces a new flag for signalling (PCEP). This document also introduces a new flag for signalling
protection strictness in PCEP. 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 July 17, 2021. This Internet-Draft will expire on August 7, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . 6
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8 6.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 8
6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 8 6.2. Cisco Implementation . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Path Computation Element (PCE) Communication Protocol (PCEP) 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 Path Control Element (PCE), or between two PCEs based on (PCC) and a Path Control Element (PCE), or between two PCEs based on
the PCE architecture [RFC4655]. the PCE architecture [RFC4655].
PCEP [RFC5440] utilizes flags, values and concepts previously defined PCEP [RFC5440] utilizes flags, values and concepts previously defined
in RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP- in RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP-
skipping to change at page 5, line 24 skipping to change at page 5, line 24
of the LSP would differ during a local failure depending on which SID of the LSP would differ during a local failure depending on which SID
is selected. is selected.
5. Protection Enforcement Flag (E-Flag) 5. Protection Enforcement Flag (E-Flag)
Section 7.11 in Path Computation Element Protocol [RFC5440] describes Section 7.11 in Path Computation Element Protocol [RFC5440] describes
the encoding of the Local Protection Desired (L-Flag). A new flag is the encoding of the Local Protection Desired (L-Flag). A new flag is
proposed in this document in the LSP Attributes Object which extends proposed in this document in the LSP Attributes Object which extends
the L-Flag to identify the protection enforcement. the L-Flag to identify the protection enforcement.
The flag bit is to be allocated by IANA following IETF Consensus. Bit 6 has been early allocated by IANA as the Protection Enforcement
flag.
This draft version proposes using the next available bit: {TBD}
//Editor note, next available bit at time of writing is bit 6
Codespace of the Flag field (LSPA Object) Codespace of the Flag field (LSPA Object)
Bit Description Reference Bit Description Reference
7 Local Protection Desired RFC5440 7 Local Protection Desired RFC5440
<TBD> Local Protection Enforcement This document 6 Local Protection Enforcement This I-D
The format of the LSPA Object as defined in [RFC5440] is: The format of the LSPA Object as defined in [RFC5440] is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 18 skipping to change at page 9, line 4
introduces a new flag to provide further control of that existing introduces a new flag to provide further control of that existing
behaviour. The introduction of this new flag and behaviour behaviour. The introduction of this new flag and behaviour
clarification does not create any new sensitive information. No clarification does not create any new sensitive information. No
additional security measure is required. additional security measure is required.
Securing the PCEP session using Transport Layer Security (TLS) Securing the PCEP session using Transport Layer Security (TLS)
[RFC8253], as per the recommendations and best current practices in [RFC8253], as per the recommendations and best current practices in
[RFC7525] is RECOMMENDED. [RFC7525] is RECOMMENDED.
8. IANA Considerations 8. IANA Considerations
8.1. LSPA Object 8.1. LSPA Object
This document defines a new flag in the LSPA Object. IANA is This document defines a new bit value in the sub-registry "LSPA
requested to allocate the following code point in the "LSPA Object Object Flag Field" in the "Path Computation Element Protocol (PCEP)
Flag Field" subregistry in the "Path Computation Element Protocol Numbers" registry. IANA is requested to confirm the early-allocated
(PCEP) Numbers" registry. codepoint.
Value Name Reference Bit Name Reference
TBD Protection Enforcement This document 6 Protection Enforcement This I-D
9. References 9. References
9.1. Normative References 9.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>.
 End of changes. 13 change blocks. 
22 lines changed or deleted 19 lines changed or added

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