draft-ietf-pce-stateful-path-protection-09.txt   draft-ietf-pce-stateful-path-protection-10.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 2, 2020 Cisco Expires: March 3, 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 30, 2019 August 31, 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-09 draft-ietf-pce-stateful-path-protection-10
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 Label Switched Paths (MPLS LSP). Furthermore, it is also
possible for an active stateful PCE to create, maintain, and delete possible for an active stateful PCE to create, maintain, and delete
LSPs. This document describes PCEP extension to associate two or LSPs. This document defines the PCEP extension to associate two or
more LSPs to provide end-to-end path protection. 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 2, 2020. This Internet-Draft will expire on March 3, 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 6, line 22 skipping to change at page 6, line 22
Association Flags (32 bits), where each bit represents a flag option. Association Flags (32 bits), where each bit represents a flag option.
The format of the Path Protection Association TLV (Figure 1) is as The format of the Path Protection Association TLV (Figure 1) is as
follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD2 | Length = 4 | | Type = TBD2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Path Protection Association 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 working or protection LSP.
skipping to change at page 11, line 23 skipping to change at page 11, line 23
| TBD5 | Protection type is not supported | This | | TBD5 | Protection type is not supported | This |
| | | document | | | | document |
+-------------+-----------------------------------------+-----------+ +-------------+-----------------------------------------+-----------+
7. Security Considerations 7. Security Considerations
The security considerations described in [RFC8231], [RFC8281], and The security considerations described in [RFC8231], [RFC8281], and
[RFC5440] apply to the extensions described in this document as well. [RFC5440] apply to the extensions described in this document as well.
Additional considerations related to associations where a malicious Additional considerations related to associations where a malicious
PCEP speaker could be spoofed and could be used as an attack vector PCEP speaker could be spoofed and could be used as an attack vector
by creating associations is described in by creating associations as described in
[I-D.ietf-pce-association-group]. Thus securing the PCEP session [I-D.ietf-pce-association-group]. Adding a spurious protection LSP
using Transport Layer Security (TLS) [RFC8253], as per the to the Path Protection Association group could give false sense of
network reliability, which leads to issues when the working LSP is
down and the protection LSP fails as well. Thus securing the PCEP
session using Transport Layer Security (TLS) [RFC8253], as per the
recommendations and best current practices in [RFC7525], is recommendations and best current practices in [RFC7525], is
RECOMMENDED. RECOMMENDED.
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
Mechanisms defined in this document do not imply any control or Mechanisms defined in this document do not imply any control or
policy requirements in addition to those already listed in [RFC5440], policy requirements in addition to those already listed in [RFC5440],
[RFC8231], and [RFC8281]. [RFC8231], and [RFC8281].
skipping to change at page 12, line 31 skipping to change at page 12, line 31
9. Acknowledgments 9. Acknowledgments
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.
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.,
 End of changes. 8 change blocks. 
9 lines changed or deleted 14 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/