Internet DRAFT - draft-dugeon-brpc-stateful

draft-dugeon-brpc-stateful







Path Computation Element Working Group                         O. Dugeon
Internet-Draft                                                 J. Meuric
Intended status: Standards Track                                  Orange
Expires: September 14, 2017                               March 13, 2017


       A Backward Recursive PCE-initiated inter-domain LSP Setup
                     draft-dugeon-brpc-stateful-00

Abstract

   The Path Computation Element (PCE) working group (WG) has produced a
   set of RFCs to standardize the behavior of the Path Computation
   Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment
   Routing paths placement.  This also include the ability to compute
   inter-domain LSPs or Segment Routing path following a distributed or
   hierarchical approach.  In complement to the original stateless mode,
   a stateful mode has been added.  In particular, the new PCInitiate
   message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS
   LSP tunnels or a Segment Routing path.  However, once computed, the
   inter-domain LSPs or Segment Routing path are hard to setup in the
   underlying network.  Especially, in operational network, RSVP-TE
   signaling is not enable between BGP border routers.  But, such RSVP-
   TE signaling is mandatory to setup contiguous LSP tunnels or to
   stitch or nest independent LSP tunnels to form the end-to-end inter-
   domain LSP tunnels.  This draft propose to combine a Backward
   Recursive method with PCInitiate message to setup independent LSP
   tunnels per domain and stitch or nest the different LSP tunnels to
   setup end-to-end inter-domain LSP tunnels without the need of inter-
   domain signaling between BGP border routers.  A new Stitching Label
   definition and new LSP-TYPE code points are proposed for that
   purpose.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 http://datatracker.ietf.org/drafts/current/.



Dugeon & Meuric        Expires September 14, 2017               [Page 1]

Internet-Draft                BRPC Stateful                   March 2017


   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 14, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  General assumptions . . . . . . . . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Stitching Label . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . .   7
   3.  Inter-domain LSP tunnels setup procedure  . . . . . . . . . .   8
     3.1.  Mode of operation . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  Inter-domain LSP setup procedure completion failure . . .  11
     3.4.  Inter-domain LSP management . . . . . . . . . . . . . . .  12
   4.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  LSP-TYPE values . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16






Dugeon & Meuric        Expires September 14, 2017               [Page 2]

Internet-Draft                BRPC Stateful                   March 2017


1.  Problem Statement

   Looking to the different RFCs that describe the PCE architecture and
   in particular PCE based architecture [RFC4655], PCE protocol
   [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], the Path Computation
   Element (PCE) is able to compute inter-domain path in complement to
   intra-domain computation.  Such inter-domain paths could then serve
   as the Explicit Route Object input for the RSVP-TE signaling to setup
   the LSPs tunnel within the underlying network.  Three sort of end-to-
   end LSP tunnels could be established:

   o  Contiguous tunnels: The RSVP-TE signaling crosses the boundary
      between two domains e.g. between two AS Border Routers (ASBR) like
      if it is two routers of the same domain.  This kind of tunnel is
      not recommended mostly for security and scalability purpose.  In
      addition, the initiating domain imposes huge constraints on
      subsequent domains, because they undergo the tunnel request
      without being able to control it.

   o  Stitching tunnels: Each domain establishes in its own network the
      corresponding part of the end-to-end LSP tunnel independently.
      Then, a second end-to-end RSVP-TE Path message is sent by the
      initiating domain to stitch the different tunnel parts to form the
      end-to-end LSP tunnel.  In fact, this second RSVP-TE Path message
      is used by border nodes to exchange the label that must be used by
      the previous domain to send the traffic in order that the IP
      packets follow the next LSP tunnel in the following domain.  These
      labels are convey in the RSVP-TE Resv message.

   o  Nesting tunnels: This is similar to the stitching mode but, this
      time, with the possibility to setup tunnel hierarchy.  For
      example, an LSP tunnel between two edge domains crossing a transit
      domain could be inserted into a tunnel of higher hierarchy in the
      transit domain.  Again, a second end-to-end RSVP-TE Path message
      is sent from the source to the destination.  Labels that must be
      used to nest local tunnels are carried by the RSVP-TE Resv
      message.

   In all case, RSVP-TE signaling must be exchange between the different
   domains.  However, from an operational point of view, looking to
   different networks under the responsibility of different
   administrative entities, only BGP protocol are setup and configured
   between AS Border Routers (ASBR).  Indeed, to the author's knowledge,
   there is no example of operational networks that enable RSVP-TE
   between ASBR.  Technology speaking, this is possible and many RFCs
   describe how to use RSVP-TE at the inter-domain.  But, due to
   security, scalability, management and contract constraints, RSVP-TE
   is no longer exposed at the network boundary.  To circumvent the



