<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-dw-pce-service-segment-routing-01"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Service Segment Routing">PCEP Extensions for service
    segment used in Segment Routing</title>

    <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Divyashree Techno Park, Whitefield</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560037</code>

          <country>India</country>
        </postal>

        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <date year="2015"/>

    <area>Routing Area</area>

    <workgroup>PCE Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Path Computation Element</keyword>

    <abstract>
      <t>Segment Routing (SR) technology leverages the source routing and
      tunneling paradigms where a source node can choose a path without
      relying on hop-by-hop signaling.</t>

      <t>This document specifies extensions to the Path Computation Element
      Protocol (PCEP) that allow a stateful PCE to compute and instantiate
      SR-TE paths that also have a local service segments involved.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Segment Routing (SR) enables Traffic Engineering (TE) without relying
      on a hop-by-hop signaling. It depends only on "segments" that are
      advertised by Interior Gateway Protocols (IGPs). These segments made by
      -</t>

      <t><list style="symbols">
          <t>Node Segment</t>

          <t>Adjacency Segment</t>

          <t>Anycast Segment</t>

          <t>IGP-Prefix Segment</t>
        </list></t>

      <t>Further to this list, a segment may also be identify a particular
      value added service or service function (SF).
      <xref target="I-D.filsfils-spring-segment-routing-use-cases"/> describes using local
      Service-Segment to stand for a BGP-VPN service in an example. 
      A service-segment may also be used to represent specific treatment
      offered by SR enabled node(s) in the path, a combination of node-segment
      and service-segment can be used. The service segment is local to the SR
      enabled node.</t>

      <t>A stateful PCE can be used for computing one or more SR-TE paths
      taking into account various constraints and objective functions. Once a
      path is chosen, the stateful PCE can instantiate an SR-TE path on a PCC
      using PCEP extensions specified in <xref
      target="I-D.ietf-pce-segment-routing"/>.</t>

      <t>An SR-TE path is defined as a path that consists of one or more
      SID(s) where each SID is associated with the identifier that represents
      the node or adjacency corresponding to the SID. This document extends
      the SR-TE path to use Service-SID(s) in the path as well.</t>

      <t>The means by which the PCE learns about the Service-SID (e.g., learnt
      over a management interface or through a variety of other mechanisms) is
      beyond scope of this document.</t>
    </section>

    <section title="Conventions used in this document">
      <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">RFC2119</xref>.</t>

      <section title="Terminology">
        <t>The following terminologies are used in this document:<list>
            <t>ERO: Explicit Route Object</t>

            <t>IGP: Interior Gateway Protocol</t>

            <t>LSR: Label Switching Router</t>

            <t>PCC: Path Computation Client</t>

            <t>PCE: Path Computation Element</t>

            <t>PCEP: Path Computation Element Protocol</t>

            <t>SF: Service Function</t>

            <t>SFC: Service Function Chaining</t>

            <t>SID: Segment Identifier</t>

            <t>SR: Segment Routing</t>

            <t>SR-ERO: Segment Routed Explicit Route Object</t>

            <t>SR Path: Segment Routed Path</t>

            <t>SR-TE: Segment Routed Traffic Engineering</t>
          </list></t>
      </section>
    </section>

    <section title="Overview of PCEP Operation in SR Networks for      Service Chaining">
      <t>In SR networks, an ingress node of an SR path appends all outgoing
      packets with an SR header consisting of a list of Segment IDs (SIDs).
      The header has all necessary information to guide the packets from the
      ingress node to the egress node of the path, and hence there is no need
      for any signaling protocol. In the <xref
      target="I-D.ietf-pce-segment-routing"/>, an SID represents either a
      nodal segment representing a path to a node or adjacency segment
      representing path over a specific adjacency. In this document,we allow
      SID also can represent a service segment representing a specific
      treatment or SF.</t>

      <t>In a PCEP session, path information is carried in the Explicit Route
      Object (ERO), which consists of a sequence of subobjects. In this
      document, a PCE needs to specify EROs containing SID of service segments
      (or service-SID), and a PCC needs to be capable of processing such ERO
      sub-objects.</t>

      <t>The SR-ERO Subobject defined in the <xref
      target="I-D.ietf-pce-segment-routing"/> can be used to carry SID of
      service segment. An SR-ERO containing SID of service segment can be
      included in the same PCEP messages specified in the <xref
      target="I-D.ietf-pce-segment-routing"/>.</t>

      <t>When a PCEP session between a PCC and a PCE is established, the
      corresponding PCEP operation is same as defined in the
      <xref
      target="I-D.ietf-pce-segment-routing"/>.</t>
    </section>

    <section title="Object Formats">
      <t>In the <xref target="I-D.ietf-pce-segment-routing"/>, an SR-TE path
      is defined as a path that consists of one or more SID(s) where each SID
      is associated with the identifier that represents the node or adjacency
      corresponding to the SID. In this document, we allow the SR-TE path to
      include one or more SID of service segments (called service-SID) that
      are inserted along with node segments in SR-TE path. A service-segment
      may also be used to represent a set of SF instances. The service-SID is
      local to the node where the service resides, thus a combination of
      node-segment and service-segment are used together.</t>

      <section title="The SR-ERO Subobject extension for service segment support">
        <t>The SR-ERO Subobject is defined in section 5.3.1 of <xref
        target="I-D.ietf-pce-segment-routing"/> and as an mandatory subobject
        used to advertise SID and NAI ('Node or Adjacency Identifier')
        associated with SID. In this document, we extend the existing SR-ERO
        Subobject as specified in section 5.3.1 of <xref
        target="I-D.ietf-pce-segment-routing"/> to represent service-SID of
        the service segment.</t>

        <t>The SR-ERO Subobject as described in <xref
        target="I-D.ietf-pce-segment-routing"/>:</t>

        <figure>
          <artwork>
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|    Type     |     Length    |  ST   |     Flags     |F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                        NAI (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

</artwork>
        </figure>

        <t><list style="hanging">
            <t hangText="L"><vspace blankLines="1"/>The L bit SHOULD NOT be
            set, so that the subobject represents a strict hop in the explicit
            route in case of service-segment. <vspace blankLines="1"/></t>

            <t hangText="Type"><vspace blankLines="1"/>The Type is as per
            <xref target="I-D.ietf-pce-segment-routing"/>.<vspace
            blankLines="1"/></t>

            <t hangText="Length"><vspace blankLines="1"/>The Length is as per
            <xref target="I-D.ietf-pce-segment-routing"/>.<vspace
            blankLines="1"/></t>

            <t hangText="ST"><vspace blankLines="1"/>The ST (SID Type) field
            is set to specify service-SID. A new SID-Type values is to be
            assigned.<vspace blankLines="1"/></t>

            <t hangText="Flags"><vspace blankLines="1"/>All flags (M, C, S, F
            bit) are as per <xref
            target="I-D.ietf-pce-segment-routing"/>.<vspace
            blankLines="1"/></t>

            <t hangText="SID"><vspace blankLines="1"/>The SID value represents
            an service segment as described in <xref
            target="I-D.filsfils-spring-segment-routing-use-cases"/>.<vspace
            blankLines="1"/></t>

            <t hangText="NAI"><vspace blankLines="1"/>The NAI for
            service-segment may be defined in future based on the service.<vspace
            blankLines="1"/></t>
          </list></t>
      </section>

      <section title="Service Segment SR-ERO Processing">
        <t>When the SID represents a service segment (as per the SID Type - ST
        field), its value is local to node segment offering the service. Thus
        Service-SID MUST be associated with a node-SID preceding it in the
        SR-ERO. Note that multiple services may be offered by the same node,
        and in this case node-SID maybe followed by multiple Service-SID. NAI
        value for service-SID may be defined in future.</t>

        <t>If a service segment (or service-SID) cannot be associated with a
        node segment (or node-SID), PCEP speaker MUST send a PCE error with
        Error-Type = "Reception of an invalid object" and Error-Value
        ="Segment List Order Error".</t>

        <t>The rest of the processing rules are as per <xref
        target="I-D.ietf-pce-segment-routing"/>.</t>
      </section>
    </section>

    <section title="Backward Compatibility">
      <t>Backward Compatibility consideration described in section 8 of <xref
      target="I-D.ietf-pce-segment-routing"/> can be applied for service
      segment support as well.</t>
    </section>

    <section title="Management Considerations">
      <t>Management consideration described in section 9 of <xref
      target="I-D.ietf-pce-segment-routing"/> can be applied to service
      segment support as well.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations described in [RFC5440] and <xref
      target="I-D.ietf-pce-segment-routing"/> apply.</t>
    </section>

    <section title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

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

      <?rfc include="reference.I-D.ietf-pce-segment-routing"?>
    </references>

    <!-- Normative -->

    <references title="Informative References">
      <?rfc include="reference.I-D.filsfils-spring-segment-routing-use-cases"?>
    </references>

    <!-- Informative -->

    <section anchor="SEC_E" title="Examples" toc="default">
      <t>Consider the below example-</t>

      <figure>
        <artwork>  
            
          +---------+                      
          |         |                      
          |         |                      
          |         |                      
          |         |                      
          ++------+ |                      
          ||      | |                      
          || S 2  | |                      
+------+  |-------+ |  +------+-+  +------+
|      |  |-------+ |  |------+ |  |      |
|      |**||      | |**||     | |**|      |
|      |  || S 1  | |  || S 3 | |  |      |
|      |  |-------+ |  |------+ |  |      |
+------+  +-------+-+  +------+-+  +------+
   N1         N2          N3          N4 
</artwork>
      </figure>

      <t><list style="symbols">
          <t>N1 is Ingress;</t>

          <t>N4 is Egress;</t>

          <t>N2 has two services hosted identified as S1 and S2;</t>

          <t>N3 hase one service hosted identified as S3.</t>
        </list></t>

      <t>The SR-ERO for the SR-TE path including the service segment would be
      -</t>

      <t>[{SID_N2, SID_S1, SID_S2}, {SID_N3, SID_S3}, {SID_N4}]</t>
    </section>
  </back>
</rfc>
