draft-ietf-pce-association-bidir-10.txt   draft-ietf-pce-association-bidir-11.txt 
PCE Working Group R. Gandhi, Ed. PCE Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track C. Barth Intended status: Standards Track C. Barth
Expires: July 10, 2021 Juniper Networks Expires: August 2, 2021 Juniper Networks
B. Wen B. Wen
Comcast Comcast
January 06, 2021 January 29, 2021
Path Computation Element Communication Protocol (PCEP) Extensions for Path Computation Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-10 draft-ietf-pce-association-bidir-11
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multiprotocol The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. (LSPs) using PCEP.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 10, 2021. This Internet-Draft will expire on August 2, 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 11, line 13 skipping to change at page 11, line 13
((Object-Class value 40). A member of the Bidirectional LSP ((Object-Class value 40). A member of the Bidirectional LSP
Association can take the role of a forward or reverse LSP and follows Association can take the role of a forward or reverse LSP and follows
the following rules: the following rules:
o An LSP (forward or reverse) MUST NOT be part of more than one o An LSP (forward or reverse) MUST NOT be part of more than one
Bidirectional LSP Association. Bidirectional LSP Association.
o The LSPs in a Bidirectional LSP Association MUST have matching o The LSPs in a Bidirectional LSP Association MUST have matching
endpoint nodes in the reverse directions. endpoint nodes in the reverse directions.
o The Tunnel (as defined in [RFC3209]) of forward and reverse LSPs o The Tunnel (as defined in [RFC3209]) containing the forward and
of the Single-sided Bidirectional LSP Association on the reverse LSPs of the Single-sided Bidirectional LSP Association on
originating endpoint node MUST be the same, albeit with reverse the originating node MUST have the same LSP parameters (as
endpoint nodes. described in section 3.1.1 of [RFC3209]), albeit both LSPs have
reversed endpoint nodes.
The Bidirectional LSP Association types are considered to be both The Bidirectional LSP Association types are considered to be both
dynamic and operator-configured in nature. As per [RFC8697], the dynamic and operator-configured in nature. As per [RFC8697], the
association group could be manually created by the operator on the association group could be manually created by the operator on the
PCEP peers, and the LSPs belonging to this association are conveyed PCEP peers, and the LSPs belonging to this association are conveyed
via PCEP messages to the PCEP peer; alternately, the association via PCEP messages to the PCEP peer; alternately, the association
group could be created dynamically by the PCEP speaker, and both the group could be created dynamically by the PCEP speaker, and both the
association group information and the LSPs belonging to the association group information and the LSPs belonging to the
association group are conveyed to the PCEP peer. The Operator- association group are conveyed to the PCEP peer. The Operator-
configured Association Range MUST be set for this association-type to configured Association Range MUST be set for this association-type to
skipping to change at page 12, line 7 skipping to change at page 12, line 7
the Association Types supported by a PCEP speaker by defining an the Association Types supported by a PCEP speaker by defining an
ASSOC-Type-List TLV to be carried within an OPEN Object. This ASSOC-Type-List TLV to be carried within an OPEN Object. This
capability exchange for the Bidirectional LSP Association Types MUST capability exchange for the Bidirectional LSP Association Types MUST
be done before using the Bidirectional LSP Association. Thus, the be done before using the Bidirectional LSP Association. Thus, the
PCEP speaker MUST include the Bidirectional LSP Association Types in PCEP speaker MUST include the Bidirectional LSP Association Types in
the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer
before using the Bidirectional LSP Association in PCEP messages. before using the Bidirectional LSP Association in PCEP messages.
4.2. Bidirectional LSP Association Group TLV 4.2. Bidirectional LSP Association Group TLV
The "Bidirectional LSP Association Group TLV" an OPTIONAL TLV for use The "Bidirectional LSP Association Group TLV" is an OPTIONAL TLV for
with the Bidirectional LSP Associations (ASSOCIATION Object with use with the Bidirectional LSP Associations (ASSOCIATION Object with
Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for Association Type TBD1 for Single-sided Bidirectional LSP or TBD2 for
Double-sided Bidirectional LSP). Double-sided Bidirectional LSP).
o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV o The "Bidirectional LSP Association Group TLV" follows the PCEP TLV
format from [RFC5440]. format from [RFC5440].
o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA. o The Type (16 bits) of the TLV is TBD3, to be assigned by IANA.
o The Length is 4 Bytes. o The Length is 4 Bytes.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
Double-sided Bidirectional LSP Association, there is no change in the Double-sided Bidirectional LSP Association, there is no change in the
PLSP-ID allocation procedure. PLSP-ID allocation procedure.
For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231] For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV [RFC8231]
MUST be included in all forward and reverse LSPs. MUST be included in all forward and reverse LSPs.
5.6. State Synchronization 5.6. State Synchronization
During state synchronization, a PCC MUST report all the existing During state synchronization, a PCC MUST report all the existing
Bidirectional LSP Associations to the Stateful PCE as per [RFC8697]. Bidirectional LSP Associations to the Stateful PCE as per [RFC8697].
After the state synchronization, the PCE MUST remove all stale After the state synchronization, the PCE MUST remove all previous
Bidirectional LSP Associations. Bidirectional LSP Associations absent in the report.
5.7. Error Handling 5.7. Error Handling
If a PCE speaker receives an LSP with a Bidirectional LSP Association If a PCE speaker receives an LSP with a Bidirectional LSP Association
Type that it does not support, the PCE speaker MUST send PCErr with Type that it does not support, the PCE speaker MUST send PCErr with
Error-Type = 26 (Association Error) and Error-Value = 1 (Association Error-Type = 26 (Association Error) and Error-Value = 1 (Association
Type is not supported). Type is not supported).
An LSP (forward or reverse) cannot be part of more than one An LSP (forward or reverse) cannot be part of more than one
Bidirectional LSP Association. If a PCE speaker receives an LSP not Bidirectional LSP Association. If a PCE speaker receives an LSP not
skipping to change at page 18, line 8 skipping to change at page 18, line 8
The security considerations described in [RFC5440], [RFC8231], and The security considerations described in [RFC5440], [RFC8231], and
[RFC8281] apply to the extensions defined in this document as well. [RFC8281] apply to the extensions defined in this document as well.
Two new Association Types for the ASSOCIATION Object, Single-sided Two new Association Types for the ASSOCIATION Object, Single-sided
Bidirectional LSP Association and Double-sided Bidirectional LSP Bidirectional LSP Association and Double-sided Bidirectional LSP
Association are introduced in this document. Additional security Association are introduced in this document. Additional security
considerations related to LSP associations due to a malicious PCEP considerations related to LSP associations due to a malicious PCEP
speaker is described in [RFC8697] and apply to these Association speaker is described in [RFC8697] and apply to these Association
Types. Hence, securing the PCEP session using Transport Layer Types. Hence, securing the PCEP session using Transport Layer
Security (TLS) [RFC8253] is recommended. Security (TLS) [RFC8253] is RECOMMENDED.
8. Manageability Considerations 8. Manageability Considerations
8.1. Control of Function and Policy 8.1. Control of Function and Policy
The mechanisms defined in this document do not imply any control or The 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].
8.2. Information and Data Models 8.2. Information and Data Models
skipping to change at page 22, line 22 skipping to change at page 22, line 22
2020. 2020.
[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-15 (work in progress), October 2020. yang-15 (work in progress), October 2020.
[I-D.ietf-pce-sr-bidir-path] [I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"PCEP Extensions for Associated Bidirectional Segment "Path Computation Element Communication Protocol (PCEP)
Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-03 (work Extensions for Associated Bidirectional Segment Routing
in progress), September 2020. (SR) Paths", draft-ietf-pce-sr-bidir-path-05 (work in
progress), January 2021.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654, Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>. September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
skipping to change at page 23, line 14 skipping to change at page 23, line 14
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
Acknowledgments Acknowledgments
The authors would like to thank Dhruv Dhody for various discussions The authors would like to thank Dhruv Dhody for various discussions
on association groups and inputs to this document. The authors would on association groups and inputs to this document. The authors would
also like to thank Mike Taillon, Harish Sitaraman, and Marina Fizgeer also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and
for reviewing this document and providing valuable comments. Marina Fizgeer for reviewing this document and providing valuable
comments.
Authors' Addresses Authors' Addresses
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Canada Canada
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Colby Barth Colby Barth
 End of changes. 10 change blocks. 
18 lines changed or deleted 21 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/