Dugeon & Meuric        Expires September 14, 2017               [Page 3]

Internet-Draft                BRPC Stateful                   March 2017


   security issue, RSVP-TE could be carry inside an IPsec tunnel between
   ASBR, but, this not eliminate the scalability aspect nor the
   constraints impose by seting up and end-to-end LSP tunnels.

   The purpose of this memo is to take the benefit of PCE stateful mode
   as per draft pce stateful [I-D.ietf-pce-stateful-pce] and draft pce
   initiated [I-D.ietf-pce-pce-initiated-lsp] to stitch or nest inter-
   domain LSP tunnels directly using PCEP protocol between domain's PCE
   instead of using RSVP-TE signaling at the inter-domain while keeping
   each operator independently setup their respective part of the end-
   to-end LSP tunnels.  PCInitiated message is used in a Backward
   Recursive way like the PCReq message in BRPC [RFC5441], to
   recursively setup the end-to-end tunnel.  PCRep message is used to
   automatically stitch or nest the different local LSP tunnels.  And,
   PCRep in conjunction of PCUpd messages are used to maintain, modify
   and remove end-to-end LSP tunnels.

1.1.  General assumptions

   In the rest of this document, we used the same references as per BRPC
   [RFC5441] and make the following set of assumptions (see figure
   below):

   o  Domain refers to an IGP area or an Autonomous System (AS).

   o  Inter-domain LSP tunnel is used to refer to an LSP tunnel that
      cross two or more different domains as defined previously,

   o  At least, one PCE is deployed in each domain.  These PCE are all
      stateful active capable and could request to enforce LSP tunnels
      in their respective domain by means of PCInitiate messages.

   o  LSRs, including border nodes, are PCC enable and support stateful
      active mode.  PCEP sessions is established between these routers
      and their domain's PCE.

   o  Each PCE establishes a PCEP session with its respective neighbor
      domain's PCE.  The way a PCE discover its neighboring PCE is out
      of scope of this draft.  These information could be fulfill
      administratively or automatically discovered through, for example
      per draft 'BGP Extensions for Path Computation Element (PCE)
      Discovery' [I-D.dong-pce-discovery-proto-bgp],

   o  PCEs are able to compute and end-o-end path as per BRPC procedure
      [RFC5441].






Dugeon & Meuric        Expires September 14, 2017               [Page 4]

Internet-Draft                BRPC Stateful                   March 2017


                   +----------------+          +----------------+
                   |  Domain (B)    |          |  Domain (C)    |
                   |                |          |                |
                   |        /-------|---PCEP---|--------\       |
                   |       /        |          |         \      |
                   |   [PCE-B]      |          |       [PCE-C]  |
                   |    /         (BN)<------>(BN)              |
                   |   /            |  Inter   |                |
                   +---|--(BN)------+  Domain  +----------------+
                       |    ^          Link
                     PCEP   |
                       |    | Inter-domain Link
                       |    v
                   +---|--(BN)------+
                   |   |            |
                   |   | Domain (A) |
                   |   \            |
                   | [PCE-A]        |
                   |                |
                   |                |
                   +----------------+



         Example of the representation of 3 domains with 3 PCEs

1.2.  Terminology

   ABR: Area Border Routers.  Routers used to connect two IGP areas
   (areas in OSPF or levels in IS-IS).

   ASBR: Autonomous System Border Router.  Router used to connect
   together ASes of the same or different service providers via one or
   more inter-AS links.

   AS: Autonomous System

   Border Node (BN): a boundary node is either an ABR in the context of
   inter-area Traffic Engineering or an ASBR in the context of inter-AS
   Traffic Engineering.

   Domains: Autonomous System (AS) or IGP Area.  An Autonoumous System
   is composed by one or more IGP area.

   Entry BN of domain(i): a BN connecting domain(i-1) to domain(i) along
   a determined sequence of domains.  Multiple entry BN(i) could be used
   to connect domain(i-1) to domain(i).




