Experience with the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-experience-00

Network Working Group                                      Loa Andersson
Internet Draft                                                 Ina Minei
Expiration Date: February 2006                                Bob Thomas
Category: Informational                                          Editors

                                                             August 2005

                    Experience with the LDP protocol

                 draft-ietf-mpls-ldp-experience-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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The purpose of this memo is to document how some of the requirements
   specified in RFC 1264 for advancing protocols developed by working
   groups within the IETF Routing Area to Draft Standard have been
   satisfied by LDP (Label Distribution Protocol).  Specifically, this
   report documents operational experience with LDP, requirement 5 of
   section 5.0 in RFC 1264.

Andersson, et al.                                               [Page 1]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

Table of Contents

 1          Introduction  ..........................................   3
 2          Operational experience  ................................   3
 2.1        Environment and duration  ..............................   3
 2.2        Applications and motivation  ...........................   4
 2.3        Protocol features  .....................................   4
 2.4        Security concerns  .....................................   4
 2.5        Implementations and inter-operability  .................   5
 2.6        Operational experience  ................................   5
 3          Intellectual Property Statement  .......................   6
 4          Acknowledgments  .......................................   6
 5          References  ............................................   7
 5.1        Normative References  ..................................   7
 5.2        Informative References  ................................   7
 6          Editors' Addresses  ....................................   7
            Full Copyright Statement  ..............................   8

Andersson, et al.                                               [Page 2]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

1. Introduction

   The purpose of this memo is to document how some of the requirements
   specified in RFC 1264 for advancing protocols developed by working
   groups within the IETF Routing Area to Draft Standard have been sat-
   isfied by LDP. Specifically, this report documents operational expe-
   rience with LDP, requirement 5 of section 5.0 in RFC 1264.

   LDP was originally published as RFC 3036 in January 2001.  It was
   produced by the MPLS Working Group of the IETF and was jointly
   authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette
   and Bob Thomas.

2. Operational experience

   This section discusses operational experience with the protocol. The
   information is based on a survey sent to the MPLS Working Group in
   October 2004. The questionnaire can be found in the MPLS Working
   Group mail archives for October 2004.

   11 responses were received, all but two requesting confidentiality.
   The survey results are summarized to maintain confidentiality.  The
   networks surveyed span different geographic locations: US, Europe and
   Asia. Both academic and commercial networks responded to the survey.

2.1. Environment and duration

   The size of the deployments ranges from less than 20 Label Switching
   Routers (LSRs) to over 1000 LSRs.  Eight out of the 11 deployments
   use LDP in the edge and the core, two on the edge only and one in the
   core only.

   Sessions exist to peers discovered via both the basic and the
   extended discovery mechanisms. In half the cases, more than one adja-
   cency (and as many as four adjacencies) are maintained per session.
   The average number of LDP sessions on an LSR ranges from under 10 to
   just over 80. The responses are spread as follows: under 10: 4
   responses, 20-50: 4 responses, over 80: 1 response.

   In the surveyed networks, the time LDP has been deployed ranges from
   under one year to over 4 years. The responses are spread out as fol-
   lows: under 1 year - 3 responses, 2 years - 2 responses, 3 years -3
   responses and over 4 years - 3 responses.

Andersson, et al.                                               [Page 3]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

2.2. Applications and motivation

   Nine out of the 11 responses list L3VPNs as the application driving
   the LDP deployment in the network.

   The list of applications is as follows. L3VPNs: 9, pseudo-wires: 4
   current (and one planned deployment), L2VPNs: 4, forwarding based on
   labels: 2, BGP-free core: 1

   There are two major options for label distribution protocols, LDP and
   RSVP-TE. One of the key differences between the two is that RSVP-TE
   has support for Traffic Engineering (TE), while LDP does not.  The
   reasons cited for picking LDP as the label distribution protocol are:
     o The deployment does not require traffic engineering - 6
     o Inter-operability concerns if a different protocol is used - 5
     o Equipment vendor only supports LDP - 5
     o Ease of configuration - 4
     o Ease of management - 3
     o Scalability concerns with other protocols - 3
     o Required for a service offering of the service provider - 1

2.3. Protocol features

   All deployments surveyed use the downstream unsolicited label distri-
   bution mode. All but one deployment use liberal label retention (one
   uses conservative).

   LSP setup is established with both independent and ordered control.
   Five of the deployments use both control modes in the same network.

   The number of LDP FECs advertised and LDP routes installed falls in
   one of two categories: 1) roughly the same as the number of LSRs in
   the network and 2) roughly the same as the number of IGP routes in
   the network. Of the 8 responses were received. 6 were in the first
   category and 2 in the second.

