[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

PCE Working Group                                          D. Dhody, Ed.
Internet-Draft                                       Huawei Technologies
Updates: 8231 (if approved)                                 S. Litkowski
Intended status: Standards Track                                  Orange
Expires: September 2, 2018                                 March 1, 2018


Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
                draft-dhody-pce-stateful-pce-optional-00

Abstract

   This document introduces a mechanism to mark some Path Computation
   Element (PCE) Communication Protocol (PCEP) objects as optional
   during PCEP messages exchange for the Stateful PCE model to allow
   relaxing some constraints.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 2, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Dhody & Litkowski       Expires September 2, 2018               [Page 1]


Internet-Draft                STATEFUL-OPT                    March 2018


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Usage Example . . . . . . . . . . . . . . . . . . . . . .   3
   3.  PCEP Extension  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .   4
     3.2.  Handling of P flag  . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  The PCRpt message . . . . . . . . . . . . . . . . . .   4
       3.2.2.  The PCUpd message and the PCInitiate message  . . . .   5
     3.3.  Handling of I flag  . . . . . . . . . . . . . . . . . . .   5
       3.3.1.  The PCUpd message . . . . . . . . . . . . . . . . . .   5
       3.3.2.  The PCRpt message . . . . . . . . . . . . . . . . . .   5
       3.3.3.  The PCInitiate message  . . . . . . . . . . . . . . .   6
     3.4.  Unknown Object Handling . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .   6
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .   7
     6.1.  Control of Function and Policy  . . . . . . . . . . . . .   7
     6.2.  Information and Data Models . . . . . . . . . . . . . . .   7
     6.3.  Liveness Detection and Monitoring . . . . . . . . . . . .   7
     6.4.  Verify Correct Operations . . . . . . . . . . . . . . . .   7
     6.5.  Requirements On Other Protocols . . . . . . . . . . . . .   7
     6.6.  Impact On Network Operations  . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [RFC5440] describes the Path Computation Element communication
   Protocol (PCEP) which enables the communication between a Path
   Computation Client (PCC) and a Path Control Element (PCE), or between
   two PCEs based on the PCE architecture [RFC4655].

   PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
   extensions to PCEP to enable active control of Multiprotocol Label
   Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS)
   tunnels.  [RFC8281] describes the setup and teardown of PCE-initiated
   LSPs under the active stateful PCE model, without the need for local
   configuration on the PCC, thus allowing for a dynamic network.

   [RFC5440] defined P flag (Processing-Rule) as part of Common Object
   Header to allow a PCC to specify in a PCReq message sent to a PCE
   whether the object must be taken into account by the PCE during path



Dhody & Litkowski       Expires September 2, 2018               [Page 2]


Internet-Draft                STATEFUL-OPT                    March 2018


   computation or is just optional.  The I flag (Ignore) is used by a
   PCE in a PCRep message to indicate to a PCC whether or not an
   optional object was processed.  Stateful PCE [RFC8231] specified that
   P and I flags of the PCEP objects defined in [RFC8231] is to be set
   to 0 on transmission and ignored on receipt since they are
   exclusively related to path computation requests.  The behavior for P
   and I flag in other objects defined in [RFC5440] and other extension
   was not specified.  This document clarifies how the P and I flag
   could be used in the stateful PCE model to identify optional objects
   in the Path Computation State Report (PCRpt), the Path Computation
   Update Request (PCUpd) and the LSP Initiate Request (PCInitiate)
   message.

   This document updates [RFC8231] with respect to usage of P and I flag
   as well as handling of unknown objects in stateful PCEP message
   exchanges.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Overview

   [RFC5440] describes the handling on unknown objects as per the
   setting of the P flag for the PCReq message.  Further [RFC8231]
   defined the usage of LSP Error Code TLV in PCRpt message in response
   to failed LSP Update Request via PCUpd message (for example, due to
   an unsupported object or a TLV).

   This document clarifies the procedure for marking some objects as
   optional to be processed by the PCEP peer in the stateful PCEP
   messages.  Further this document updates the procedure for handling
   unknown objects in the stateful PCEP messages based on the P flag.

2.1.  Usage Example

   The PCRpt message is used to report the current state of an LSP.  As
   part of the message both the <intended-attribute-list> and <actual-
   attribute-list> is encoded.  The <intended-attribute-list> could
   include the METRIC object to indicate a limiting constraint (B flag
   set) for the Path Delay Variation metric [RFC8233].  In some
   scenarios it would be useful to state that this limiting constraint
   can be relaxed by the PCE, in case it cannot find a path.  Similarly
   in case of an association groups [I-D.ietf-pce-association-group]