Dugeon & Meuric        Expires September 14, 2017               [Page 5]

Internet-Draft                BRPC Stateful                   March 2017


   Exit BN of domain(i): a BN connecting domain(i) to domain(i+1) along
   a determined sequence of domains.  Multiple exit BN(i) could be used
   to connect domain(i) to domain(i+1).

   Inter-domain LSP tunnel: A LSP tunnel that crosses two or more
   domains through a per of Border Node.

   Local LSP tunnel: A LSP tunnel that do not cross a domain.  It is
   setup between entry BN to exit BN, any source to exit BN or entry BN
   to any destination of the same domain.

   Local LSP tunnel(i): A local LSP tunnel of domain(i)

   IGP-TE: Interior Gateway Protocol with Traffic Engineering support.
   Both OSPF-TE and IS-IS-TE are identified in this category.

   Stitching Label (SL): A dedicated label that is used to stitch two
   RSVP-TE tunnels or two Segment Routing paths.

   PCE: Path Computation Element.  An entity (component, application, or
   network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints.

   PCE(i) is a PCE with the scope of domain(i).

2.  Stitching Label

   This section introduce the concept of Stitching Label that allows
   stitching and nesting of Local LSP tunnels in order to form inter-
   domain LSP tunnel that cross several different domains.

2.1.  Definition

   The operation of stitch or nest a local LSP tunnel(i) to a local LSP
   tunnel(i+1) in order to form and inter-domain LSP tunnel simply
   consist in defining the label that the exit BN(i) will use to send
   its traffic to the entry BN(i+1).  Indeed, the entry BN(i+1) needs to
   identify the incoming traffic i.e. IP packets, in order to know if
   this traffic must follow the local LSP tunnel(i+1) or not.
   Forwarding Equivalent Class (FEC) could be used for that purpose.
   But, when stitching or nesting tunnels, the FEC is reduce to the
   incoming label that the entry BN(i+1) as chosen for the local LSP
   tunnel(i+1).

   In this memo, we introduce the named of 'Stitching Label (SL)' to
   designate this label.  Such label is usually exchange between exit
   BN(i) and entry BN(i+1) with the RSVP-TE signaling.  But, as we want
   to avoid to use RSVP-TE signaling due to operational constraints,



Dugeon & Meuric        Expires September 14, 2017               [Page 6]

Internet-Draft                BRPC Stateful                   March 2017


   this Stitching Label will be convey by PCEP protocol.  In fact, the
   Explicit Route Object (ERO) and the Record Route Object (RRO) are
   defined in order to transport this Stitching Label in the RSVP-TE
   signaling.  As PCEP protocol used RSVP-TE Objects, and in particular
   the ERO and ERO, it is able to convey the Stitching Label without any
   modification of the PCEP protocol nor the PCE or RSVP-TE Objects.

   As per RFC4003 [RFC4003], the Stitching Label will be convey as a
   companion of an IP address.  In our case, this is the IP address of
   the input interface ITF_INPUT(i+1) of BN(i+1) which is connected to
   the exit BN(i) and which receives the traffic from the domain(i).

2.2.  Inter-domain LSP-TYPE

   However, even if PCEP could convey the Stitching Label, a PCC is not
   aware that a PCE requests or provides such label.  For that purpose,
   this memo propose to use the LSP-TYPE as defined in draft lsp setup
   type [I-D.ietf-pce-lsp-setup-type] with new values (See IANA section
   of this memo) defined as follow:

   o  TBD1: Inter-Domain Traffic engineering end-to-end path is setup
      using Backward Recursive method.  This new LSP-TYPE value MUST be
      set in a PCInitiate messages sends by a PCE(i) to its neighbor
      PCE(i+1) to initiate a new inter-domain LSP tunnel.  In turn,
      neighbor PCE(i+1) MUST return a Stitching Label SL with the IP
      address of the associated interface in the RRO of the PCRpt
      message to PCE (i).

   o  TBD2: Inter-Domain Traffic engineering local path is setup using
      RSVP-TE.  This new LSP-TYPE value MUST be set in the PCInitiate
      message sends by a PCE(i) requesting to a PCC of domain(i) to
      initiate a new local LSP tunnel(i) which is part of an inter-
      domain LSP tunnel.  This LSP-TYPE value MUST be used by the PCE(i)
      only after receiving a PCInitiate message with an LSP-TYPE equal
      to TBD1 from a neighbor PCE(i-1).  In turn, the PCC of domain(i)
      MUST return a Stitching Label SL with the IP address of associated
      interface in the RRO of the PCRpt message.

   o  TBD3: Inter-Domain Traffic engineering local path is setup using
      Segment Routing.  This new LSP-TYPE value MUST be set in the
      PCInitiate message sends by a PCE(i) requesting to a PCC of
      domain(i) to initiate a new Segment Routing path which is part of
      and inter-domain Segment Routing path.  This LSP-TYPE value MUST
      be used by the PCE(i) only after receiving a PCInitiate message
      with an LSP-TYPE equal to TBD1 from a neighbor PCE(i-1).  In turn,
      the PCC MUST return a Stitching Label SL with the IP address of
      the associated interface in the RRO of the PCRpt message.




Dugeon & Meuric        Expires September 14, 2017               [Page 7]

Internet-Draft                BRPC Stateful                   March 2017


3.  Inter-domain LSP tunnels setup procedure

   This section describes how to setup inter-domain LSP tunnels than
   cross several different domains.

3.1.  Mode of operation

   This section describes how PCInitiate and PCRpt messages are combined
   between PCE in order to setup inter-domain LSP tunnels between a
   source domain(1) to a destination domain(n).  S and D are
   respectively the source and destination of the inter-domain LSP
   tunnel.  Domain(1) and domain(n) are different and connected through
   0 or more intermediate domains denoted domain(i) with i = (2, n-1).
   Domains are directly connected when n = 2.

   First, the PCE(S) run standard BRPC algorithm as per RFC5441
   [RFC5441] with its neighbor PCEs in order to compute the inter-domain
   LSP tunnel from S to D, where S and D are respectively a node in the
   domain(1) and domain(n).  Path Key confidentiality as per RFC5520
   [RFC5520] MAY be used to obfuscate the detailed ERO of the different
   domains(i).  The resulting ERO is of the form (S, PKS(1), exit BN(1),
   ..., entry BN(i), PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D).
   As subsequent domains are not aware about the final computed ERO in
   case of multiple VSPT, the final computed ERO MUST be send in the
   PCInitiate message to indicate to the subsequent PCEs which solution
   has been finally chosen.

   The complete procedure follow the different steps described below:

   Steps 1: Initialization

   Once ERO(S, D) computed, PCE(1) sends a PCInitiate message to PCE(2)
   containing and ERO equal to {S, PKS(1), exit BN(1), ..., entry BN(i),
   PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D}, LSP-TYPE = TBD1 and
   End-Points Object = (S, D).  The ERO corresponds to the one PCE(1) as
   received from PCE(2) during the BRPC process.  In case of multiple
   EROs, i.e. VSPT > 1, PCE(1) has chosen one of them and used the
   selected one for the PCInitiate message.  PKS(i) could be replaced by
   the full ERO description if Path Key is not used by PCE(i).

   When PCE(i) receives a PCInitiate message from domain(i-1) with LSP-
   TYPE = TBD1 and ERO = {entry BN(i), PKS(i), exit BN(i), ..., entry
   BN(n), PKS(n), D)}, it forwards the PCInitiate message to PCE(i+1)
   once remove its {entry BN(i), PKS(i), exit BN(i)} part from the ERO.
   All intermediate PCE(i) propagate the PCInitiate message to PCE(i+1)
   up to the domain(n).

   Steps 2: Actions taken at the destination domain(n)



