One document matched: draft-dhody-pce-iro-update-00.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="std" docName="draft-dhody-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="October" 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>An informal survey was conducted to determine the state of current
and planned implementation with respect to IRO ordering and handling
of Loose 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 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 <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 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. </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>
</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>
| PAFTECH AB 2003-2026 | 2026-04-23 14:37:03 |