[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sivabalan-pce-lsp-setup-type) 00 01 02 03 04 05 06 07 08 09 10

PCE Working Group                                           S. Sivabalan
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                             J. Tantsura
Expires: November 5, 2018                                 Nuage Networks
                                                                I. Minei
                                                            Google, Inc.
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                             J. Hardwick
                                                     Metaswitch Networks
                                                             May 4, 2018


               Conveying path setup type in PCEP messages
                    draft-ietf-pce-lsp-setup-type-10

Abstract

   A Path Computation Element (PCE) can compute Traffic Engineering (TE)
   paths through a network that are subject to various constraints.
   Currently, TE paths are Label Switched Paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to the PCE communication protocol (PCEP) to
   allow support for different path setup methods over a given PCEP
   session.

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 November 5, 2018.








Sivabalan, et al.       Expires November 5, 2018                [Page 1]


Internet-Draft             PCE path setup type                  May 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Path Setup Type Capability TLV  . . . . . . . . . . . . . . .   4
   4.  Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . .   6
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .   9
     8.2.  New Path Setup Type Registry  . . . . . . . . . . . . . .   9
     8.3.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  10
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   [RFC5440] describes the Path Computation Element communication
   Protocol (PCEP) for communication between a Path Computation Client
   (PCC) and a Path Computation Element (PCE), or between a PCE and a
   PCE.  A PCC requests a path subject to various constraints and
   optimization criteria from a PCE.  The PCE responds to the PCC with a
   hop-by-hop path in an Explicit Route Object (ERO).  The PCC uses the
   ERO to set up the path in the network.

   [RFC8231] specifies extensions to PCEP that allow a PCC to delegate
   its LSPs to a PCE.  The PCE can then update the state of LSPs



Sivabalan, et al.       Expires November 5, 2018                [Page 2]


Internet-Draft             PCE path setup type                  May 2018


   delegated to it.  In particular, the PCE may modify the path of an
   LSP by sending a new ERO.  The PCC uses this ERO to re-route the LSP
   in a make-before-break fashion.  [RFC8281] specifies a mechanism
   allowing a PCE to dynamically instantiate an LSP on a PCC by sending
   the ERO and the characteristics of the LSP.  The PCC creates the LSP
   using the ERO and other attributes sent by the PCE.

   So far, PCEP and its extensions have assumed that the TE paths are
   label switched and are established via the RSVP-TE protocol.
   However, other methods of LSP setup are possible in the PCE
   architecture (see [RFC4655] and [RFC4657]).  This document
   generalizes PCEP to allow other LSP setup methods to be used.  It
   defines two new TLVs and specifies the base procedures to facilitate
   this, as follows.

   o  The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to
      announce which LSP setup methods it supports when the PCEP session
      is established.

   o  The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify
      which setup method should be used for a given LSP.  When multiple
      path setup types are deployed in a network, a given PCEP session
      may have to simultaneously support more than one path setup type.
      A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate
      the intended path setup type in the appropriate PCEP messages,
      unless the path setup type is RSVP-TE (which is assumed to be the
      path setup type if no other setup type is indicated).  This is so
      that both the PCC and the PCE can take the necessary steps to set
      up the path.

   This document defines a path setup type code for RSVP-TE.  When a new
   path setup type (other than RSVP-TE) is introduced for setting up a
   path, a path setup type code and, optionally, a sub-TLV pertaining to
   the new path setup type will be defined by the document that
   specifies the new path setup type.

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.








Sivabalan, et al.       Expires November 5, 2018                [Page 3]


Internet-Draft             PCE path setup type                  May 2018


2.  Terminology

   The following terminologies are used in this document:

   ERO:  Explicit Route Object.

   LSR:  Label Switching Router.

   PCC:  Path Computation Client.

   PCE:  Path Computation Element.

   PCEP:  Path Computation Element Protocol.

   PST:  Path Setup Type.

   TLV:  Type, Length, and Value.

