PCE Working Group D. Dhody
Internet-Draft Huawei Technologies
Intended status: Informational October 23, 2014
Expires: April 26, 2015

Informal Survey into Include Route Object (IRO) Implementations in Path Computation Element communication Protocol (PCEP)
draft-dhody-pce-iro-survey-01

Abstract

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.

Status of This Memo

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 26, 2015.

Copyright Notice

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.


Table of Contents

1. Introduction

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.

2. Survey Details

2.1. Survey Preamble

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

2.2. Survey Questions

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?

3. Respondents

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.

4. Results

IRO Encoding
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.

IRO Decoding
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.

Impact
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.

5. Conclusions

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.

5.1. Proposed Action

The proposed action is as follows:

  • Update [RFC5440] to specify IRO as an ordered list.
  • Update [RFC5440] to specify support for loose bit (L-bit) for IRO.
  • Remove the new IRO option from draft-ietf-pce-pcep-domain-sequence-05.

An update to IRO specification are proposed in [I-D.dhody-pce-iro-update].

6. Security Considerations

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.

7. IANA Considerations

This informational document makes no requests to IANA for action.

8. Acknowledgments

A special thanks to author of [I-D.farrel-ccamp-ero-survey], this document borrow some of the structure and text from it.

9. References

9.1. Normative References

[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

9.2. Informative References

[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-06, October 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.
[I-D.dhody-pce-iro-update] Dhody, D., "Update to Include Route Object (IRO) specification in Path Computation Element communication Protocol (PCEP)", Internet-Draft draft-dhody-pce-iro-update-00, October 2014.

Appendix A. Contributor Addresses

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
        

Author's Address

Dhruv Dhody Huawei Technologies Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruv.ietf@gmail.com