Dugeon & Meuric        Expires September 14, 2017               [Page 8]

Internet-Draft                BRPC Stateful                   March 2017


   When PCInitiate message propagation reach the destination domain(n),
   PCE(n) retrieves the ERO from the PKS(n) if necessary and sends to
   entry BN(n) a PCInitiate message with the ERO(n) = {BN(n), ..., D},
   LSP-TYPE= TBD2 and End-Points Object = (BN(n), D) in order to inform
   the PCC BN(n) that this local LSP tunnel(n) is part of an inter-
   domain LSP tunnel.  When the PCC entry BN(n) received the PCInitiate
   message from its PCE(n), it setup the LSP tunnels from entry BN(n) to
   D by means of RSVP-TE signaling with the given ERO(n).  Once the
   tunnel setup, it chooses a free label for the Stitching Label SL(n)
   and add a new entry in its MPLS LFIB with this SL(n) label.  Then, it
   sends a PCRpt message to its PCE(n) with an RRO equal to
   {[ITF_INPUT(n), SL(n)], RRO(n)}. Once PCE(n) receives the PCRpt from
   the PCC BN(n) with the RRO and LSP-TYPE = TBD2, it sends to the
   PCE(n-1) a PCRpt containing the RRO equal to {[ITF_INPUT(n), SL(n)]}.
   PCE(n) MAY adds BN(n), D in the RRO as loose path.

   Steps i: Actions performed by all intermediate domains(i), for i = 2
   to n-1

   1.  When the PCE(i) receives a PCRpt message from domain(i+1) with
       LSP-TYPE = TBD1 and RRO = {[ITF_INPUT(i+1), SL(i+1)]}, it
       retrieves the ERO from the PKS(i) if necessary and sends to the
       PCC entry BN(i) a PCInitiate message with ERO = {ERO(i),
       [ITF_INPUT(i+1), SL(i+1)]}, LSP-TYPE = TBD2 and End-Points Object
       = {entry BN(i), exit BN(i)} in order to inform the PCC entry
       BN(i) that this local LSP tunnel(i) is part of an inter-domain
       LSP tunnel.

   2.  When the PCC entry BN(i) received the PCInitiate message from its
       PCE(i), it setup the LSP tunnels from entry BN(i) to exit BN(i)
       by means of RSVP-TE signaling with the given ERO(i).

   3.  When the exit Bn(i) receives an RSVP-TE Path message with an ERO
       = {x-1, [ITF_INPUT(i+1), SL(i+1)]} and End-Points Object = {entry
       BN(i), exit BN(i)}, it MUST install in its MPLS LFIB the SWAP
       instruction to label SL(i+1) with forward to ITF_INPUT(i+1)
       instead of the standard POP instruction.

   4.  Once the tunnel setup, it chooses a free label for the Stitching
       Label SL(i) and add a new entry in its MPLS LFIB with this SL(i)
       label.  Then, it sends a PCRpt message to its PCE(i) with an RRO
       equal to {[ITF_INPUT(i), SL(i)], RRO(i)}.

   5.  Once PCE(i) receives the PCRpt from the PCC entry BN(i) with the
       RRO and LSP-TYPE = TBD2, it sends to the PCE(i-1) a PCRpt
       containing the RRO equal to {[ITF_INPUT(i), SL(i)]}. PCE(i) MAY
       adds entry BN(i), exit BN(i) in the RRO as loose path.