2.4. Security concerns

   A  security concern was raised by one of the operators with respect
   to the lack of a mechanism for securing LDP Hellos.

Andersson, et al.                                               [Page 4]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

2.5. Implementations and inter-operability

   Eight out of the 11 responses state that more than one implementation
   (and as many as four different ones) are deployed in the same net-
   work.

   The consensus is that although implementations differ, no inter-oper-
   ability issues exist. The challenges listed by providers running mul-
   tiple implementations are:
     o Different flexibility in picking which FECs to advertise labels
       for.
     o Different flexibility in setting transport and LDP router-id
       addresses.
     o Different default utilization of LDP labels for traffic resolu-
       tion. Some vendors use LDP for both VPN and IPv4 traffic forward-
       ing, while other vendors allow only VPN traffic to resolve via
       LDP. The challenge is to restrict the utilization of LDP labels
       to VPN traffic in a mixed-vendor environment.
     o Understanding the differences in the implementations.

2.6. Operational experience

   In general, operators reported stable implementations and steady
   improvement in resiliency to failure and convergence times over the
   years. Some operators reported that no issues were found with the
   protocol since deploying.

   The operational issues reported fall in three categories:
      1. Configuration issues. Both the session and adjacency endpoints
         must be allowed by the firewall filters. Misconfiguration of
         the filters causes sessions to drop (if already established) or
         not to establish.
      2. Vendor bugs. These include traffic blackholing, unnecessary
         label withdrawals and changes, session resets and problems
         migrating from older versions of the technology. Most reports
         stated that the problems reported occurred in early versions of
         the implementations.
      3. Protocol issues.
     - The synchronization required between LDP and the IGP was listed
       as the main protocol issue. Two issues were reported. 1) Slow
       convergence, due to the fact that LDP convergence time is tied to
       the IGP convergence time. 2) Traffic blackholing on a link-up
       event. When an interface comes up, the LDP session may come up
       slower than the IGP session. This results in dropping MPLS traf-
       fic for a link-up event (not a failure but a restoration). This
       issue is described in more detail in [LDP-SYNC].

Andersson, et al.                                               [Page 5]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

     - Silent failures. Failure not being propagated to the head end of
       the LSP when setting up LSPs using independent control.

3. Intellectual Property Statement

   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 assur-
   ances 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.

4. Acknowledgments

   The editors would like to thank the operators who participated in the
   survey for their valuable input: Shane Amante, Niclas Comstedt, Bruno
   Decraene, Mourad Kaddache, Kam Lee Yap, Lei Wang and Otto Kreiter.
   Not all who participated are listed here, due to confidentiality
   requests. Those listed have given their consent.

   Also, a big thank you to Scott Bradner who acted as an independent
   third party ensuring anonymity of the responses.

   The editors would like to thank Rajiv Papneja, Halit Ustundag and Loa
   Andersson for their input to the survey questionnaire.

Andersson, et al.                                               [Page 6]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

5. References

5.1. Normative References

   [RFC1264] Hinden, R., "Internet Engineering Task Force Internet Rout-
   ing Protocol Standardization Criteria", RFC 1264, October 1991.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
   3", RFC 2026, October 1996.

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
   B. Thomas, "LDP Specification", RFC 3036, January 2001.

   [RFC3815] Cucchiara,J., Sjostrand, H. and Luciani, J., "Definitions
   of Managed Objects for the Multiprotocol Label Switching (MPLS),
   Label Distribution Protocol (LDP)", RFC 3815, June 2004.

5.2. Informative References

   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
   April 1992.

   [LDP-SYNC] Jork, M., Atlas, A. and Fang, L., "LDP IGP Synchroniza-
   tion", draft-jork-ldp-igp-sync-00

6. Editors' Addresses

   Loa Andersson
   Acreo AB
   Isafjordsgatan 22
   Kista, Sweden
   email: loa.andersson@acreo.se
          loa@pi.se

   Ina Minei
   Juniper Networks
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089
   e-mail: ina@juniper.net

   Bob Thomas
   Cisco Systems, Inc.
   1414 Massachusetts Ave
   Boxborough, MA 01719

Andersson, et al.                                               [Page 7]
Internet Draft    draft-ietf-mpls-ldp-experience-00.txt      August 2005

   email: rhthomas@cisco.com

Full Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

   Additional copyright notices are not permitted in IETF Documents
   except in the case where such document is the product of a joint
   development effort between the IETF and another standards development
   organization or the document is a republication of the work of
   another standards organization.  Such exceptions must be approved on
   an individual basis by the IAB.

   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 INFOR-
   MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Andersson, et al.                                               [Page 8]