| PCE Working Group | D. Dhody |
| Internet-Draft | Huawei Technologies |
| Intended status: Informational | October 10, 2014 |
| Expires: April 13, 2015 |
Informal Survey into Include Route Object (IRO) Implementations in Path Computation Element communication Protocol (PCEP)
draft-dhody-pce-iro-survey-00
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).
Since there was a proposal to have a new IRO type with ordering, as well as handling of Loose bit, it felt necessary to conduct a survey of the existing and planned implementations.
This document summarizes the survey questions and captures the results. Some conclusions are also presented.
This survey was informal and conducted via email. Responses were collected and anonymized by the PCE working group chairs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
[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.
[RFC5441] suggested the use of IRO to indicate the sequence of domains to be traversed during inter-domain path computation.
During discussion of [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.
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.
This document summarizes the survey questions and captures the results. Some conclusions are also presented.
The survey was introduced with the following text.
Hi PCE WG.
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.
Dhruv will process the results, but to improve confidentiality, answers may be sent privately to the chairs.
Thanks,
JP & Julien, on behalf of Dhruv
The following survey questions were asked, the survey questionnaire is listed verbatim below.
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?
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.
| Questions | Response | |
|---|---|---|
| 1a | Does your implementation construct IRO? | yes (9) |
| 1b | Does your implementation construct the IRO as an ordered list always, sometimes or never? | always (8), never (1) |
| 1c | What criteria do you use to decide if the IRO is an ordered or unordered list? | none (9) |
| 1d | Does your implementation construct the IRO as a sequence of strict hops or as a sequence of loose hops? | strict (5), loose (2), both (2) |
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.
| Questions | Response | |
|---|---|---|
| 2a | Does your implementation decode IRO? | yes (9) |
| 2b | Does your implementation interpret the decoded IRO as an ordered list always, sometimes or never? | always (7), sometimes (1), never (1) |
| 2c | What criteria do you use to decide if the IRO is an ordered or unordered list? | none (9) |
| 2d | Does your implementation interpret the IRO as a sequence of strict hops or as a sequence of loose hops? | strict (5), loose (2), both (2) |
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.
| Questions | Response | |
|---|---|---|
| 3a | Will there be an impact to your implementation if [RFC5440] is updated to state that the IRO is an ordered list? | none (9) |
| 3b | Will there be an impact to your implementation if [RFC5440] is updated to state that the IRO is an unordered list? | yes (5), no (4) |
| 3c | will there be an impact to your implementation if [RFC5440] is also updated to allow IRO sub-objects to use the loose bit (L-bit)? | none (5), yes(1), yes-but-small (3) |
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 [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.
The results shown in this survey seems to suggest that most implementations would be fine with updating [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 [RFC5440] to enable support for loose bit (L-bit) such that both strict and loose hops could be supported in the IRO.
The proposed action is as follows:
An update to draft-ietf-pce-pcep-domain-sequence-05 is one possible way to handle all of the above proposed action points.
This survey defines no protocols or procedures and so includes no security-related protocol changes. Clarification in the supported IRO ordering 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.
This informational document makes no requests to IANA for action.
A special thanks to author of [I-D.farrel-ccamp-ero-survey], this document borrow some of the structure and text from it.
| [RFC5440] | Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. |
| [RFC5441] | Vasseur, JP., Zhang, R., Bitar, N. and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. |
| [I-D.ietf-pce-pcep-domain-sequence] | Dhody, D., Palle, U. and R. Casellas, "Standard Representation Of Domain-Sequence", Internet-Draft draft-ietf-pce-pcep-domain-sequence-05, July 2014. |
| [I-D.farrel-ccamp-ero-survey] | Farrel, A., "Informal Survey into Explicit Route Object Implementations in Generalized Multiprotocol Labels Switching Signaling Implementations", Internet-Draft draft-farrel-ccamp-ero-survey-00, May 2006. |
Julien Meuric
Orange
EMail: julien.meuric@orange.com
Jean Philippe Vasseur
Cisco Systems, Inc.
EMail: jpv@cisco.com
Jonathan Hardwick
Metaswitch
100 Church Street
Enfield EN2 6BQ
UK
EMail: jonathan.hardwick@metaswitch.com