Dhody & Litkowski       Expires September 2, 2018               [Page 3]


Internet-Draft                STATEFUL-OPT                    March 2018


   such as Disjoint Association [I-D.ietf-pce-association-diversity],
   the PCE may need to completely relax the disjointness constraint in
   order to provide a path to all the LSPs that are part of the
   association.  In these case it would be useful mark the objects as
   optional and could be ignored by the PCEP peer.  Also it would be
   used for the PCEP speaker to learn if the PCEP peer has relaxed the
   constraint and ignored the processing of the PCEP object.

   Thus, this document simply clarifies how the already existing P and I
   flag in PCEP common object header could be used during stateful PCEP
   exchanges.

3.  PCEP Extension

3.1.  STATEFUL-PCE-CAPABILITY TLV

   A PCEP speaker indicates its ability to support for handling P and I
   flag during the stateful PCEP message exchanges during the PCEP
   initialization phase, as follows.  When the PCEP session is created,
   it sends an Open message with an OPEN object that contains the
   STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231].  A new flag,
   the R (RELAX) flag, is introduced to this TLV to indicate support for
   relaxing the processing of some objects via the use of P and I flag
   in PCEP common object header.

   R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
   indicates that the PCEP Speaker is willing to send and receive PCEP
   objects with handling of P and I flags in the PCEP common object
   header.  In case the bit is unset, it indicates that the PCEP Speaker
   would not handle P and I flags in the PCEP common object header.

   The R flag must be set by both a PCC and a PCE for handling of P and
   I flag in the PCEP common object header to allow relaxing some
   constraints by marking objects as optional to process.  If the PCEP
   speaker that did not set R flag but receives PCEP objects with P or I
   bit set, would behave as per the processing rule in [RFC8231].

3.2.  Handling of P flag

3.2.1.  The PCRpt message

   The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
   a PCE whether the object must be taken into account by the PCE
   (during path computation or re-optimization) or is just optional.
   When the P flag is set, the object MUST be taken into account by the
   PCE.  Conversely, when the P flag is cleared, the object is optional
   and the PCE is free to ignore it.  The P flag for the mandatory
   objects LSP and ERO (intended path) MUST be set in the PCRpt message.



Dhody & Litkowski       Expires September 2, 2018               [Page 4]


Internet-Draft                STATEFUL-OPT                    March 2018


   If the mandatory object is received with the P flag set incorrectly
   according to the rules stated above, the receiving peer MUST send a
   PCErr message with Error-Type=10 (Reception of an invalid object) and
   Error-value=1 (reception of an object with P flag not set).  By
   default, the PCC SHOULD set the P flag, unless a local configuration
   or local policy indicates that some constraints (corresponding PCEP
   objects) can be marked as optional and could be ignored by the PCE.

3.2.2.  The PCUpd message and the PCInitiate message

   The P flag in the PCUpd message [RFC8231] and the PCInitiate message
   [RFC8281] allows a PCE to specify to a PCC whether the object must be
   taken into account by the PCC (during path setup) or is just
   optional.  When the P flag is set, the object MUST be taken into
   account by the PCC.  Conversely, when the P flag is cleared, the
   object is optional and the PCC is free to ignore it.  The P flag for
   the mandatory objects SRP, LSP and ERO (intended path) MUST be set in
   the PCUpd message.  If the mandatory object is received with the P
   flag set incorrectly according to the rules stated above, the
   receiving peer MUST send a PCErr message with Error-Type=10
   (Reception of an invalid object) and Error-value=1 (reception of an
   object with P flag not set).  By default, the PCE SHOULD set the P
   flag, unless a local configuration or local policy indicates that
   some constraints (corresponding PCEP objects) can be marked as
   optional and could be ignored by the PCC.

3.3.  Handling of I flag

3.3.1.  The PCUpd message

   The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
   a PCC whether or not an optional object was processed.  The PCE MAY
   include the ignored optional object in its update request and set the
   I flag to indicate that the optional object was ignored.  When the I
   flag is cleared, the PCE indicates that the optional object was
   processed.  Note that for the delegated LSPs, the PCE can update and
   mark some object as ignored even when the PCC had set the P flag
   during delegation.