3.  Path Setup Type Capability TLV

   A PCEP speaker indicates which PSTs it supports during the PCEP
   initialization phase, as follows.  When the PCEP session is created,
   it sends an Open message with an OPEN object containing the PATH-
   SETUP-TYPE-CAPABILITY TLV.  The format of this TLV is as follows.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type (TBD1)         |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved            |  Num of PSTs  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     PST#1     |      ...      |     PST#N     |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //               Optional sub-TLVs (variable)                  //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV

   The TLV type is TBD1 (to be assigned by IANA).  Its reserved field
   MUST be set to zero by the sender and MUST be ignored by the
   receiver.  The other fields in the TLV are as follows.

   Length:  The total length in bytes of the remainder of the TLV, that
      is, excluding the Type and Length fields.




Sivabalan, et al.       Expires November 5, 2018                [Page 4]


Internet-Draft             PCE path setup type                  May 2018


   Number of PSTs:  The number of PSTs in the following list, excluding
      padding.

   List of PSTs:  A list of the PSTs that the PCEP speaker supports.
      Each PST is a single byte in length.  Duplicate entries in this
      list MUST be ignored.  The PCEP speaker MUST pad the list with
      zeros so that it is a muliple of four bytes in length.  This
      document defines the following PST value:

      *  PST = 0: Path is setup using the RSVP-TE signaling protocol.

   Optional sub-TLVs:  A list of sub-TLVs associated with the supported
      PSTs.  Each PST has zero or one sub-TLVs associated with it, and
      each sub-TLV is associated with exactly one PST.  Each sub-TLV
      MUST obey the rules for TLV formatting defined in ([RFC5440]).
      That is, each sub-TLV is padded to a four byte alignment, and the
      length field of each sub-TLV does not include the padding bytes.
      This document does not define any sub-TLVs; an example can be
      found in [I-D.ietf-pce-segment-routing].

   A PCEP speaker MUST check that this TLV is correctly formatted, as
   follows.

   o  If there are no sub-TLVs, then the TLV length field MUST be equal
      to four bytes plus the size of the PST list, excluding any padding
      bytes.

   o  If there are sub-TLVs then the TLV Length field MUST be equal to
      four bytes plus the size of the PST list (rounded up to the
      nearest multiple of four) plus the size of the appended sub-TLVs
      excluding any padding bytes in the final sub-TLV.

   o  The Number of PSTs field MUST be greater than zero.

   If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV which
   violates these rules, then the PCEP speaker MUST send a PCErr message
   with Error-Type = 10 (Reception of an invalid object) and Error-Value
   = 11 (Malformed object) and MUST close the PCEP session.  The PCEP
   speaker MAY include the malformed OPEN object in the PCErr message as
   well.

   If a PCEP speaker receives an OPEN object with more than one PATH-
   SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first
   instance of this TLV.

   The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
   object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
   single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs.  A PCEP



Sivabalan, et al.       Expires November 5, 2018                [Page 5]


Internet-Draft             PCE path setup type                  May 2018


   speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST
   it supports is RSVP-TE.  If a PCEP speaker supports other PSTs
   besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE-
   CAPABILITY TLV in its OPEN object.

   If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
   TLV, it will ignore the TLV in accordance with [RFC5440].

4.  Path Setup Type TLV

   When a PCEP session is used to set up TE paths using different
   methods, the corresponding PCE and PCC must be aware of the path
   setup method used.  That means, a PCE must be able to specify paths
   in the correct format and a PCC must be able to take control plane
   and forwarding plane actions appropriate to the PST.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type (28)           |           Length (4)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved            |      PST      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: PATH-SETUP-TYPE TLV

   PATH-SETUP-TYPE TLV is an optional TLV associated with the RP
   ([RFC5440]) and the SRP ([RFC8231]) objects.  Its format is shown in
   the above figure.  The TLV type is 28.  Its reserved field MUST be
   set to zero.  The one byte value contains the PST as defined for the
   PATH-SETUP-TYPE-CAPABILITY TLV.

   The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-
   TYPE TLV with a PST value of 0 (RSVP-TE).  A PCEP speaker MAY omit
   the TLV if the PST is RSVP-TE.  If the RP or SRP object contains more
   than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed
   and the rest MUST be ignored.

   If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will
   ignore the TLV in accordance with [RFC5440], and will use RSVP-TE to
   set up the path.

