Network Working Group Adrian Farrel Internet Draft Old Dog Consulting Category: Informational Expiration Date: November 2006 May 2006 Informal Survey into Explicit Route Object Implementations in Generalized Multiprotocol Labels Switching Signaling Implementations Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract During discussions of a document to provide guidance on the use of addressing fields within the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling protocol used in Generalized Multiprotocol Label Switching (GMPLS), it was determined that there was considerable variation in the implementation of options for the Explicit Route Object (ERO). Since there was a proposal to deprecate some of the options, it was 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 CCAMP working group chair. A. Farrel [Page 1] draft-farrel-ccamp-ero-survey-00.txt May 2006 1. Introduction [GMPLS-ADDR] documents advice and procedures for filling in protocol fields that contain addresses within the signaling and routing protocols in the Generalized Multiprotocol Label Switching (GMPLS) protocol family. The Resource Reservation Protocol (RSVP) [RFC2205] has been extended as RSVP for Traffic Engineering (RSVP-TE) for use in Multiprotocol Label Switching (MPLS) signaling [RFC3209] and Generalized MPLS (GMPLS) [RFC3473]. [RFC3209] defines the Explicit Route Object (ERO) to encode the explicit path of a Label Switched Path (LSP) through the network. This object and its encoding rules are inherited by [RFC3473], but further details specific to GMPLS are added in [RFC3473] under the guidance of [RFC3471]. [RFC4201] introduces additional GMPLS-specific ERO encodings. In total there are many options about how an ERO may be constructed, and therefore some confusion about what EROs a Label Switching Router (LSR) may construct and what ERO formats an LSR must be able to process. During discussion of [GMPLS-ADDR] it was proposed that unused and unwanted options for ERO construction within the existing RFCs be deprecated. However, it was unclear which options were commonly supported, which were used, and which might be safely deprecated. 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 CCAMP 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. In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03 we determined that implementations must support any form of ERO that is legitimately sent by any other implementation. At the same time there is a desire to reduce the number of options if this is possible. Lastly, there was some confusion about what the RFCs actually allow you to do, and rather than debate this as though we were lawyers, it may be more profitable to look at what current implementations do. A. Farrel [Page 2] draft-farrel-ccamp-ero-survey-00.txt May 2006 Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 go to Draft Standard. To move things forward, I would like to do an informal and *confidential* survey of current implementations. Please respond to each question below with, Yes / No / NA. NA would largely apply where the implementation is found on a NE where the technology makes the ERO option inappropriate. Send your responses to me and not to the mailing lists (unless you fancy the publicity). Thanks, Adrian 2.2. Survey Questions The following two survey questions were asked. 1. EROs built for use on Path messages For each hop in the path, which of the following options does your implementation utilize? This question applies to EROs that your implementations construct, NOT to EROs that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects A. Farrel [Page 3] draft-farrel-ccamp-ero-survey-00.txt May 2006 k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 2. EROs received from the previous hop on Path messages Which *top* subobjects in the ERO does your implementation support receiving? This question applies to ERO subobjects that your implementations must handle, NOT to ERO subobjects that you forward. a. IP Address with non-full prefix length specifying a group of nodes b. AS number c. TE Router ID d. Incoming TE link ID e. Outgoing TE link ID f. Outgoing TE link ID followed by one or two Label subobjects A. Farrel [Page 4] draft-farrel-ccamp-ero-survey-00.txt May 2006 g. Outgoing TE link ID followed by Component Interface ID subobject h. Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects i. TE Router ID and Outgoing TE link ID j. TE Router ID and Outgoing TE link ID followed by one or two Label subobjects k. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject l. TE Router ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects m. Incoming TE link ID and Outgoing TE link ID n. Incoming TE link ID and Outgoing TE link ID followed by one or two Label subobjects o. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject p. Incoming TE link ID and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by one or two Label subobjects s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed by Component Interface ID subobject and one or two Label subobjects 3. Respondents Responses were received from 9 vendors, one software house, and one research lab. Two vendors made responses for their current products and for the products that they currently have under development. Thus there were a total of 13 responses. Responses to questions from all respondents were clear yes or no answers. The option of N/A (not applicable) was never used. A. Farrel [Page 5] draft-farrel-ccamp-ero-survey-00.txt May 2006 4. Results This section breaks the results down by respondent category and then shows an overall table of all results. 4.1. Vendors' Current Products | Responding vendors | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |Totals| ---+---+---+---+---+---+---+---+---+---+------+ 1a | N | N | N | N | Y | Y | N | N | N | 2/9 | 1b | N | N | N | N | Y | N | N | N | N | 1/9 | 1c | Y | N | Y | N | Y | Y | N | Y | Y | 6/9 | 1d | Y | N | N | N | Y | Y | N | N | Y | 4/9 | 1e | Y | Y | Y | N | Y | Y | N | N | Y | 6/9 | 1f | Y | N | Y | N | Y | Y | N | N | N | 4/9 | 1g | Y | Y | N | N | Y | N | N | N | N | 3/9 | 1h | Y | Y | N | N | Y | N | N | N | N | 3/9 | 1i | Y | N | Y | Y | Y | Y | N | N | Y | 6/9 | 1j | Y | N | Y | N | Y | Y | N | N | Y | 5/9 | 1k | Y | N | N | Y | Y | N | N | N | Y | 4/9 | 1l | Y | N | N | Y | Y | N | N | N | Y | 4/9 | 1m | N | N | N | N | Y | N | Y | N | N | 2/9 | 1n | N | N | N | N | Y | N | Y | N | N | 2/9 | 1o | N | N | N | N | Y | N | Y | N | N | 2/9 | 1p | N | N | N | N | Y | N | Y | N | N | 2/9 | 1q | N | N | N | N | Y | N | N | N | N | 1/9 | 1r | N | N | N | N | Y | N | N | N | N | 1/9 | 1s | N | N | N | N | Y | N | N | N | N | 1/9 | 1t | N | N | N | N | Y | N | N | N | N | 1/9 | ---+---+---+---+---+---+---+---+---+---+------+ 2a | N | N | N | N | Y | N | N | N | N | 1/9 | 2b | Y | N | N | N | Y | Y | N | N | N | 3/9 | 2c | Y | N | Y | N | Y | Y | Y | Y | Y | 6/9 | 2d | Y | N | N | N | Y | Y | Y | N | Y | 5/9 | 2e | Y | Y | Y | N | Y | Y | N | N | Y | 6/9 | 2f | Y | N | Y | N | Y | Y | N | N | N | 4/9 | 2g | Y | Y | N | N | Y | N | N | N | N | 3/9 | 2h | Y | Y | N | N | Y | N | N | N | N | 3/9 | 2i | Y | N | Y | Y | Y | Y | Y | N | Y | 7/9 | 2j | Y | N | Y | Y | Y | Y | Y | N | Y | 7/9 | 2k | Y | N | N | Y | Y | N | Y | N | Y | 5/9 | 2l | Y | N | N | Y | Y | N | Y | N | Y | 5/9 | 2m | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2n | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2o | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2p | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2q | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2r | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2s | Y | N | N | N | Y | N | Y | N | N | 3/9 | 2t | Y | N | N | N | Y | N | Y | N | N | 3/9 | A. Farrel [Page 6] draft-farrel-ccamp-ero-survey-00.txt May 2006 4.2. Vendors' Development Products This section shows the responses for the two vendors who supplied details of their products under development. The 'modified totals' column shows the impact on the totals in the table in section 4.1 of replacing the vendors' entries with those in the table in this section. |vendors| ||Modified| | 1 | 2 |Totals|| Totals | ---+---+---+------++--------+ 1a | N | N | 0 || 2/9 | 1b | N | Y | 1 || 2/9 | 1c | Y | Y | 2 || 6/9 | 1d | N | N | 0 || 4/9 | 1e | Y | N | 1 || 6/9 | 1f | Y | N | 1 || 4/9 | 1g | N | N | 0 || 3/9 | 1h | N | N | 0 || 3/9 | 1i | Y | Y | 2 || 7/9 | 1j | Y | N | 1 || 5/9 | 1k | N | N | 0 || 4/9 | 1l | N | N | 0 || 4/9 | 1m | N | N | 0 || 2/9 | 1n | N | N | 0 || 2/9 | 1o | N | N | 0 || 2/9 | 1p | N | N | 0 || 2/9 | 1q | N | N | 0 || 1/9 | 1r | N | N | 0 || 1/9 | 1s | N | N | 0 || 1/9 | 1t | N | N | 0 || 1/9 | ---+---+---+------++--------+ 2a | N | N | 0 || 1/9 | 2b | N | Y | 1 || 4/9 | 2c | Y | Y | 2 || 6/9 | 2d | Y | N | 1 || 6/9 | 2e | Y | N | 1 || 6/9 | 2f | Y | N | 1 || 4/9 | 2g | N | N | 0 || 3/9 | 2h | N | N | 0 || 3/9 | 2i | Y | Y | 2 || 8/9 | 2j | Y | N | 1 || 7/9 | 2k | N | N | 0 || 5/9 | 2l | N | N | 0 || 5/9 | 2m | Y | N | 1 || 4/9 | 2n | Y | N | 1 || 4/9 | 2o | N | N | 0 || 3/9 | 2p | N | N | 0 || 3/9 | 2q | Y | N | 1 || 4/9 | 2r | Y | N | 1 || 4/9 | 2s | N | N | 0 || 3/9 | 2t | N | N | 0 || 3/9 | A. Farrel [Page 7] draft-farrel-ccamp-ero-survey-00.txt May 2006 4.3. Software and Research Implementations Separating these results into a separate section is in no way intended to imply that these implementations are any more or less valid. |software|research|Total| ---+--------+--------+-----+ 1a | Y | N | 1 | 1b | Y | N | 1 | 1c | Y | Y | 2 | 1d | Y | N | 1 | 1e | Y | Y | 2 | 1f | Y | N | 1 | 1g | Y | N | 1 | 1h | Y | N | 1 | 1i | Y | Y | 2 | 1j | Y | Y | 2 | 1k | Y | N | 1 | 1l | Y | N | 1 | 1m | Y | N | 1 | 1n | Y | N | 1 | 1o | Y | N | 1 | 1p | Y | N | 1 | 1q | Y | N | 1 | 1r | Y | N | 1 | 1s | Y | N | 1 | 1t | Y | N | 1 | ---+--------+--------+-----+ 2a | Y | N | 1 | 2b | Y | N | 1 | 2c | Y | Y | 2 | 2d | Y | N | 1 | 2e | Y | Y | 2 | 2f | Y | N | 1 | 2g | Y | N | 1 | 2h | Y | N | 1 | 2i | Y | Y | 2 | 2j | Y | Y | 2 | 2k | Y | N | 1 | 2l | Y | N | 1 | 2m | Y | N | 1 | 2n | Y | N | 1 | 2o | Y | N | 1 | 2p | Y | N | 1 | 2q | Y | N | 1 | 2r | Y | N | 1 | 2s | Y | N | 1 | 2t | Y | N | 1 | A. Farrel [Page 8] draft-farrel-ccamp-ero-survey-00.txt May 2006 4.4. Grand Totals This section presents totals for the vendor implementations, the software implementation, and the research implementation. Where a vendor submitted a response for a current and future product, only the response for the future product has been counted. | Grand | | Totals | ---+---------+ 1a | 3/11 | 1b | 3/11 | 1c | 8/11 | 1d | 5/11 | 1e | 8/11 | 1f | 5/11 | 1g | 4/11 | 1h | 4/11 | 1i | 9/11 | 1j | 7/11 | 1k | 5/11 | 1l | 5/11 | 1m | 3/11 | 1n | 3/11 | 1o | 3/11 | 1p | 3/11 | 1q | 2/11 | 1r | 2/11 | 1s | 2/11 | 1t | 2/11 | ---+---------+ 2a | 2/11 | 2b | 5/11 | 2c | 8/11 | 2d | 7/11 | 2e | 8/11 | 2f | 5/11 | 2g | 4/11 | 2h | 4/11 | 2i | 10/11 | 2j | 9/11 | 2k | 6/11 | 2l | 6/11 | 2m | 5/11 | 2n | 5/11 | 2o | 4/11 | 2p | 4/11 | 2q | 5/11 | 2r | 5/11 | 2s | 4/11 | 2t | 4/11 | A. Farrel [Page 9] draft-farrel-ccamp-ero-survey-00.txt May 2006 5. Conclusions The results shown in this survey are not wholly conclusive. They suggest that all options may be generated by some implementations and that some options are commonly available. At the same time, the results show that the support for received options is patchy with few implementations supporting a wide choice of received ERO options and only two options (i and j - TE Router ID with Outgoing TE link ID, and TE Router ID with Outgoing TE link ID followed by one or two Label subobjects) being widely supported. Results for options containing Component Link IDs (g, h, k, l, o, p, s, and t) should be treated with some caution as support for these options requires support for link bundling [RFC4201] which is an implementation option on any device. A device that does not support link bundling would not ever need to process these ERO options. (Properly, many responses should have used 'N/A' and not 'No' for these options.) Interoperability would appear, from these results, to be a tough objective to achieve. In order to successfully complete wide interoperability at least one of the following options must be adopted: - Some implementations stop generating certain ERO options that are not widely supported. - Some implementations start to support certain ERO options that are widely generated. 5.1. Proposed Action The proposed action is as follows: - No change is made to the protocols defined in [RFC3209], [RFC3471], [RFC3473] and [RFC4201] at this time. - [GMPLS-ADDR] continues to specify the availability of all options on EROs that are generated - [GMPLS-ADDR] continues to recommend that implementations support the receipt of all ERO options applicable to their hardware capabilities - Implementations generate only those ERO options that they really require - A future survey is carried out when there is a plan to advance the protocol RFCs to Draft Standard. This future survey should aim to determine deployment experience as opposed to implementation experience. 6. IANA Considerations This informational document makes no requests to IANA for action. A. Farrel [Page 10] draft-farrel-ccamp-ero-survey-00.txt May 2006 7. Security Considerations This survey defines no protocols or procedures and so includes no security-related protocol changes. Reductions in the supported ERO options will not have any negative security impact, and removing options might possibly improve the security of GMPLS signaling if there exist any undiscovered issues with the retired options. 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 a single individual who, although (or perhaps because) he is a working group chair, cannot necessarily be trusted. Thus, the IETF process is open to an attack by this individual. 8. References 8.1 Normative References [GMPLS-ADDR] Shiomoto, K., Papneja, R., and Rabbat, R., "Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks", draft-ietf-ccamp-gmpls-addressing, work in progress. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4201] Kompella, K., Rekhter, Y. and Berger, L. "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. A. Farrel [Page 11] draft-farrel-ccamp-ero-survey-00.txt May 2006 9. Author's Address Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk 10. Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 11. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A. Farrel [Page 12]