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

Versions: 00

PCE Working Group                                                  Y. Qu
Internet-Draft                                                   H. Chen
Updates: 8408 (if approved)                                    Futurewei
Intended status: Standards Track                            July 8, 2019
Expires: January 9, 2020


               PCEP Extensions for Preferred Path Routing
                      draft-qc-pce-path-routing-00

Abstract

   This document specifies extensions to the Path Computation Element
   Protocol (PCEP) that allow a stateful PCE to initiate Preferred Path
   Routing (PPR) paths.  It also specifies how PCC should react to the
   PCEP messages.

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.

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 January 9, 2020.

Copyright Notice

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





Qu & Chen                Expires January 9, 2020                [Page 1]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of PCEP Operation in PPR Networks  . . . . . . . . .   4
   4.  Extensions to PCEP  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Capability for PPR  . . . . . . . . . . . . . . . . . . .   4
     4.2.  PPR TLV . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  PPR-Flags . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  PPR-Prefix Sub-TLV  . . . . . . . . . . . . . . . . .   7
       4.2.3.  PPR-ID Sub-TLV  . . . . . . . . . . . . . . . . . . .   8
       4.2.4.  PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . .   9
       4.2.5.  PPR-Attributes Sub-TLV  . . . . . . . . . . . . . . .  12
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Management Considerations . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Segment Routing (SR) [RFC8402] leverages the source routing paradigm.
   A packet is steered through a network using an ordered list of
   instructions, called "segments".  A segment is often referred to by
   its Segment Identifier (SID), and can represent any instruction,
   topological or service based.  The SR architecture can be implemented
   using either MPLS [I-D.ietf-spring-segment-routing-mpls] or IPv6
   [I-D.ietf-6man-segment-routing-header] forwarding plane.

   A Preferred Path Routing (PPR)
   [I-D.chunduri-lsr-isis-preferred-path-routing]
   [I-D.chunduri-lsr-ospf-preferred-path-routing] path is identified by
   a PPR ID and described as a list of Path Description Elements (PDEs).
   A PPR path could be used as a Traffic Engineering (TE) path, or a



Qu & Chen                Expires January 9, 2020                [Page 2]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   Service Function Chaining (SFC) [RFC7665] path etc.  PPR can help to
   reduce the data plane overhead and mitigate MTU issues.

   [RFC5440] describes the Path Computation Element Protocol (PCEP) for
   communication between a Path Computation Client (PCC) and a Path
   Computation Element (PCE) or between a pair of PCEs.  [RFC8281]
   specifies a mechanism to dynamically initiate LSPs on a PCC based on
   the requests from a stateful PCE or a controller using stateful PCE.
   A stateful PCE can compute one or more SR-TE paths, and initiate a
   SR-TE path on a PCC using the SR specific PCEP extensions specified
   in [I-D.ietf-pce-segment-routing].

   It is possible to use a stateful PCE for computing PPR paths taking
   into account various constraints.  This document specifies the PCEP
   extensions that can be used to for the stateful PCE to initiate a PPR
   path on a PCC.

2.  Terminology

   The following terminologies are used in this document:

   ERO:  Explicit Route Object

   IGP:  Interior Gateway Protocol

   IS-IS:  Intermediate System to Intermediate System

   LSR:  Label Switching Router

   NAI:  Node or Adjacency Identifier

   OSPF:  Open Shortest Path First

   PCC:  Path Computation Client

   PCE:  Path Computation Element

   PCEP:  Path Computation Element Communication Protocol

   RRO:  Record Route Object

   SID:  Segment Identifier

   SR:  Segment Routing

   PPR:  Preferred Path Routing

   PDE:  Path Description Element



Qu & Chen                Expires January 9, 2020                [Page 3]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


3.  Overview of PCEP Operation in PPR Networks

   In a PPR network, the ingress node of a PPR path prepends a PPR
   header to all outgoing packets.  Depending on the forwarding plane,
   different formats of header will be chosen.  The header contains a
   PPR ID, in combination with the control plane information about the
   PPR ID, the packets will be routed through the network.

   In PCEP messages, PPR path information is carried in the Explicit
   Route Object (ERO), which consists of a sequence of sub objects.  PPR
   paths computed by a PCE can be represented in an ERO with a PPR ID
   followed by one of the following list:

   o  An ordered set of IP addresses representing network nodes/links.

   o  An ordered set of SIDs, with or without the corresponding IP
      addresses.

   o  An ordered set of MPLS labels, with or without corresponding IP
      address.

   After a PCC receives the PCEP messages, one of the following two
   methods can be used to program the control plane:

   o  IGP can be used to populate the PPR path information as described
      in [I-D.chunduri-lsr-isis-preferred-path-routing] and
      [I-D.chunduri-lsr-ospf-preferred-path-routing].

   o  If PCEP is used directly to program a PPR path, and a PCC sees
      itself is part of a PPR path, it will install the corresponding
      information, such as PPR ID, next hop into forwarding table.

