<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-pce-iro-update-00" obsoletes="" updates="5440" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="IRO-UPDATE">Update to Include Route Object 
    (IRO) specification in Path Computation Element communication 
    Protocol (PCEP)</title>
    <author initials="D" surname="Dhody" fullname="Dhruv Dhody">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Leela Palace</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560008</code>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <date month="March" year="2015" />
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>
    <abstract>
   <t> 
   During discussions of a document to provide a standard representation
   and encoding of Domain-Sequence within the Path Computation 
   Element (PCE) communication Protocol (PCEP) for communications 
   between a Path Computation Client (PCC) and a PCE, or between two 
   PCEs. It was determined that there was a need for clarification with 
   respect to the ordered nature of the
   Include Route Object (IRO).</t>

   <t>An informal survey was conducted to determine the state of current
   and planned implementation with respect to IRO ordering and handling
   of Loose bit (L bit).</t>

   <t>This document updates the IRO specification based on the survey
   conclusion and recommendation.</t>   
   
   </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
   <t>The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.</t>

   <t><xref target="RFC5440"/> defines the Include Route Object (IRO) to 
   specify that the computed path must traverse a set of specified 
   network elements. The specification did not mention if IRO is an ordered or 
   un-ordered list of sub-objects. It mentioned that the Loose bit (L bit) 
   has no meaning within an IRO.</t>
    
   <t><xref target="RFC5441"/> suggested the use of IRO 
   to indicate the sequence of domains to be traversed during 
   inter-domain path computation.</t>   
   
   <t>During discussion of <xref target='I-D.ietf-pce-pcep-domain-sequence'/>
   it was proposed to have a new IRO type with ordered nature, as well 
   as handling of Loose bit (L bit).</t>
   
   <t>In order to discover the current state of 
   affairs amongst implementations a survey of the existing and planned 
   implementations was conducted. This survey <xref target="I-D.dhody-pce-iro-survey"/> was informal and conducted
   via email. Responses were collected and anonymized by the PCE working
   group chair.</t>
   
   <t>This document updates the IRO specifications in <xref target="RFC5440"/> as per
    the conclusion and action points presented in <xref target="I-D.dhody-pce-iro-survey"/>.</t>
          <section title="Requirements Language" toc="default">
        <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"/>.</t>
      </section>
    </section>
<section title="Update in IRO specification" toc="default" anchor="SEC_IRO_UPD">
      <t><xref target="RFC5440"/> describes IRO as an optional object used to specify
   that the computed path MUST traverse a set of specified network
   elements. It further state that the Loose bit (L bit) of such sub-object has 
   no meaning within an IRO. It did not mention if IRO is an ordered or 
   un-ordered list of sub-objects.  </t>
   <t>A survey of the existing and planned implementations
   was conducted in order to discover the current state of affairs amongst
   implementations. <xref target="I-D.dhody-pce-iro-survey"/> describe the questionnaire, 
   results and presents some conclusions and proposed action items. More details 
   in <xref target="SEC_A"/>.   </t>
   <t>The survey suggest that most implementations construct or interpret IRO in an
   ordered fashion and consider it to be an ordered list.  More than
   half of implementation under survey consider the IRO sub-objects as
   strict hops, others consider loose or support both. The results shown in this 
   survey seems to suggest that most
   implementations would be fine with updating <xref target="RFC5440"/> to specify IRO
   as an ordered list as well as to enable
   support for Loose bit (L bit) such that both strict and loose hops
   could be supported in the IRO.</t>
   <t>This document thus updates <xref target="RFC5440"/> regarding the IRO 
   specification making IRO as an ordered list as well as support for Loose bit (L bit).</t>
   <t>The content of an IRO object is an ordered list of subobjects 
   representing a series of abstract nodes. An abstract node may just be a 
   simple abstract node comprising one node or a group of nodes for example
   an AS (comprising of multiple
   hops within the AS) (refer <xref target="RFC3209"/> for details). Further each subobject has an 
   attribute called 'L bit', which is set if the subobject represents a loose 
   hop. If the bit is not set, the subobject represents a strict hop. The
   interpretation of Loose bit (L bit) is as per section 4.3.3.1 of <xref target="RFC3209"/>.
</t>
   </section>
      
    <section title="Other Considerations" toc="default">
    <t>Based on the survey, it should be noted that most implementation already
    support the update in the IRO specification as per this document. The other
    implementation are expected to make an update to the IRO procedures.</t>
    
    
    </section>
    <section title="Security Considerations" toc="default">
    <t>This update in IRO specification does not introduce any
    new security considerations, apart from those mentioned in 
    <xref target="RFC5440"/>.  Clarification in the 
    supported IRO ordering or Loose bit handling will not have any negative security impact.
     </t>
     <t>It is worth noting that PCEP operates over TCP.  An analysis of the
   security issues for routing protocols that use TCP (including PCEP)
   is provided in <xref target="RFC6952"/>, while <xref target="I-D.ietf-pce-pceps"/> discusses an
   experimental approach to provide secure transport for PCEP.</t>
    </section>
      
    <section title="IANA Considerations" toc="default">
    <t>This informational document makes no requests to IANA for action.</t>
    </section>
    
    <section title="Acknowledgments" toc="default">
      <t>A special thanks to PCE chairs for guidance regarding this work.</t>
      <t>Thanks to Francesco Fondelli for his suggestions in clarifying the L bit usage.</t>
    </section>    
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.2119.xml" ?>
    <?rfc include="reference.RFC.5440.xml" ?>
    </references>
    <references title="Informative References">
     <?rfc include="reference.RFC.3209.xml" ?>
     <?rfc include="reference.RFC.5441.xml" ?>
     <?rfc include="reference.RFC.6952.xml" ?>
      <?rfc include="reference.I-D.ietf-pce-pcep-domain-sequence"?>
      <?rfc include="reference.I-D.ietf-pce-pceps"?>
      <?rfc include="reference.I-D.dhody-pce-iro-survey"?>

    </references>
    <section title="Details of IRO survey" toc="default" anchor="SEC_A">
   <t>During discussions of this document to provide a standard representation
   and encoding of Domain-Sequence within PCEP.  It was
   determined that there was a need for clarification with respect to
   the ordered nature of the IRO.</t>

   <t>Since there was a proposal to have a new IRO type with ordering, 
   as well as handling of Loose bit, 
   in an earlier version of this document (refer - 
   draft-ietf-pce-pcep-domain-sequence-05),  it was deemed necessary 
   to conduct a survey of the existing and planned implementations. 
   An informal survey was conducted via email.  Responses were
   collected and anonymized by the PCE working group chairs.</t>

   <t><xref target="I-D.dhody-pce-iro-survey"/> summarizes the survey questions and 
   captures the results. It further list some conclusions and
   action points.</t>

   <t>This document was considered as one possible
   venue to handle the proposed action points.</t>
    </section>
  </back>
</rfc>
