draft-ietf-pce-stateful-pce-17.txt   draft-ietf-pce-stateful-pce-18.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: May 20, 2017 Google, Inc. Expires: June 5, 2017 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
November 16, 2016 December 2, 2016
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-17 draft-ietf-pce-stateful-pce-18
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.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across control of timing and sequence of path computations within and across
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 20, 2017. This Internet-Draft will expire on June 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 18, line 11 skipping to change at page 18, line 11
Redelegation Timeout Interval and MAY be set to infinity (meaning Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact). set by the PCE, they will remain intact).
5.7.3. Returning a Delegation 5.7.3. Returning a Delegation
In order to keep a delegation, a PCE MUST set the Delegate flag to 1 In order to keep a delegation, a PCE MUST set the Delegate flag to 1
on each LSP Update Request sent to the PCC. A PCE that no longer on each LSP Update Request sent to the PCC. A PCE that no longer
wishes to update an LSP's parameters SHOULD return the LSP delegation wishes to update an LSP's parameters SHOULD return the LSP delegation
back to the PCC by sending an empty LSP Update Request which has the back to the PCC by sending an empty LSP Update Request which has the
Delegate flag set to 0. If a PCC receives a non-empty LSP Update Delegate flag set to 0. If a PCC receives an LSP Update Request with
Request with the Delegate flag set to 0, it MUST treat this as a the Delegate flag set to 0 (whether the LSP Update Request is empty
delegation return. or not), it MUST treat this as a delegation return.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| LSP delegated |---PCRpt, Delegate=1--->| LSP delegated
| . | | . |
| . | | . |
| . | | . |
|<--PCUpd, Delegate=0----| Delegation returned |<--PCUpd, Delegate=0----| Delegation returned
skipping to change at page 19, line 29 skipping to change at page 19, line 29
the delegation state and the LSP state are kept intact. the delegation state and the LSP state are kept intact.
If the PCE crashes but does not recover within the Redelegation If the PCE crashes but does not recover within the Redelegation
Timeout, the delegation state is returned to the PCC. If the PCC can Timeout, the delegation state is returned to the PCC. If the PCC can
redelegate the LSPs to another PCE, and that PCE accepts the redelegate the LSPs to another PCE, and that PCE accepts the
delegations, there will be no change in LSP state. If the PCC cannot delegations, there will be no change in LSP state. If the PCC cannot
redelegate the LSPs to another PCE, then upon expiration of the State redelegate the LSPs to another PCE, then upon expiration of the State
Timeout Interval, the state set by the PCE is flushed, which may Timeout Interval, the state set by the PCE is flushed, which may
cause change in the LSP state. Note that an operator may choose to cause change in the LSP state. Note that an operator may choose to
use an infinite State Timeout Interval if he wishes to maintain the use an infinite State Timeout Interval if he wishes to maintain the
PCE state indefinetely. Note also that flushing the state should be PCE state indefinitely. Note also that flushing the state should be
implemented using make-before-break to avoid traffic loss. implemented using make-before-break to avoid traffic loss.
If there is a standby PCE, the Redelegation Timeout may be set to 0 If there is a standby PCE, the Redelegation Timeout may be set to 0
through policy on the PCC, causing the LSPs to be redelegated through policy on the PCC, causing the LSPs to be redelegated
immediately to the PCC, which can delegate them immediately to the immediately to the PCC, which can delegate them immediately to the
standby PCE. Assuming the State Timeout Interval is greater than the standby PCE. Assuming the State Timeout Interval is greater than the
Redelegation Timeout, and assuming the standby PCE takes similar Redelegation Timeout, and assuming the standby PCE takes similar
decisions as the failed PCE, the LSP state will be kept intact. decisions as the failed PCE, the LSP state will be kept intact.
5.8. LSP Operations 5.8. LSP Operations
skipping to change at page 24, line 17 skipping to change at page 24, line 17
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE, or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is to be assigned by IANA. for the PCRpt message is to be assigned by IANA.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
Where: Where:
<path>::= <intended_path> <path>::= <intended_path>
[<actual_attribute_list><actual_path>] [<actual_attribute_list><actual_path>]
<intended_attribute_list> <intended_attribute_list>
<actual_attribute-list>::=[<BANDWIDTH>] <actual_attribute-list>::=[<BANDWIDTH>]
[<metric-list>] [<metric-list>]
Where: Where:
<intended_path> is represented by the ERO object defined in <intended_path> is represented by the ERO object defined in
section 7.9 of [RFC5440]. section 7.9 of [RFC5440].
<actual_attribute_list> consists of the actual computed and signaled values <actual_attribute_list> consists of the actual computed and
of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440]. signaled values of the <BANDWIDTH> and <metric-lists> objects
<actual_path> is represented by the RRO object defined in defined in [RFC5440].
section 7.10 of [RFC5440]. <actual_path> is represented by the RRO object defined in
<intended_attribute_list> is the attribute-list defined in section 7.10 of [RFC5440].
section 6.5 of [RFC5440] and extended by PCEP extensions. <intended_attribute_list> is the attribute-list defined in
section 6.5 of [RFC5440] and extended by PCEP extensions.
The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message
is not in response to a PCupd message, the SRP object MAY be omitted. is not in response to a PCupd message, the SRP object MAY be omitted.
When the PCC does not include the SRP object, the PCE MUST treat this When the PCC does not include the SRP object, the PCE MUST treat this
as an SRP object with an SRP-ID-number equal to the reserved value as an SRP object with an SRP-ID-number equal to the reserved value
0x00000000. The reserved value 0x00000000 indicates that the state 0x00000000. The reserved value 0x00000000 indicates that the state
reported is not as a result of processing a PCUpd message. reported is not as a result of processing a PCUpd message.
If the PCRpt message is in response to a PCUpd message, the SRP If the PCRpt message is in response to a PCUpd message, the SRP
object MUST be included and the value of the SRP-ID-number in the SRP object MUST be included and the value of the SRP-ID-number in the SRP
skipping to change at page 25, line 26 skipping to change at page 25, line 29
in each LSP State Report on the PCRpt message. If the LSP object is in each LSP State Report on the PCRpt message. If the LSP object is
missing, the receiving PCE MUST send a PCErr message with Error- missing, the receiving PCE MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value to be assigned by type=6 (Mandatory Object missing) and Error-value to be assigned by
IANA (LSP object missing). IANA (LSP object missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The intended path, represented by the ERO object, is REQUIRED. If The intended path, represented by the ERO object, is REQUIRED. If
the ERO ojbect is missing, the receiving PCE MUST send a PCErr the ERO object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 (Mandatory Object missing) and Error-value message with Error-type=6 (Mandatory Object missing) and Error-value
to be assigned by IANA (ERO object missing). The ERO may be empty if to be assigned by IANA (ERO object missing). The ERO may be empty if
the PCE does not have a path for a delegated LSP. the PCE does not have a path for a delegated LSP.
The actual path, represented by the RRO object, SHOULD be included in The actual path, represented by the RRO object, SHOULD be included in
PCRpt by the PCC when the path is up or active, but MAY be omitted if PCRpt by the PCC when the path is up or active, but MAY be omitted if
the path is down due to a signaling error or another failure. the path is down due to a signaling error or another failure.
The intended_attribute_list maps to the attribute_list in Section 6.5 The intended_attribute_list maps to the attribute_list in Section 6.5
of [RFC5440] and is used to convey the requested parameters of the of [RFC5440] and is used to convey the requested parameters of the
skipping to change at page 49, line 14 skipping to change at page 49, line 14
12. Acknowledgements 12. Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria and Ramon We would like to thank Adrian Farrel, Cyril Margaria and Ramon
Casellas for their contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga,
Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky,
Ambrose Kwong, Ashwin Sampath and Calvin Ying for helpful comments Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui,
and discussions. Stephane Litkowski and Olivier Dugeon for helpful comments and
discussions.
13. References 13. References
13.1. Normative References 13.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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 13 change blocks. 
33 lines changed or deleted 35 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/