5.  Operation

   During the PCEP initialization phase, if a PCEP speaker receives a
   PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST assume that the
   peer supports only the PSTs listed in the TLV.  If the PCEP speaker
   and its peer have no PSTs in common, then the PCEP speaker MUST send



Sivabalan, et al.       Expires November 5, 2018                [Page 6]


Internet-Draft             PCE path setup type                  May 2018


   a PCErr message with Error-Type = 21 (Invalid traffic engineering
   path setup type) and Error-Value = 2 (Mismatched path setup type) and
   close the PCEP session.

   If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
   speaker MUST infer that the peer supports path setup using at least
   RSVP-TE.  The PCEP speaker MAY also infer that the peer supports
   other path setup types, but the means of inference are outside the
   scope of this document.

   When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST
   include the PATH-SETUP-TYPE TLV in the RP object, unless the intended
   PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
   If the PCE is capable of expressing the path in a format appropriate
   to the intended PST, it MUST use the appropriate ERO format in the
   PCRep message.

   When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST
   include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is
   RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.  If the
   PCE does not support the intended PST, it MUST send a PCErr message
   with Error-Type = 21 (Invalid traffic engineering path setup type)
   and Error-Value = 1 (Unsupported path setup type) and close the PCEP
   session.  If the PSTs corresponding to the PCReq and PCRep messages
   do not match, the PCC MUST send a PCErr message with Error-Type = 21
   (Invalid traffic engineering path setup type) and Error-Value = 2
   (Mismatched path setup type) and close the PCEP session.

   When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate
   message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV
   in the SRP object, unless the intended PST is RSVP-TE, in which case
   it MAY omit the PATH-SETUP-TYPE TLV.  If the PCC does not support the
   PST associated with the PCUpd or PCInitiate message, it MUST send a
   PCErr message with Error-Type = 21 (Invalid traffic engineering path
   setup type) and Error-Value = 1 (Unsupported path setup type) and
   close the PCEP session.

   When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it
   MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the
   PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
   The PCC MUST include the SRP object in the PCRpt message if the PST
   is not RSVP-TE, even when the SRP-ID-number is the reserved value of
   0x00000000.  If the PCRpt message is triggered by a PCUpd or
   PCInitiate message, then the PST that the PCC indicates in the PCRpt
   MUST match the PST that the stateful PCE intended in the PCUpd or
   PCInitiate.  If it does not, then the PCE MUST send a PCErr message
   with Error-Type = 21 (Invalid traffic engineering path setup type)




Sivabalan, et al.       Expires November 5, 2018                [Page 7]


Internet-Draft             PCE path setup type                  May 2018


   and Error-Value = 2 (Mismatched path setup type) and close the PCEP
   session.

6.  Manageability Considerations

   This document generalises PCEP to allow path setup methods other than
   RSVP-TE to be used by the network (but does not define any new path
   setup types, besides RSVP-TE).  It is possible that, in a given
   network, multiple path setup methods will be used.  It is also
   possible that not all devices will support the same set of path setup
   methods.  Managing networks that combine multiple path setup methods
   may therefore raise some challenges from a configuration and
   observability point of view.

   Each document that defines a new Path Setup Type in the Path Setup
   Type Registry (Section 8.2) must include a manageability section.
   The manageability section must explain how operators can manage PCEP
   with the new path setup type.  It must address the following
   questions, which are generally applicable when working with multiple
   path setup types in PCEP.

   o  What are the criteria for when devices will use the new path setup
      type in PCEP, and how can the operator control this?

   o  How can the network be migrated to the new path setup type, and
      are there any backwards compatibility issues that operators need
      to be aware of?

   o  Are paths set up using the new path setup type intended to coexist
      with other paths over the long term and, if so, how is this
      situation managed with PCEP?

   o  How can operators verify the correct operation of PCEP in the
      network with respect to the new path setup type?  Which fault
      conditions must be reported to the operators?

   o  Are there any existing management interfaces (such as YANG models)
      that must be extended to model the operation of PCEP in the
      network with respect to the new path setup type?

   See [RFC5706] for further guidance on how to write manageability
   sections in standards-track documents.

7.  Security Considerations

   The security considerations described in [RFC5440] and [RFC8281] are
   applicable to this specification.  No additional security measure is
   required.