4.  Extensions to PCEP

4.1.  Capability for PPR

   When a PCEP session is established between a PCE and a PCC, they
   exchange their capabilities of supporting PPR.

   A new sub-TLV, which is called PPR_CAPABILITY, is defined.  It is
   included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1
   (suggested value 3 for PPR) in the OPEN object, which is exchanged in
   Open messages when the PCEP session is established.  Its format is
   illustrated below.







Qu & Chen                Expires January 9, 2020                [Page 4]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


     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 = TBD2          |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Reserved            |             Flags           |I|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: PPR_CAPABILITY sub-TLV

   Type:  TBD2 is to be assigned by IANA.

   Length:  4.

   Reserved:  2 octets.  Must be set to zero in transmission and ignored
      on reception.

   Flags:  2 octets.  This document defines the following flag bits.
      The other bits MUST be set to zero by the sender and MUST be
      ignored by the receiver.

      *  I: A PCC sets this flag bit to 1 to indicate that it is capable
         of flooding PPR path information in an IGP domain.

   The PCC, which supports PPR, sends the PCE an Open message containing
   PPR_CAPABILITY sub-TLV.  This sub-TLV indicates that the PCC is
   capable of supporting PPR.

   The PCE, which supports PPR, sends the PCC an Open message containing
   PPR_CAPABILITY sub-TLV.  This sub-TLV indicates that the PCE is
   capable of supporting PPR.

   When both the PCC and the PCE support PPR_CAPABILITY, each of the
   Open messages sent by the PCC and PCE contains
   PATH_SETUP_TYPE_CAPABILITY TLV with a PST list containing PST=TBD1
   and a PPR_CAPABILITY sub-TLV.

   If the PCE receives an Open message without a PPR_CAPABILITY sub-TLV
   from the PCC, then the PCE MUST not send the PCC any request for PPR.

   If the PCC receives an Open message without a PPR_CAPABILITY sub-TLV
   from a PCE, then the PCC MUST ignore any request for PPR from the
   PCE.








Qu & Chen                Expires January 9, 2020                [Page 5]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


4.2.  PPR TLV

   A new TLV called PPR TLV is defined.  When a PCE sends a PCC a
   PCInitiate message for initiating PPR path, the message contains this
   TLV in the LSP object.

   A PPR TLV may contain the encodings of a Prefix, PPR-ID, and path
   description with an ordered PDE Sub-TLVs and a set of optional PPR
   attribute Sub-TLVs, which can be used to describe one or more
   parameters of the path.  The format of the PPR TLV is illustrated
   below:

     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 = TBD3          |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |I|        PPR-Flags            |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             PPR-Prefix Sub-TLV (variable size)                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              PPR-ID   Sub-TLV (variable size)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  PPR-PDE Sub-TLVs (variable)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PPR-Attribute Sub-TLVs(variable)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 2: PPR TLV Format

   Type:  TBD3 is to be assigned by IANA.

   Length:  Total length of the value field in bytes (variable).

   PPR-Flags:  2 octets.  The defined flags are described below.

   Reserved:  2 octets.  Must be set to zero in transmission and ignored
      on reception.

   PPR-Prefix Sub-TLV:  Variable octets.  It represents the prefix for
      which path description is being attached to, and is defined below.

   PPR-ID Sub-TLV:  Variable octets.  It represents the data plane or
      forwarding identifier of the PPR, and is defined below.

   PPR-PDE Sub-TLVs:  Variable octets.  They represent the path in
      ordered PDE Sub-TLVs, and are defined below.




Qu & Chen                Expires January 9, 2020                [Page 6]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   PPR-Attribute Sub-TLVs:  Variable octets.  They represent the path
      attributes, and are defined below.

4.2.1.  PPR-Flags

   Two flags are defined in the PPR-Flags field of PPR TLV, which are
   shown below:

                0  1  2  3  4  5  6  7                      15
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              |I |       Reserved                             |
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                         Figure 3: PPR-Flags Field

   I Flag:  IGP flag.  If set, IGP will be used to flood this path as
      described in [I-D.chunduri-lsr-isis-preferred-path-routing] and
      [I-D.chunduri-lsr-isis-preferred-path-routing].  If not set, the
      PCC received this TLV will verify the path information, and if it
      sees itself as part of the PPR path, it will install the
      corresponding path information into its forwarding table.

   Reserved:  This field Must be set to zero in transmission and ignored
      on reception.