Dugeon & Meuric        Expires September 14, 2017               [Page 9]

Internet-Draft                BRPC Stateful                   March 2017


   Steps n: Actions performed at the source domain(1)

   Once PCE(1) received the PCRpt message from PCE(2) with the RRO
   containing the label SL(2), it sends a PCInitiate message to PCC node
   S with ERO equal to {ERO(1), [ITF_INPUT(2), SL(2)]}, LSP_TYPE = 0 and
   End-Points Object = {S, BN(1)}. This time, the LSP_TYPE is equal to 0
   as the PCC S does not need to return a Stitching Label SL i.e. it is
   the head-end of the inter-domain LSP tunnel.  Standard PCRpt message
   is sent back to PCE(1) by the PCC node S.

   To use Segment Routing instead of RSVP-TE to setup the LSP tunnels as
   defined in draft pce segment routing [I-D.ietf-pce-segment-routing],
   PCEs MUST send PCInitiate message with LSP-TYPE = TBD3 instead of
   TBD2 to advertise their respective PCC that the LSP tunnels is
   enforce by means of Segment Routing.  SL label will be inserted in
   the label stack in order to become the top label in the stack when
   the packet reach entry BN(i+).  Then, entry BN(i+1) will push a new
   label stack to reach the exit BN(i+1) and follow.

