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

                <draft-farrel-ccamp-ero-survey-00.txt>

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]