4.2.2.  PPR-Prefix Sub-TLV

   A PPR-Prefix Sub-TLV contains a prefix for the path described in a
   PPR TLV.  Its format is illustrated below:

     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 = TBD4        |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     MT-ID     | Prefix Length | Mask Length   |  Reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                   Prefix (variable)                          //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              PPR-Prefix  Sub-TLVs (variable)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: PPR-Prefix Sub-TLV Format

   Type:  TBD4 is to be assigned by IANA.

   Length:  Total length of the value field in bytes (variable).




Qu & Chen                Expires January 9, 2020                [Page 7]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   MT-ID:  1 octet.  Multi-Topology ID (as defined in [RFC4915]).

   Prefix Length:  1 octet.  It is the length of the prefix in bits.
      Only the most significant octets of the Prefix are encoded.

   Mask Length:  1 octet.  It is the valid length of the prefix in bits.
      Only the most significant octets of the Prefix are encoded.

   Reserved:  1 octet.  Must be set to zero in transmission and ignored
      on reception.

   Prefix:  Variable octets.  It represents the prefix at the tail-end
      of the PPR.  For the address family IPv4 unicast, the prefix
      itself is encoded as a 32-bit value.  The default route is
      represented by a prefix of length 0.

   PPR-Prefix Sub-TLVs:  Variable octets.  It has 1 octet type, 1 octet
      length and value field is defined per the type field.

4.2.3.  PPR-ID Sub-TLV

   A PPR-ID Sub-TLV contains an identifier, which represents the actual
   data plane identifier in the packet and could be of any data plane as
   defined in PPR-ID-type field.  Both Prefix and PPR-ID MUST belong to
   a same node in the network.  The format of the PPR-ID Sub-TLV is
   illustrated below:

     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 = TBD5        |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     PPR-ID Flags              | PPR-ID Type   | PPR-ID Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |PPR-ID Mask Len|  Algo         | PPR-ID                       //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //                 PPR-ID (cont., variable size)               //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: PPR-ID Sub-TLV Format

   Type:  TBD5 is to be assigned by IANA.

   Length:  Total length of the value field in bytes (variable).

   PPR-ID Type:  1 octet.  Data plane type of PPR-ID.  This is a new
      registry (TBD IANA) for this Sub-TLV and the defined types are as
      follows:



Qu & Chen                Expires January 9, 2020                [Page 8]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


      a.  Type = 1:  MPLS SID/Label.

      b.  Type = 2:  Native IPv4 Address/Prefix.

      c.  Type = 3:  Native IPv6 Address/Prefix.

      d.  Type = 4:  IPv6 SID in SRv6 with SRH.

   PPR-ID Flags:  2 octets.  Two flags are defined below:

                0  1  2  3  4  5  6  7                      15
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              |  Reserved                                     |
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      Reserved:  Reserved bits for future use.  They must be set to zero
         in transmission and ignored on reception.

   PPR-ID Length:  1 octet.  It is the length of the PPR-ID field in
      octets and this depends on the PPR-ID type.  See PPR-ID below for
      the length of this field and other considerations.

   PPR-ID Mask Len:  1 octet.  It is applicable for only for PPR-ID Type
      2.  For Type 1 this value MUST be set to zero.  It contains the
      length of the PPR-ID Prefix in bits.  Only the most significant
      octets of the Prefix are encoded.  This is needed, if PPR-ID
      followed is an IPv4 Prefix instead of 4 octet Address
      respectively.

   Algo:  1 octet.  It represents the SPF algorithm.  Algorithm registry
      is as defined in [I-D.ietf-ospf-segment-routing-extensions].

   PPR-ID:  Variable octets.  It represents the Preferred Path
      forwarding identifier that would be on the data packet.  The value
      of this field is variable and it depends on the PPR-ID Type - for
      Type 1, this is and MPLS SID/Label.  For Type 2 this is a 4 byte
      IPv4 address.

4.2.4.  PPR-PDE Sub-TLV

   This is a new Sub-TLV type in PPR TLV and is called as PPR Path
   Description Element (PDE).  PPR-PDEs are used to describe the path in
   the form of set of contiguous and ordered Sub-TLVs, where first Sub-
   TLV represents (the top of the stack in MPLS data plane or) first
   node/segment of the path.  These set of ordered Sub-TLVs can have
   both topological SIDs and non-topological SIDs (e.g., service
   segments).  The format of the PPR-PDE Sub-TLV is illustrated below:




