draft-ietf-pce-association-bidir-01.txt   draft-ietf-pce-association-bidir-02.txt 
PCE Working Group C. Barth PCE Working Group C. Barth
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Gandhi, Ed. Intended status: Standards Track R. Gandhi, Ed.
Expires: November 19, 2018 Cisco Systems, Inc. Expires: May 18, 2019 Cisco Systems, Inc.
B. Wen B. Wen
Comcast Comcast
May 18, 2018 November 14, 2018
PCEP Extensions for PCEP Extensions for
Associated Bidirectional Label Switched Paths (LSPs) Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-01 draft-ietf-pce-association-bidir-02
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 2, line 32 skipping to change at page 2, line 32
3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5 3.1. Single-sided Initiation . . . . . . . . . . . . . . . . . 5
3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6 3.2. Double-sided Initiation . . . . . . . . . . . . . . . . . 6
3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7 3.3. Co-routed Associated Bidirectional LSP . . . . . . . . . . 7
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8
4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8 4.1. Association Object . . . . . . . . . . . . . . . . . . . . 8
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9 4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9
5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10 5. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 5.1. PCE Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10
5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10 5.2. PCC Initiated LSPs . . . . . . . . . . . . . . . . . . . . 10
5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Stateless PCE . . . . . . . . . . . . . . . . . . . . . . 11
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 5.4. Bidirectional (B) Flag . . . . . . . . . . . . . . . . . . 11
5.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11 5.5. State Synchronization . . . . . . . . . . . . . . . . . . 11
5.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Manageability Considerations . . . . . . . . . . . . . . . . . 12 7. Manageability Considerations . . . . . . . . . . . . . . . . . 12
7.1. Control of Function and Policy . . . . . . . . . . . . . . 12 7.1. Control of Function and Policy . . . . . . . . . . . . . . 12
7.2. Information and Data Models . . . . . . . . . . . . . . . 12 7.2. Information and Data Models . . . . . . . . . . . . . . . 12
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13 8.1. Association Types . . . . . . . . . . . . . . . . . . . . 13
8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13 8.2. Bidirectional LSP Association Group TLV . . . . . . . . . 13
8.2.1. Flag Fields in Bidirectional LSP Association Group 8.2.1. Flag Fields in Bidirectional LSP Association Group
TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP) as a [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
skipping to change at page 4, line 35 skipping to change at page 4, line 39
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology defined in The reader is assumed to be familiar with the terminology defined in
[RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association]. [RFC5440], [RFC7551], [RFC8231], and [I-D.ietf-pce-association].
The term forward and reverse direction of an LSP is from the view
point of a PCE.
3. Overview 3. Overview
As shown in Figure 1, two reverse unidirectional LSPs can be grouped As shown in Figure 1, two reverse unidirectional LSPs can be grouped
to form an associated bidirectional LSP. There are two methods of to form an associated bidirectional LSP. There are two methods of
initiating the bidirectional LSP association, single-sided and initiating the bidirectional LSP association, single-sided and
double-sided, as defined in [RFC7551] and described in the following double-sided, as defined in [RFC7551] and described in the following
sections. sections.
LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 --> LSP1 -->
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
skipping to change at page 10, line 28 skipping to change at page 10, line 28
compute bidirectional paths of the forward and reverse LSPs of a compute bidirectional paths of the forward and reverse LSPs of a
co-routed bidirectional LSP. co-routed bidirectional LSP.
The Reserved flags MUST be set to 0 when sent and MUST be ignored The Reserved flags MUST be set to 0 when sent and MUST be ignored
when received. when received.
5. PCEP Procedure 5. PCEP Procedure
5.1. PCE Initiated LSPs 5.1. PCE Initiated LSPs
As specified in [I-D.ietf-pce-association], Bidirectional LSP As specified in [I-D.ietf-pce-association], the Bidirectional LSP
Association Groups can be created by a Stateful PCE. Association Groups can be created by a Stateful PCE.
o Stateful PCE can create and update the forward and reverse LSPs o Stateful PCE can create and update the forward and reverse LSPs
independently for both single-sided and double-sided bidirectional independently for both single-sided and double-sided bidirectional
LSP association groups. LSP association groups.
o Stateful PCE can establish and remove the association relationship o Stateful PCE can establish and remove the association relationship
on a per LSP basis. on a per LSP basis.
o Stateful PCE can create and update the LSP and the association on o Stateful PCE can create and update the LSP and the association on
skipping to change at page 11, line 31 skipping to change at page 11, line 31
5.3. Stateless PCE 5.3. Stateless PCE
For a stateless PCE, it might be useful to associate a path For a stateless PCE, it might be useful to associate a path
computation request to an association group, thus enabling it to computation request to an association group, thus enabling it to
associate a common set of configuration parameters or behaviors with associate a common set of configuration parameters or behaviors with
the request. A PCC can request co-routed or non co-routed forward the request. A PCC can request co-routed or non co-routed forward
and reverse direction paths from a stateless PCE for a bidirectional and reverse direction paths from a stateless PCE for a bidirectional
LSP association group. LSP association group.
5.4. State Synchronization 5.4. Bidirectional (B) Flag
As defined in [RFC5440], the Bidirectional (B) flag in the Request
Parameters (RP) object is set when the PCC specifies that the path
computation request is for a bidirectional TE LSP with the same TE
requirements (e.g. latency) in each direction. For an associated
bidirectional LSP, the B-flag MAY be set when the PCC makes the path
computation request for the same TE requirements in the forward and
reverse directions. When a stateful PCE initiates or updates the
bidirectional LSPs, the B-flag in Stateful PCE Request Parameters
(SRP) object [RFC8231] MAY also be set.
5.5. State Synchronization
During state synchronization, a PCC MUST report all the existing During state synchronization, a PCC MUST report all the existing
bidirectional LSP association groups to the Stateful PCE as per bidirectional LSP association groups to the Stateful PCE as per
[I-D.ietf-pce-association]. After the state synchronization, the PCE [I-D.ietf-pce-association]. After the state synchronization, the PCE
MUST remove all stale bidirectional LSP associations. MUST remove all stale bidirectional LSP associations.
5.5. Error Handling 5.6. Error Handling
An LSP (forward or reverse) can not be part of more than one An LSP (forward or reverse) can not be part of more than one
Bidirectional LSP Association Group. If a PCE attempts to add an LSP Bidirectional LSP Association Group. If a PCE attempts to add an LSP
not complying to this rule, the PCC MUST send PCErr with Error-Type = not complying to this rule, the PCC MUST send PCErr with Error-Type =
29 (Early allocation by IANA) (Association Error) and Error-Value = 29 (Early allocation by IANA) (Association Error) and Error-Value =
TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if TBD4 (Bidirectional LSP Association - Group Mismatch). Similarly, if
a PCC attempts to add an LSP at PCE not complying to this rule, the a PCC attempts to add an LSP at PCE not complying to this rule, the
PCE MUST send this PCErr. PCE MUST send this PCErr.
The LSPs (forward or reverse) in a single-sided bidirectional LSP The LSPs (forward or reverse) in a single-sided bidirectional LSP
association group MUST belong to the same TE Tunnel (as defined in association group MUST belong to the same TE Tunnel (as defined in
skipping to change at page 12, line 36 skipping to change at page 12, line 48
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].
7.2. Information and Data Models 7.2. Information and Data Models
[RFC7420] describes the PCEP MIB, there are no new MIB Objects [RFC7420] describes the PCEP MIB, there are no new MIB Objects
defined for LSP associations. defined for LSP associations.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] supports LSP The PCEP YANG module [I-D.ietf-pce-pcep-yang] defines data model for
associations. LSP associations.
7.3. Liveness Detection and Monitoring 7.3. Liveness Detection and Monitoring
The mechanisms defined in this document do not imply any new liveness The mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440], [RFC8231], and [RFC8281]. listed in [RFC5440], [RFC8231], and [RFC8281].
7.4. Verify Correct Operations 7.4. Verify Correct Operations
The mechanisms defined in this document do not imply any new The mechanisms defined in this document do not imply any new
skipping to change at page 17, line 8 skipping to change at page 17, line 8
8253, October 2017. 8253, October 2017.
[I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J.
Tantsura, "A YANG Data Model for Path Computation Element Tantsura, "A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang
(work in progress). (work in progress).
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. The authors would also like to thank Dhruv on association groups and inputs to this document. The authors would
Dhody and Mike Taillon for reviewing this document and providing also like to thank Dhruv Dhody and Mike Taillon for reviewing this
valuable comments. document and providing valuable comments.
Authors' Addresses Authors' Addresses
Colby Barth Colby Barth
Juniper Networks Juniper Networks
Email: cbarth@juniper.net Email: cbarth@juniper.net
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 12 change blocks. 
17 lines changed or deleted 32 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/