<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-dugeon-brpc-stateful-00" ipr="trust200902">
  <front>
    <title abbrev="BRPC Stateful">A Backward Recursive PCE-initiated
    inter-domain LSP Setup</title>

    <author fullname="Olivier Dugeon" initials="O.D." surname="Dugeon">
      <organization>Orange</organization>

      <address>
        <postal>
          <street>2, Avenue Pierre Marzin</street>

          <city>Lannion</city>

          <code>22307</code>

          <country>France</country>
        </postal>

        <email>olivier.dugeon@orange.com</email>
      </address>
    </author>

    <author fullname="Julien Meuric" initials="J.M." surname="Meuric">
      <organization>Orange</organization>

      <address>
        <postal>
          <street>2, Avenue Pierre Marzin</street>

          <city>Lannion</city>

          <code>22307</code>

          <country>France</country>
        </postal>

        <email>julien.meuric@orange.com</email>
      </address>
    </author>

    <date day="13" month="March" year="2017"/>

    <area>Routing Area</area>

    <workgroup>Path Computation Element Working Group</workgroup>

    <keyword>Draft</keyword>

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Problem Statement">
      <t>Looking to the different RFCs that describe the PCE architecture and
      in particular <xref target="RFC4655">PCE based architecture </xref>,
      <xref target="RFC5440">PCE protocol</xref>, <xref target="RFC5441">
      BRPC</xref> and <xref target="RFC6805">H-PCE</xref>, 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:</t>

      <t><list style="symbols">
          <t>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.</t>

          <t>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.</t>

          <t>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.</t>
        </list>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 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.</t>

      <t>The purpose of this memo is to take the benefit of PCE stateful mode
      as per <xref target="I-D.ietf-pce-stateful-pce">draft pce
      stateful</xref> and <xref target="I-D.ietf-pce-pce-initiated-lsp">draft
      pce initiated</xref> 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
      <xref target="RFC5441">BRPC</xref>, 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.</t>

      <section title="General assumptions">
        <t>In the rest of this document, we used the same references as per
        <xref target="RFC5441">BRPC</xref> and make the following set of
        assumptions (see figure below):</t>

        <t><list style="symbols">
            <t>Domain refers to an IGP area or an Autonomous System (AS).</t>

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

            <t>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.</t>

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

            <t>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 <xref target="I-D.dong-pce-discovery-proto-bgp">'BGP
            Extensions for Path Computation Element (PCE)
            Discovery'</xref>,</t>

            <t>PCEs are able to compute and end-o-end path as per <xref
            target="RFC5441">BRPC procedure</xref>.</t>
          </list></t>

        <t><figure>
            <artwork align="center"
                     name="Example of the representation of 3 domains with 3 PCEs"><![CDATA[
          +----------------+          +----------------+
          |  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
  ]]></artwork>
          </figure></t>
      </section>

      <section title="Terminology">
        <t>ABR: Area Border Routers. Routers used to connect two IGP areas
        (areas in OSPF or levels in IS-IS).</t>

        <t>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.</t>

        <t>AS: Autonomous System</t>

        <t>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.</t>

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

        <t>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).</t>

        <t>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).</t>

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

        <t>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.</t>

        <t>Local LSP tunnel(i): A local LSP tunnel of domain(i)</t>

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

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

        <t>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.</t>

        <t>PCE(i) is a PCE with the scope of domain(i).</t>
      </section>
    </section>

    <section title="Stitching Label">
      <t>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.</t>

      <section title="Definition">
        <t>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).</t>

        <t>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, 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.</t>

        <t>As per <xref target="RFC4003">RFC4003</xref>, 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).</t>
      </section>

      <section title="Inter-domain LSP-TYPE">
        <t>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 <xref
        target="I-D.ietf-pce-lsp-setup-type">draft lsp setup type</xref> with
        new values (See IANA section of this memo) defined as follow:</t>

        <t><list style="symbols">
            <t>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).</t>

            <t>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.</t>

            <t>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.</t>
          </list></t>
      </section>
    </section>

    <section title="Inter-domain LSP tunnels setup procedure">
      <t>This section describes how to setup inter-domain LSP tunnels than
      cross several different domains.</t>

      <section title="Mode of operation">
        <t>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.</t>

        <t>First, the PCE(S) run standard BRPC algorithm as per <xref
        target="RFC5441">RFC5441</xref> 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 <xref target="RFC5520">RFC5520</xref> 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.</t>

        <t>The complete procedure follow the different steps described
        below:</t>

        <t>Steps 1: Initialization</t>

        <t>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 &gt; 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).</t>

        <t>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).</t>

        <t>Steps 2: Actions taken at the destination domain(n)</t>

        <t>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.</t>

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

        <t><list style="numbers">
            <t>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.</t>

            <t>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).</t>

            <t>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.</t>

            <t>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)}.</t>

            <t>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.</t>
          </list></t>

        <t>Steps n: Actions performed at the source domain(1)</t>

        <t>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.</t>

        <t>To use Segment Routing instead of RSVP-TE to setup the LSP tunnels
        as defined in <xref target="I-D.ietf-pce-segment-routing">draft pce
        segment routing </xref>, 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.</t>
      </section>

      <section title="Example">
        <t>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:</t>

        <t><list style="symbols">
            <t>PKS(D) = Path Key correponding to the path from BN(D) to
            PE-D</t>

            <t>ERO(D) = Explicit Route Object corresponding to the path from
            BN(D) to PE-D retrieves from PKS(D)</t>

            <t>RRO(D) = Record Route Object of Local LSP tunnel(D) from BN(D)
            to PE-D</t>

            <t>SL(D) = Stitching Label for Local LSP tunnel from BN(D) to
            PE-D</t>

            <t>ERO(S) = Explicit Route Object corresponding to the path from
            PE-S to BN(S)</t>

            <t>RRO(S) = Record Route Object of Local LSP tunnel(S) from PE-S
            to BN(S)</t>
          </list></t>

        <t><list style="numbers">
            <t/>
          </list></t>

        <t><figure>
            <artwork><![CDATA[
  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

]]></artwork>
          </figure></t>
      </section>

      <section title="Inter-domain LSP setup procedure completion failure">
        <t>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 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.</t>

        <t>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).</t>

        <t>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 <xref
        target="I-D.ietf-pce-pce-initiated-lsp">draft pce initiated lsp</xref>
        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).</t>
      </section>

      <section title="Inter-domain LSP management">
        <t>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.</t>

        <t>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).</t>

        <t>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.</t>

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

        <t>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
        PCE(1) to take appropriate correction e.g. start a new BRPC to compute
        a new ERO.</t>
      </section>
    </section>

    <section title="Applicability">
      <t>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).</t>

      <t>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.</t>

      <t>In inter-layer scenario is left for further study.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section title="LSP-TYPE values">
        <t><xref target="I-D.ietf-pce-lsp-setup-type">Draft pce lsp setup
        type</xref> 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:</t>

        <texttable align="left" suppress-title="true">
          <ttcol>Value</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Reference</ttcol>

          <c>TBD1</c>

          <c>Inter-Domain Traffic engineering end-to-end path is setup using
          Backward Recursive method</c>

          <c>This Document</c>

          <c>TBD2</c>

          <c>Inter-Domain Traffic engineering local path is setup using
          RSVP-TE</c>

          <c>This Document</c>

          <c>TBD3</c>

          <c>Inter-Domain Traffic engineering local path is setup using
          Segment Routing</c>

          <c>This Document</c>
        </texttable>
      </section>

      <section title="PCEP-Error Object">
        <t>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:</t>

        <texttable>
          <ttcol>Error-Value</ttcol>

          <ttcol>Description</ttcol>

          <c>TBD4</c>

          <c>Missing Mandatory Stitching Label in RRO</c>
        </texttable>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>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 <xref target="I-D.ietf-pce-pceps">draft secure
      transport for PCEP</xref> or use any other secure tunnel mechanism e.g.
      IPsec tunnel to transport PCEP session between PCE.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors want to thanks PCE's WG members.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5441.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4003.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5520.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6805.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-stateful-pce-18.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-pce-initiated-lsp-09.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-lsp-setup-type-03.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-pceps-11.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pce-segment-routing-08.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-dong-pce-discovery-proto-bgp-06.xml"?>
    </references>
  </back>
</rfc>
