[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

PCE Working Group                                               D. Dhody
Internet-Draft                                       Huawei Technologies
Intended status: Informational                         December 26, 2014
Expires: June 29, 2015


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

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 (L-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 June 29, 2015.






Dhody                     Expires June 29, 2015                 [Page 1]


Internet-Draft                 IRO-SURVEY                  December 2014


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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Survey Details  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Survey Preamble . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Survey Questions  . . . . . . . . . . . . . . . . . . . .   3
   3.  Respondents . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Results . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Proposed Action . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  10

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.




Dhody                     Expires June 29, 2015                 [Page 2]


Internet-Draft                 IRO-SURVEY                  December 2014


   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



Dhody                     Expires June 29, 2015                 [Page 3]


Internet-Draft                 IRO-SURVEY                  December 2014


           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)?




Dhody                     Expires June 29, 2015                 [Page 4]


Internet-Draft                 IRO-SURVEY                  December 2014


           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.

   o  Total Number of Respondents: 9

      *  Vendors: 4

         +  Shipping Product: 1

         +  Product Under Development: 1

         +  Prototype: 1

         +  Unknown: 1

      *  Software House: 1

      *  Research Labs: 2

         +  Operator's Research Facility: 1

      *  Open Source: 1

         +  Shipped Release: 1

      *  Others (or Unknown): 1

4.  Results















Dhody                     Expires June 29, 2015                 [Page 5]


Internet-Draft                 IRO-SURVEY                  December 2014


   +----+---------------------------------------------+----------------+
   |    | Questions                                   | Response       |
   +----+---------------------------------------------+----------------+
   | 1a | Does your implementation construct IRO?     | yes (9)        |
   |    |                                             |                |
   | 1b | Does your implementation construct the IRO  | always (8),    |
   |    | as an ordered list always, sometimes or     | never (1)      |
   |    | never?                                      |                |
   |    |                                             |                |
   | 1c | What criteria do you use to decide if the   | none (9)       |
   |    | IRO is an ordered or unordered list?        |                |
   |    |                                             |                |
   | 1d | Does your implementation construct the IRO  | strict (5),    |
   |    | as a sequence of strict hops or as a        | loose (2),     |
   |    | sequence of loose hops?                     | both (2)       |
   +----+---------------------------------------------+----------------+

                           Table 1: IRO Encoding

   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     | always (7),     |
   |    | decoded IRO as an ordered list always,     | sometimes (1),  |
   |    | sometimes or never?                        | never (1)       |
   |    |                                            |                 |
   | 2c | What criteria do you use to decide if the  | none (9)        |
   |    | IRO is an ordered or unordered list?       |                 |
   |    |                                            |                 |
   | 2d | Does your implementation interpret the IRO | strict (5),     |
   |    | as a sequence of strict hops or as a       | loose (2), both |
   |    | sequence of loose hops?                    | (2)             |
   +----+--------------------------------------------+-----------------+

                           Table 2: IRO Decoding

   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.




Dhody                     Expires June 29, 2015                 [Page 6]


Internet-Draft                 IRO-SURVEY                  December 2014


   +----+----------------------------------------------+---------------+
   |    | Questions                                    | Response      |
   +----+----------------------------------------------+---------------+
   | 3a | Will there be an impact to your              | none (9)      |
   |    | implementation if [RFC5440] is updated to    |               |
   |    | state that the IRO is an ordered list?       |               |
   |    |                                              |               |
   | 3b | Will there be an impact to your              | yes (5), no   |
   |    | implementation if [RFC5440] is updated to    | (4)           |
   |    | state that the IRO is an unordered list?     |               |
   |    |                                              |               |
   | 3c | will there be an impact to your              | none (5),     |
   |    | implementation if [RFC5440] is also updated  | yes(1), yes-  |
   |    | to allow IRO sub-objects to use the loose    | but-small (3) |
   |    | bit (L-bit)?                                 |               |
   +----+----------------------------------------------+---------------+

                              Table 3: Impact

   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:

   o  Update [RFC5440] to specify IRO as an ordered list.

   o  Update [RFC5440] to specify support for loose bit (L-bit) for IRO.

   o  Remove the new IRO option from draft-ietf-pce-pcep-domain-
      sequence-05.





Dhody                     Expires June 29, 2015                 [Page 7]


Internet-Draft                 IRO-SURVEY                  December 2014


   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", draft-ietf-pce-pcep-
              domain-sequence-06 (work in progress), October 2014.






Dhody                     Expires June 29, 2015                 [Page 8]


Internet-Draft                 IRO-SURVEY                  December 2014


   [I-D.farrel-ccamp-ero-survey]
              Farrel, A., "Informal Survey into Explicit Route Object
              Implementations in Generalized Multiprotocol Labels
              Switching Signaling Implementations", draft-farrel-ccamp-
              ero-survey-00 (work in progress), May 2006.

   [I-D.dhody-pce-iro-update]
              Dhody, D., "Update to Include Route Object (IRO)
              specification in Path Computation Element communication
              Protocol (PCEP)", draft-dhody-pce-iro-update-01 (work in
              progress), October 2014.








































Dhody                     Expires June 29, 2015                 [Page 9]


Internet-Draft                 IRO-SURVEY                  December 2014


Appendix A.  Contributor Addresses

   Julien Meuric
   Orange
   France

   EMail: julien.meuric@orange.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


























Dhody                     Expires June 29, 2015                [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/