3.3.2.  The PCRpt message

   The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to
   a PCE whether or not an optional object was processed in response to
   an LSP Update Request.  The PCC MAY include the ignored optional
   object in its report and set the I flag to indicate that the optional
   object was ignored at PCC.  When the I flag is cleared, the PCC
   indicates that the optional object was processed.  The I flag has no




Dhody & Litkowski       Expires September 2, 2018               [Page 5]


Internet-Draft                STATEFUL-OPT                    March 2018


   meaning if the PCRpt message is not in response to a PCUpd or
   PCInitiate message.

3.3.3.  The PCInitiate message

   The I flag has no meaning in the PCinitiate message [RFC8281].

3.4.  Unknown Object Handling

   This document updates the handling of unknown objects in stateful
   PCEP messages as per the setting of P flag in the common object
   header in a similar way as [RFC5440], i.e. if a PCEP speaker does not
   understand an object with the P flag set or understands the object
   but decides to ignore the object, the entire stateful PCEP message
   MUST be rejected and the PCE MUST send a PCErr message with Error-
   Type="Unknown Object" or "Not supported Object" [RFC5440].  In case
   the P flag is not set, the PCEP speaker is free to ignore the object
   and continue with the message processing as defined.

   [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message
   in the LSP object to convey error information.  This document does
   not change that impact that procedure.

4.  Security Considerations

   This documents clarifies how the already existing P and I flag in
   PCEP common object header could be used during stateful PCEP
   exchanges.  It updates the unknown object error handling in stateful
   PCEP message exchange.  These changes on its own do not add any new
   security concerns.  The security considerations identified in
   [RFC5440], [RFC8231], and [RFC8281].

   As stated in [RFC6952], PCEP implementations SHOULD support the TCP-
   AO [RFC5925] and not use TCP MD5 because of TCP MD5's known
   vulnerabilities and weakness.  PCEP also support Transport Layer
   Security (TLS) [RFC8253] as per the recommendations and best current
   practices in [RFC7525].

5.  IANA Considerations

5.1.  STATEFUL-PCE-CAPABILITY TLV

   [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA
   created a registry to manage the value of the STATEFUL-PCE-CAPABILITY
   TLV's Flag field.  IANA has allocated a new bit in the STATEFUL-PCE-
   CAPABILITY TLV Flag Field registry, as follows:





Dhody & Litkowski       Expires September 2, 2018               [Page 6]


Internet-Draft                STATEFUL-OPT                    March 2018


   Bit       Description                 Reference
   -------------------------------------------------
   TBD1      RELAX bit                   [This I.D.]

6.  Manageability Considerations

6.1.  Control of Function and Policy

   An operator MUST be allowed to configure the capability to support
   relaxation of constraints in the stateful PCEP message exchange.
   They SHOULD also allow configuration of related LSP constraints (or
   parameters) that are optional to process.

6.2.  Information and Data Models

   An implementation SHOULD allow the operator to view the capability
   defined in this document.  To serve this purpose, the PCEP YANG
   module [I-D.ietf-pce-pcep-yang] could be extended.

6.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

6.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

6.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

6.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

7.  References

7.1.  Normative References







Dhody & Litkowski       Expires September 2, 2018               [Page 7]


Internet-Draft                STATEFUL-OPT                    March 2018


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

7.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <https://www.rfc-editor.org/info/rfc6952>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC8233]  Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) to Compute Service-Aware Label Switched
              Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
              2017, <https://www.rfc-editor.org/info/rfc8233>.



Dhody & Litkowski       Expires September 2, 2018               [Page 8]


Internet-Draft                STATEFUL-OPT                    March 2018


   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
              YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", draft-ietf-pce-pcep-
              yang-06 (work in progress), January 2018.

   [I-D.ietf-pce-association-diversity]
              Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody,
              "Path Computation Element communication Protocol extension
              for signaling LSP diversity constraint", draft-ietf-pce-
              association-diversity-03 (work in progress), February
              2018.

   [I-D.ietf-pce-association-group]
              Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "PCEP Extensions for
              Establishing Relationships Between Sets of LSPs", draft-
              ietf-pce-association-group-04 (work in progress), August
              2017.

Authors' Addresses

   Dhruv Dhody (editor)
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com


   Stephane Litkowski
   Orange

   EMail: stephane.litkowski@orange.com




Dhody & Litkowski       Expires September 2, 2018               [Page 9]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/