One document matched: draft-dhody-pce-iro-survey-02.xml

<?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="info" docName="draft-dhody-pce-iro-survey-02" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="IRO-SURVEY">Informal Survey into Include Route Object 
    (IRO) Implementations 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="December" year="2014" />
    <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>Since there was a proposal to have a new IRO type with ordering,
   as well as handling of Loose bit (L-Bit), it 
   felt necessary to conduct a survey of the existing and planned
   implementations.</t>

   <t>This document summarizes the survey questions and captures the
   results. Some conclusions are also presented.</t>

   <t>This survey was informal and conducted via email. Responses were
   collected and anonymized by the PCE working group chairs.</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 L bit (loose) 
   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 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 was informal and conducted
   via email. Responses were collected and anonymized by the PCE working
   group chair.</t>
   
   <t>This document summarizes the survey questions and 
   captures the results. Some conclusions are also presented.</t>
    </section>

    <section title="Survey Details" toc="default">
    <section title="Survey Preamble" toc="default">
    <t>The survey was introduced with the following text.</t>
    <t>Hi PCE WG.</t>

    <t>To address the issues associated with 
    draft-ietf-pce-pcep-domain-sequence and "Include Route Object" in 
    PCEP, Dhruv has proposed to start a small survey. If implementers 
    agree that we need to clarify this, they would be much welcome to 
    answer the attached questions.</t>

    <t>Dhruv will process the results, but to improve confidentiality, 
    answers may be sent privately to the chairs.</t>

    <t>Thanks,</t>
    <t>JP & Julien, on behalf of Dhruv</t>
    </section>
    <section title="Survey Questions" toc="default">
    <t>The following survey questions were asked, the survey questionnaire is listed verbatim below.</t>
<figure>
<artwork>

    During discussion of draft-ietf-pce-pcep-domain-sequence-05,  
    it has been noted that RFC 5440 does not define whether the 
    sub-objects in the IRO are ordered or unordered.

    We would like to do an informal and *confidential* survey  
    of current implementations, to help clarify this 
    situation.

    1. IRO Encoding

        a. Does your implementation construct IRO?

        b. If your answer to part (a) is Yes, does your 
           implementation construct the IRO as an ordered list 
           always, sometimes or never?

        c. If your answer to part (b) is Sometimes, what criteria 
           do you use to decide if the IRO is an ordered or 
           unordered list?

        d. If your answer to part (b) is Always or Sometimes, does 
           your implementation construct the IRO as a sequence of 
           strict hops or as a sequence of loose hops?

    2. IRO Decoding

        a. Does your implementation decode IRO?

        b. If your answer to part (a) is Yes, does your 
           implementation interpret the decoded IRO as an ordered 
           list always, sometimes or never?

        c. If your answer to part (b) is Sometimes, what criteria do 
           you use to decide if the IRO is an ordered or unordered 
           list?

        d. If your answer to part (b) is Always or Sometimes, does 
           your implementation interpret the IRO as a sequence of 
           strict hops or as a sequence of loose hops?

    3. Impact

        a. Will there be an impact to your implementation if RFC 5440 
           is updated to state that the IRO is an ordered list?

        b. Will there be an impact to your implementation if RFC 5440
           is updated to state that the IRO is an unordered list?

        c. If RFC 5440 is updated to state that the IRO is an  
           ordered list, will there be an impact to your 
           implementation if RFC 5440 is also updated to allow IRO 
           sub-objects to use the loose bit (L-bit)?

    4. Respondents

        a. Are you a Vendor/Research Lab/Software House/Other (please
           specify)? 
      
        b. If your answer to part (a) is Vendor, is the 
           implementation for a shipping product, product under 
           development or a prototype?