Qu & Chen                Expires January 9, 2020                [Page 9]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


     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 = TBD6        |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | PPR-PDE Type  |  PDE-ID Type  |  PDE-ID Len   | Reserved      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     PPR-PDE Flags             | PDE-ID Value                 //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    //             PDE-ID Value (Contd., Variable size)            //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                PPR-PDE  Sub-TLVs (variable)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6: PPR-PDE Sub-TLV Format

   Type:  TBD6 is to be assigned by IANA.

   Length:  Total length of the value field in bytes (variable).

   PPR-PDE Type:  1 octet.  This is a new registry (TBD IANA) for this
      Sub-TLV and the defined types are as follows:

      a.  Type = 1:  Topological.

      b.  Type = 2:  Non-Topological.

   PPR-ID Type:  1 octet.  PDE-forwarding IDentifier Type.  This is a
      new registry (TBD IANA) for this Sub-TLV and the defined types and
      corresponding PDE-ID Len, PDE-ID Value are as follows:

      Type = 1:  SID/Label Sub-TLV as defined in [I-D.ietf-ospf-segment-
         routing-extensions].  PDE-ID Len and PDE- ID Value fields are
         defined as the above.

      Type = 2:  SR-MPLS Prefix SID.  PDE-ID Len and PDE-ID Value are
         the same as Type 1.

      Type = 3:  SR-MPLS Adjacency SID.  PDE-ID Len and PDE-ID Value are
         the same as Type 1.

      Type = 4:  IPv4 Node Address.  PDE-ID Len is 4 bytes and PDE-ID
         Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix
         described above.

      Type = 5:  IPv4 P2P interface Address.  PDE-ID Len is 4 bytes and
         PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
         Prefix described above.



Qu & Chen                Expires January 9, 2020               [Page 10]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


      Type = 6:  IPv4 LAN interface Address.  PDE-ID Len is 4 bytes and
         PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
         Prefix described above.

      Type = 7:  IPv6 Node Address.  PDE-ID Len is 16 bytes and PDE-ID
         Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix
         described above.

      Type = 8:  IPv6 P2P interface Address.  PDE-ID Len is 16 bytes and
         PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6
         Prefix described above.

      Type = 9:  IPv6 LAN interface Address.  PDE-ID Len is 16 bytes and
         PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6
         Prefix described above.

      Type = 10:  SRv6 Node SID as defined in
         [I-D.ietf-lsr-isis-srv6-extensions].

      Type = 11:  SRv6 Adjacency-SID.  PDE-ID Len and PDE-ID Values are
         similar to SRv6 Node SID above.

   PPR-ID Len:  1 octet.  It is the length of the PPR-ID field in
      octets.

   Reserved:  1 octet.  Reserved bits MUST be reset to zero on
      transmission and ignored on receive.

   PPR-PDE Flags:  2 octets.  Two flags are defined below:

                0  1  2  3  4  5  6  7                      15
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              |L |        Reserved                            |
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      L: Loose Bit. Indicates the type of next "Topological PDE-ID" in
         the path description.  If set, the next Topological PDE is
         Loose.  If this flag is unset, the next Topological PDE is
         Strict Type.

      Reserved:  Reserved bits for future use.  They must be set to zero
         in transmission and ignored on reception.

   PPR-PDE Sub-TLVs:  TBD.  It has 2 octet type, 2 octet length and
      value field is defined per type.






Qu & Chen                Expires January 9, 2020               [Page 11]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


4.2.5.  PPR-Attributes Sub-TLV

   PPR-Attribute Sub-TLVs describe the attributes of the path.  The
   following Sub-TLVs draw from a new registry for Sub-TLV numbers; this
   registry is to be created by IANA, and administered using the first
   come first serve process:

   Type:  TBD7 is to be assigned by IANA.  This is Packet Traffic
      accounting Sub-TLV.  Length is 0.  There is no value field.  It
      specifies to create a counter to count number of packets forwarded
      on this PPR-ID on each node in the path description.

   Type:  TBD8 is to be assigned by IANA.  This is Traffic statistics in
      Bytes Sub-TLV.  Length is 0.  Thee is no value field.  It
      specifies to create a counter to count number of bytes forwarded
      on this PPR-ID specified in the network header (e.g.  IPv4, IPv6)
      on each node in the path description.

   Type:  TBD9 is to be assigned by IANA.  PPR-Metric Sub-TLV.  Length
      is 4 bytes, and Value is metric of this path represented through
      the PPR-ID.  Different nodes can advertise the same PPR-ID for the
      same Prefix with a different set of PPR-PDE Sub-TLVs and the
      receiving node MUST consider the lowest metric value (TBD more, on
      what happens when metric is same for two different set of PPR-PDE
      Sub-TLVs).