Sivabalan, et al.       Expires November 5, 2018                [Page 8]


Internet-Draft             PCE path setup type                  May 2018


   Note that, if the security mechanisms of [RFC5440] and [RFC8281] are
   not used, then the protocol described by this draft could be attacked
   in the following new way.  An attacker, using a TCP man-in-the-middle
   attack, could inject error messages into the PCEP session when a
   particular PST is (or is not) used.  By doing so, the attacker could
   potentially force the use of a specific PST, which may allow them to
   subsequently attack a weakness in that PST.

8.  IANA Considerations

8.1.  PCEP TLV Type Indicators

   IANA is requested to confirm the early allocation of the following
   code point in the PCEP TLV Type Indicators registry.

         Value                   Description        Reference

         28                      PATH-SETUP-TYPE    This document

   IANA is requested to allocate a new code point for the following TLV
   in the PCEP TLV Type Indicators registry.

       Value               Description                Reference

       TBD1                PATH-SETUP-TYPE-CAPABILITY This document

   Note to IANA: The above TLV type was not part of the early code point
   allocation that was done for this draft.  It was added to the draft
   after the early code point allocation had taken place.  Please assign
   a code point from the indicated registry and replace each instance of
   "TBD1" in this document with the allocated code point.

8.2.  New Path Setup Type Registry

   IANA is requested to create a new sub-registry within the "Path
   Computation Element Protocol (PCEP) Numbers" registry called "PCEP
   Path Setup Types".  The allocation policy for this new registry
   should be by IETF Review.  The new registry should contain the
   following value:

        Value           Description                   Reference

        0               Path is setup using the RSVP- This document
                        TE signaling protocol.







Sivabalan, et al.       Expires November 5, 2018                [Page 9]


Internet-Draft             PCE path setup type                  May 2018


8.3.  PCEP-Error Object

   IANA is requested to confirm the early allocation of the following
   code-points in the PCEP-ERROR Object Error Types and Values registry.


    Error-Type  Meaning
       10       Reception of an invalid object

                 Error-value=11: Malformed object

    Error-Type  Meaning
       21       Invalid traffic engineering path setup type

                 Error-value=0:  Unassigned
                 Error-value=1:  Unsupported path setup type
                 Error-value=2:  Mismatched path setup type

   Note to IANA: the early allocation for Error-Type=10, Error-value=11
   was originally done by draft-ietf-pce-segment-routing.  However, we
   have since moved its definition into this document.  Therefore,
   please update the reference for this Error-value in the indicated
   registry to point to RFC.ietf-pce-lsp-setup-type.

9.  Contributors

   The following people contributed to this document:

      - Jan Medved
      - Edward Crabbe

10.  Acknowledgements

   We like to thank Marek Zavodsky for valuable comments.

11.  References

11.1.  Normative References

   [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>.



Sivabalan, et al.       Expires November 5, 2018               [Page 10]


Internet-Draft             PCE path setup type                  May 2018


   [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>.

   [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>.

11.2.  Informative References

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-11 (work in progress),
              November 2017.

   [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>.

   [RFC4657]  Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", RFC 4657, DOI 10.17487/RFC4657, September
              2006, <https://www.rfc-editor.org/info/rfc4657>.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions",
              RFC 5706, DOI 10.17487/RFC5706, November 2009,
              <https://www.rfc-editor.org/info/rfc5706>.

Authors' Addresses

   Siva Sivabalan
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario  K2K 3E8
   Canada

   Email: msiva@cisco.com



Sivabalan, et al.       Expires November 5, 2018               [Page 11]


Internet-Draft             PCE path setup type                  May 2018


   Jeff Tantsura
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: jefftant.ietf@gmail.com


   Ina Minei
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   USA

   Email: inaminei@google.com


   Robert Varga
   Pantheon Technologies SRO
   Mlynske Nivy 56
   Bratislava, 821 05
   Slovakia

   Email: nite@hq.sk


   Jon Hardwick
   Metaswitch Networks
   100 Church Street
   Enfield, Middlesex
   UK

   Email: jonathan.hardwick@metaswitch.com

















Sivabalan, et al.       Expires November 5, 2018               [Page 12]


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