</artwork>
</figure>
    </section>      
    </section>
    <section title="Respondents" toc="default">
    <t>Total 9 responses were received from
    vendors, software houses, and research labs. Vendors made responses 
    for their current shipping products as well as products that they 
    currently have under development.
    <list style="symbols">
    <t>Total Number of Respondents: 9
    <list style="symbols">
    <t>Vendors: 4
    <list style="symbols">
    <t>Shipping Product: 1</t>
    <t>Product Under Development: 1</t>
    <t>Prototype: 1</t>
    <t>Unknown: 1</t>
    </list>
    </t>
    
    
    <t>Software House: 1</t>
    <t>Research Labs: 2
    <list style="symbols">
    <t>Operator's Research Facility: 1</t>
    </list>
    </t>
    <t>Open Source: 1
    <list style="symbols">
    <t>Shipped Release: 1</t>
    </list>
    </t>
    <t>Others (or Unknown): 1</t>
    </list>
    </t>
    </list>
    </t>
    </section>

    <section title="Results" toc="default">
    <texttable anchor="tab.result1" title="IRO Encoding" suppress-title="false" align="center" style="full">
        <ttcol align="left"> </ttcol>
        <ttcol align="left">Questions</ttcol>
        <ttcol align="left">Response</ttcol>
        <c>1a</c><c>Does your implementation construct IRO?</c><c>yes (9)</c>
        <c></c><c></c><c></c>
        <c>1b</c><c>Does your implementation construct the IRO as an ordered 
        list always, sometimes or never?</c><c>always (8), never (1)</c>
        <c></c><c></c><c></c>
        <c>1c</c><c>What criteria do you use to decide if the IRO is an ordered 
        or unordered list?</c><c>none (9)</c>
        <c></c><c></c><c></c>
        <c>1d</c><c>Does your implementation construct the IRO as a sequence of
        strict hops or as a sequence of loose hops?</c><c>strict (5), loose (2), 
        both (2)</c>
        </texttable>
        <t>Regarding IRO encodings, most implementations construct 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.</t>
        <texttable anchor="tab.result2" title="IRO Decoding" suppress-title="false" align="center" style="full">
        <ttcol align="left"> </ttcol>
        <ttcol align="left">Questions</ttcol>
        <ttcol align="left">Response</ttcol>
        <c>2a</c><c>Does your implementation decode IRO?</c><c>yes (9)</c>
        <c></c><c></c><c></c>
        <c>2b</c><c>Does your implementation interpret the decoded IRO as an 
        ordered list always, sometimes or never?</c><c>always (7), sometimes 
        (1), never (1)</c>
        <c></c><c></c><c></c>
        <c>2c</c><c>What criteria do you use to decide if the IRO is an ordered 
        or unordered list?</c><c>none (9)</c>
        <c></c><c></c><c></c>
        <c>2d</c><c>Does your implementation interpret the IRO as a sequence of 
        strict hops or as a sequence of loose hops?</c><c>strict (5), loose (2),
        both (2)</c>
        </texttable>
        <t>Regarding IRO decoding, most implementations interpret IRO as an 
        ordered list. More than half of implementation under survey consider 
        the IRO sub-objects as strict hops, others consider loose or support 
        both.</t>
        <texttable anchor="tab.result3" title="Impact" suppress-title="false" align="center" style="full">
        <ttcol align="left"> </ttcol>
        <ttcol align="left">Questions</ttcol>
        <ttcol align="left">Response</ttcol>
        <c>3a</c><c>Will there be an impact to your implementation if <xref target="RFC5440"/> 
        is updated to state that the IRO is an ordered list?</c><c>none (9)</c>
        <c></c><c></c><c></c>
        <c>3b</c><c>Will there be an impact to your implementation if <xref target="RFC5440"/> 
        is updated to state that the IRO is an unordered list?</c><c>yes (5), no (4)</c>
        <c></c><c></c><c></c>
        <c>3c</c><c>will there be an impact to your implementation if <xref target="RFC5440"/> 
        is also updated to allow IRO sub-objects to use the loose bit (L-bit)?</c><c>none (5), yes(1), yes-but-small (3)</c>
      </texttable>
      <t>It is interesting to note that most implementation that responded to 
      the survey finds that there is no impact to their existing or 
      under-development implementation if <xref target="RFC5440"/> is updated 
      to state that the IRO as an ordered list. Further most implementations 
      find that support for loose bit (L-bit) for IRO has minimal or no impact 
      on their implementation.</t>
    </section>

    <section title="Conclusions" toc="default">
    <t>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 with no impact on the shipping or under-development products. 
    It is also the conclusion of this survey to suggest that it would be helpful
    to update <xref target="RFC5440"/> to enable support for loose bit (L-bit)
    such that both strict and loose hops could be supported in the IRO.</t>
    <section title="Proposed Action" toc="default">
    <t>The proposed action is as follows:
    <list style="symbols">
    <t>Update <xref target="RFC5440"/> to specify IRO as an ordered list.</t>
    <t>Update <xref target="RFC5440"/> to specify support for loose bit (L-bit) 
    for IRO.</t>
    <t>Remove the new IRO option from draft-ietf-pce-pcep-domain-sequence-05. </t>
    </list>
    </t>
    
    <t>An update to IRO specification are proposed in <xref target='I-D.dhody-pce-iro-update'/>. 
    </t>
    
    </section>
    </section>
    
    <section title="Security Considerations" toc="default">
      <t>This survey defines no protocols or procedures and so includes 
      no security-related protocol changes. Clarification in the 
      supported IRO ordering or loose bit handling will not have any negative security impact.
     The survey responses in this document were collected by email and
     that email was not authenticated, although responses were sent to
     the respondents that might have triggered alarms if the responses
     were spoofed. Spoofed or malicious responses could represent an
     attack on the IETF process and so this survey should be treated
     with some caution where there is reason to suspect such an attack.
     Further, this survey was compiled and anonymized by the working 
     group chairs.</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 author of 
      <xref target='I-D.farrel-ccamp-ero-survey'/>, this document borrow
      some of the structure and text from it.</t>
    </section>    
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.5440.xml" ?>
    </references>
    <references title="Informative References">
     <?rfc include="reference.RFC.5441.xml" ?>
      <?rfc include="reference.I-D.ietf-pce-pcep-domain-sequence"?>
      <?rfc include="reference.I-D.farrel-ccamp-ero-survey"?>
      <?rfc include="reference.I-D.dhody-pce-iro-update"?>

    </references>
<section title="Contributor Addresses" toc="default">
    <t>
    <figure title="" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Julien Meuric
Orange
France

EMail: julien.meuric@orange.com

Jonathan Hardwick
Metaswitch
100 Church Street
Enfield  EN2 6BQ
UK

EMail: jonathan.hardwick@metaswitch.com
        ]]></artwork>
        </figure>
      </t>
    </section>    
  </back>
</rfc>