5.  Procedures

   PPR_CAPABILITY sub-TLV in the Open message is exchanged between a PCC
   and a PCE to indicate the support of PPR.  When both the PCC and the
   PCE support PPR_CAPABILITY, each of the Open messages sent by the PCC
   and PCE contains PATH_SETUP_TYPE_CAPABILITY TLV with a PST list
   containing PST=TBD1 and a PPR_CAPABILITY sub-TLV.

   If a PCC sets the I bit to 1 in PPR_CAPABILITY sub-TLV, it means this
   PCC is capable of flooding PPR path info across IGP domain.
   Otherwise it means it supports to install PPR path info into its
   forwarding table but can't flood the information.

   After a PCC receives a PPR TLV, it needs to verify whether it's
   valid.

   If a PCC receives a PPR TLV with flog I bit set to 1, however this
   PCC doesn't support IGP flooding of PPR info, it MUST consider the
   TLV invalid and MUST sent a PCErr message with Error-Type = 10
   ("Reception of an invalid object").





Qu & Chen                Expires January 9, 2020               [Page 12]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   The PPR TLV contains a sequence of subobjects/sub TLVs, which defines
   the PPR path information.  If a routing process/protocol is
   configured to flood PPR path, it interprets the sub TLVs and converts
   them into corresponding routing protocol TLVs and flood them.

   Section 4 in [I-D.chunduri-lsr-isis-preferred-path-routing] describes
   how PCCs act after receiving path information from a controller.

6.  Management Considerations

   This document adds a new path setup type to PCEP to allow PPR paths
   to be set up on PCCs.  This path setup type may be used with PECP
   alongside other path setup types, such as RSVP-TE, Segment Routing
   Traffic Engineering, or it may be used exclusively.

   The PATH-SETUP-TYPE-CAPABILITY TLV is used to indicate the path setup
   type supported.  It requires both PCC and PCE to include PST=TBD1,
   also include the PPR-CAPABILITY sub-TLV.

   A network operator can use the following steps to enable PCEP to
   setup paths using PPR as path setup type:

   o  The operator enables the PPR PST on the PCE servers.

   o  The operator enables the PPR PST on the PCCs.

   o  The operator resets each PCEP session.  The PCEP sessions come
      back up with PPR enabled.

   o  If the operator detects a problem, they can roll the network back
      to its initial state by disabling the PPR PST on the PCEP speakers
      and resetting the PCEP sessions.

   The data plane is unaffected if a PCEP session is reset.  Any PPR
   path that was set up before the session reset will remain in active.

   The PPR YANG module is defined in [I-D.qct-lsr-ppr-yang], and it is
   used to configure PPR path information on a router and it can coexist
   with the path set up method defined in this document.

7.  Security Considerations

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

   This draft enables a network controller to instantiate a path in the
   network, and that creates additional vulnerability.



Qu & Chen                Expires January 9, 2020               [Page 13]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


8.  IANA Considerations

   TBD.

9.  Acknowledgements

   TBD.

10.  References

10.1.  Normative References

   [I-D.chunduri-lsr-isis-preferred-path-routing]
              Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
              L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
              draft-chunduri-lsr-isis-preferred-path-routing-03 (work in
              progress), May 2019.

   [I-D.chunduri-lsr-ospf-preferred-path-routing]
              Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
              Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
              chunduri-lsr-ospf-preferred-path-routing-03 (work in
              progress), May 2019.

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








Qu & Chen                Expires January 9, 2020               [Page 14]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


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

   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying Path Setup Type in PCE Communication
              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
              July 2018, <https://www.rfc-editor.org/info/rfc8408>.

10.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
              progress), April 2019.

   [I-D.ietf-lsr-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extensions to Support Routing over IPv6
              Dataplane", draft-ietf-lsr-isis-srv6-extensions-00 (work
              in progress), May 2019.

   [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-16 (work in progress),
              March 2019.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-18
              (work in progress), December 2018.

   [I-D.qct-lsr-ppr-yang]
              Qu, Y., Chunduri, U., and J. Tantsura, "YANG Data Model
              for Preferred Path Routing", draft-qct-lsr-ppr-yang-01
              (work in progress), March 2019.




Qu & Chen                Expires January 9, 2020               [Page 15]


Internet-Draft PCEP Extensions for Preferred Path Routing      July 2019


   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Yingzhen Qu
   Futurewei

   EMail: yingzhen.qu@futurewei.com


   Huaimo Chen
   Futurewei

   EMail: huaimo.chen@futurewei.com


















Qu & Chen                Expires January 9, 2020               [Page 16]


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