3.2.  Example

   In the figure below, two different domains S and D are interconnected
   through BN respectively BN-S and BN-D.  PE-S and PE-D are edge
   routers.  All routers in the figure are connected to their respective
   PCE through PCEP protocol.  In this example, PCE(S) would setup an
   intre-domain LSP tunnel between PE-S and PE-D acting as source and
   destination of the tunnel.  Intermediate routers between (PE-S, BN-
   S), (BN-D and PE-D) as well as RSVP-TE messages are not represented
   to simplify the figure.  But they are all presents.  The following
   notation is used in the figure:

   o  PKS(D) = Path Key correponding to the path from BN(D) to PE-D

   o  ERO(D) = Explicit Route Object corresponding to the path from
      BN(D) to PE-D retrieves from PKS(D)

   o  RRO(D) = Record Route Object of Local LSP tunnel(D) from BN(D) to
      PE-D

   o  SL(D) = Stitching Label for Local LSP tunnel from BN(D) to PE-D

   o  ERO(S) = Explicit Route Object corresponding to the path from PE-S
      to BN(S)

   o  RRO(S) = Record Route Object of Local LSP tunnel(S) from PE-S to
      BN(S)

   1.



Dugeon & Meuric        Expires September 14, 2017              [Page 10]

Internet-Draft                BRPC Stateful                   March 2017


     PE-S      PCE-S                           BN-D      PCE-D
      |          |                              |          |
      |        [ -------- Standard BRPC exchange ------------]
      |          |                              |          |
      |          | PCInitiate(ERO={BN(D), PKS(D)}, LSP-TYPE = TBD1)
      |          | --------------------------------------> |
      |          |                              |          |
      |          |             PCInitiate(ERO = ERO(D), LSP-TYPE = TBD2)
      |          |                              | <------- |
      |          |                              |          |
      |          |         PCRpt(RRO = {SL(D), RRO(D)}, LSP-TYPE = TBD2)
      |          |                              |  ------> |
      |          |                              |          |
      |          |   PCRpt(RRO = {SL(D), PKS(D)}, LSP-TYPE = TBD1)
      |          | <-------------------------------------- |
      |          |                              |          |
      |  PCInitiate(ERO={ERO(S), SL(D), BN(D)}, LSP-TYPE = 0)
      | <------- |                              |          |
      |          |                              |          |
      |  PCRpt(RRO={RRO(S)}, LSP-TYPE = 0)      |          |
      | -------> |                              |          |
      |          |                              |          |

     +----------------------+                  +----------------------+
     |                      |                  |                      |
     |       +------+       |     PCEP         |       +------+       |
     | +---->|PCE(S)|<-------------------------------->|PCE(D)|       |
     | |     +------+       |                  |       +------+       |
     | |         ^          |                  |        ^  ^          |
     | |         |          |                  |        |  |          |
     | |PCEP     |          |                  |        |  |          |
     | |         |PCEP      |                  |   PCEP |  | PCEP     |
     | v         |          |                  |        |  |          |
   (PE-S)        +------> (BN-S) <---------> (BN-D)<----+  +----> (PE-D)
     |                      |  Inter-Domain    |                      |
     |     Domain (S)       |   Link           |   Domain (D)         |
     +----------------------+                  +----------------------+

    [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---]

   Example of end-to-end LSP tunnel setup between two domains


3.3.  Inter-domain LSP setup procedure completion failure

   In case of error during LSP setup, PCRpt and or PCError messages MUST
   be used to signal the problem to the neighbor PCE domain backward.
   In particular, if new LSP-TYPE values defined in this memo are not



Dugeon & Meuric        Expires September 14, 2017              [Page 11]

