Update to Include Route Object
(IRO) specification in Path Computation Element communication
Protocol (PCEP)Huawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560037Indiadhruv.ietf@gmail.com
Routing
PCE Working Group
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).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).This document updates RFC 5440 regarding the IRO specification, based on the survey
conclusion and recommendation.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. defines the Include Route Object (IRO) to
specify network elements to be traversed in the computed path.
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. suggested the use of IRO
to indicate the sequence of domains to be traversed during
inter-domain path computation.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.During discussion of
it was proposed to have a new IRO type with ordered nature, as well
as handling of Loose bit (L bit); however, with the update to
described in this document, no new IRO type is needed.This document updates the IRO specifications in section 7.12 of as per
the conclusion and action points presented in .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 .Section 7.12 of describes IRO as an optional object used to specify
a set of network elements to be traversed in the computed path.
It also states that the Loose bit (L bit) in sub-object has
no meaning within an IRO. It did not mention if IRO is an ordered or
un-ordered list of sub-objects. A survey of the existing and planned implementations
was conducted in order to discover the current state of affairs amongst
implementations. describe the questionnaire,
results and presents some conclusions and proposed action items. 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 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.Section 7.12 of regarding the IRO
specification is updated to remove the last line in the section 7.12
of , that statesFurther, the Section 7.12 of is updated
to add following two statements - - The content of IRO is an ordered list of sub-objects
representing a series of abstract nodes.
An abstract node could 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 section 4.3.2 of ). - The L Bit of IRO sub-object is set based on the loose or strict
property of the sub-object, which is set
if the sub-object represents a loose hop. If the bit is not set, the
sub-object represents a strict hop. The
interpretation of Loose bit (L bit) is as per section
4.3.3.1 of .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
based on this document.During the survey it was also noted that minority of the implementations,
interpreted the IRO sub-objects as loose, when these implementation
interwork with an implementation conforming to this document, the
following impact might be seen -
If a non-conforming (to this document) PCC sends an IRO, to a
conforming (to this document) PCE, then the PCE may unexpectedly
fail to find a path (since the PCC may think of IRO sub-objects
as loose hops, but the PCE interprets them as strict hops).If a conforming PCC sends an IRO containing strict hops to a
non-conforming PCE, then the PCE may erroneously return a path
that does not comply with the requested strict hops (since PCE
interprets them all as loose hops). The PCC may check the
returned path and find the issue or it may end up using incorrect
path.Thus it is RECOMMENDED that network operators ensure that all PCEP
speakers in their network conform to this document with updated
IRO specification if they intend to use IRO.This update in IRO specification does not introduce any
new security considerations, apart from those mentioned in
. Clarification in the
supported IRO ordering or Loose bit handling will not have any negative security impact.
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 , while discusses an
experimental approach to provide secure transport for PCEP.This document makes no requests to IANA for action.A special thanks to PCE chairs for guidance regarding this work.Thanks to Francesco Fondelli for his suggestions in clarifying the L bit usage.Thanks to Adrian Farrel for his review and comments.Thanks to Jonathan Hardwick for document shepherding and providing text in .Thanks to Deborah Brungard for her comments and being the responsible AD.