Internet-Draft                BRPC Stateful                   March 2017


   supported by the neighbor PCE or the PCC, the PCE, receptively the
   PCC, MUST return a PCErr message with Error-Type = 21 (Traffic
   engineering path setup error) and Error-Value = 1 (Unsupported path
   setup type) to its neighbor PCE.

   If a PCC or a PCE don't return an RRO or an RRO without the Stitching
   Label SL with the IP address of the associated interface following a
   PCInitiate message with LSP-TYPE set to the new values defined in
   this memo, the PCE MUST return a PCErr message with Error-Type = 21
   (Traffic engineering path setup error) and Error-Value = TBD4 (No
   Mandatory Stitching Label is present in the RRO).

   In case of completion failure, the PCE(i) MUST propagate the PCErr
   message up to the PCE(1).  In turn, PCE(1) MUST send a PCInitate
   message (R flag set in the SRP Object as per draft pce initiated lsp
   [I-D.ietf-pce-pce-initiated-lsp] to delete this inter-domain LSP
   tunnel to its neighbor PCEs.  PCE(i) MUST propagate the PCInitiate
   message and remove their Local LSP tunnel by means of PCInitiate
   message to their PCC entry BN(i) and send back PCRpt message to
   PCE(i-1).

3.4.  Inter-domain LSP management

   Each domain manages their respective local LSP tunnel part of an
   inter-domain LSP tunnel independently of each other.  In particular,
   Stitching Label(i) is managed by domain(i) and is of interest of
   domain(i-1) only.  Thus, Stitching Label SL(i) is not supposed to be
   propagated to other domains.

   If a PCE(i) needs to modify its local LSP tunnel(i) with PCUpd
   message, it MUST sends a new PCRpt message to its neighbor PCE(i-1)
   to advertise it of the modification, in particular if this concern a
   modification of Stitching Label SL(i).

   PCE(1) could modify the inter-domain LSP tunnel.  For that purpose,
   it MUST sends a PCUpd message to its neighbor PCEs.  Each PCE(i) MUST
   process PCUpd message the same way they process PCInitiate message:
   first, propagate the PCUpd message up to the destination domain(n),
   then process the modification once PCRpt received from PCE(i+1) and
   send PCRpt to PCE(i-1) once modification done.

   Modification of Local LSP tunnel, entry BN(i) and exit BN(i) is left
   for further study.

   In case of a failure appear in domain(i), PCE(i) MUST sends a PCRpt
   message to its neighbor PCE(i-1) to advertise it that its local part
   of the inter-domain LSP tunnel is down.  Once PCE(1) receives this
   PCRpt message indicating that the tunnel is down, it is up to the



Dugeon & Meuric        Expires September 14, 2017              [Page 12]

Internet-Draft                BRPC Stateful                   March 2017


   PCE(1) to take appropriate correction e.g. start a new BRPC to
   compute a new ERO.

4.  Applicability

   The newly introduce Stitching Label SL serves to stitch or nest part
   of LSP tunnels to form an inter-domain LSP tunnel.  Each domain is
   free to decide if the tunnel is stitched or nested.  For example, a
   domain(i) may decided to nest the incoming Local LSP tunnel into a
   higher hierarchy of tunnel for Traffic Engineering purpose.  A PCE(i)
   may also decided to group Local LSP tunnels part of inter-domain LSP
   tunnels into a higher hierarchical tunnel to carry all these Local
   LSP tunnels from one entry BN(i) to one exit BN(i).

   The Stitching Label SL could serves to stitch Segment Path and RSVP-
   TE tunnel.  Indeed, each domain is free to enforce its part of the
   inter-domain LSP tunnel with the underlying mechanism it chosen.
   Stitching Label SL will be part of the label stack in order to become
   the top label in the stack when reaching the entry BN(i+1).  This
   Stitching Label could be swap as usual if the next domain that uses
   RSVP-TE tunnel.  When the previous domain uses a RSVP-TE tunnel, the
   Stitching Label will serve as key for the entry BN(i+1) to determine
   which label stack it must push on top of the packet for a Segment
   Routing path.

   In inter-layer scenario is left for further study.

5.  IANA Considerations

5.1.  LSP-TYPE values

   Draft pce lsp setup type [I-D.ietf-pce-lsp-setup-type] defines the
   PATH-SETUP-TYPE TLV and requests that IANA creates a registry to
   manage the value of the PATH_SETUP_TYPE TLV's PST field.  IANA is
   requested to allocate a new code point in the PCEP PATH_SETUP_TYPE
   TLV PST field registry, as follows:

   +-------+-----------------------------------------------+-----------+
   | Value | Description                                   | Reference |
   +-------+-----------------------------------------------+-----------+
   | TBD1  | Inter-Domain Traffic engineering end-to-end   | This      |
   |       | path is setup using Backward Recursive method | Document  |
   | TBD2  | Inter-Domain Traffic engineering local path   | This      |
   |       | is setup using RSVP-TE                        | Document  |
   | TBD3  | Inter-Domain Traffic engineering local path   | This      |
   |       | is setup using Segment Routing                | Document  |
   +-------+-----------------------------------------------+-----------+




Dugeon & Meuric        Expires September 14, 2017              [Page 13]

Internet-Draft                BRPC Stateful                   March 2017


5.2.  PCEP-Error Object

   IANA is requested to allocate code-points in the PCEP-ERROR Object
   Error Values registry for a new error-value or Error-Type 21 Invalid
   traffic engineering path setup:

        +-------------+------------------------------------------+
        | Error-Value | Description                              |
        +-------------+------------------------------------------+
        | TBD4        | Missing Mandatory Stitching Label in RRO |
        +-------------+------------------------------------------+

6.  Security Considerations

   No modification of PCE protocol (PCEP) has been requested by this
   draft which not introduce any issue regarding security.  Concerning
   the PCEP session between PCEs, authors recommend to use the secure
   version of PCEP as defined in draft secure transport for PCEP
   [I-D.ietf-pce-pceps] or use any other secure tunnel mechanism e.g.
   IPsec tunnel to transport PCEP session between PCE.

7.  Acknowledgements

   The authors want to thanks PCE's WG members.

8.  References

8.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,
              <http://www.rfc-editor.org/info/rfc2119>.

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

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








Dugeon & Meuric        Expires September 14, 2017              [Page 14]

Internet-Draft                BRPC Stateful                   March 2017


   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <http://www.rfc-editor.org/info/rfc5441>.

8.2.  Informative References

   [I-D.dong-pce-discovery-proto-bgp]
              Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K.,
              and T. Murai, "BGP Extensions for Path Computation Element
              (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-06
              (work in progress), October 2016.

   [I-D.ietf-pce-lsp-setup-type]
              Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga,
              R., Tantsura, J., and J. Hardwick, "Conveying path setup
              type in PCEP messages", draft-ietf-pce-lsp-setup-type-03
              (work in progress), June 2015.

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
              progress), March 2017.

   [I-D.ietf-pce-pceps]
              Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
              Transport for PCEP", draft-ietf-pce-pceps-11 (work in
              progress), January 2017.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
              Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and
              J. Hardwick, "PCEP Extensions for Segment Routing", draft-
              ietf-pce-segment-routing-08 (work in progress), October
              2016.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-18 (work in progress), December 2016.

   [RFC4003]  Berger, L., "GMPLS Signaling Procedure for Egress
              Control", RFC 4003, DOI 10.17487/RFC4003, February 2005,
              <http://www.rfc-editor.org/info/rfc4003>.




Dugeon & Meuric        Expires September 14, 2017              [Page 15]

Internet-Draft                BRPC Stateful                   March 2017


   [RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
              "Preserving Topology Confidentiality in Inter-Domain Path
              Computation Using a Path-Key-Based Mechanism", RFC 5520,
              DOI 10.17487/RFC5520, April 2009,
              <http://www.rfc-editor.org/info/rfc5520>.

   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
              DOI 10.17487/RFC6805, November 2012,
              <http://www.rfc-editor.org/info/rfc6805>.

Authors' Addresses

   Olivier Dugeon
   Orange
   2, Avenue Pierre Marzin
   Lannion  22307
   France

   Email: olivier.dugeon@orange.com


   Julien Meuric
   Orange
   2, Avenue Pierre Marzin
   Lannion  22307
   France

   Email: julien.meuric@orange.com





















Dugeon & Meuric        Expires September 14, 2017              [Page 16]