Movatterモバイル変換

Network Working Group                                  L. Andersson, Ed.Request for Comments: 5037                                      Acreo ABCategory: Informational                                    I. Minei, Ed.                                                        Juniper Networks                                                          B. Thomas, Ed.                                                     Cisco Systems, Inc.                                                            October 2007Experience with the Label Distribution Protocol (LDP)Status of This Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Abstract   The purpose of this memo is to document how some of the requirements   specified inRFC 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 ofsection 5.0 in RFC 1264.Table of Contents1. Introduction ....................................................22. Operational Experience ..........................................22.1. Environment and Duration ...................................22.2. Applications and Motivation ................................32.3. Protocol Features ..........................................32.4. Security Concerns ..........................................42.5. Implementations and Inter-Operability ......................42.6. Operational Experience .....................................43. Security Considerations .........................................54. Acknowledgments .................................................55. References ......................................................65.1. Normative References .......................................65.2. Informative References .....................................6Andersson, et al.            Informational                      [Page 1]

RFC 5037            Experience with the LDP Protocol        October 20071.  Introduction   The purpose of this memo is to document how some of the requirements   specified in [RFC1264] for advancing protocols developed by working   groups within the IETF Routing Area to Draft Standard have been   satisfied by LDP.  Specifically, this report documents operational   experience with LDP, requirement 5 ofsection 5.0 in RFC 1264.   LDP was originally published as [RFC3036] 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.  It has since been obsoleted by [RFC5036].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 2 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   adjacency (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 out as follows:   under 10: 4 responses, 20-50: 4 responses, and over 80: 1 response.   In the surveyed networks, the time LDP has been deployed ranges from   under 1 year to over 4 years.  The responses are spread out as   follows: under 1 year: 3 responses, 2 years: 2 responses, 3 years: 3   responses, and over 4 years: 3 responses.Andersson, et al.            Informational                      [Page 2]

RFC 5037            Experience with the LDP Protocol        October 20072.2.  Applications and Motivation   Nine of the 11 responses list Layer 3 Virtual Private Networks   (L3VPNs) as the application driving the LDP deployment in the   network.   The list of applications is as follows: L3VPNs: 9, pseudowires: 4   current (and one planned deployment), L2VPNs: 4, forwarding based on   labels: 2, and BGP-free core: 1.   There are two major options for label distribution protocols, LDP and   Resource Reservation Protocol-Traffic Engineering (RSVP-TE).  One of   the key differences between the two is that RSVP-TE has support for   traffic engineering, 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 - 12.3.  Protocol Features   All deployments surveyed use the Downstream Unsolicited Label   Distribution 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 Forwarding Equivalence Classes (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 that   were received, 6 were in the first category and 2 in the second.Andersson, et al.            Informational                      [Page 3]

RFC 5037            Experience with the LDP Protocol        October 20072.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.2.5.  Implementations and Inter-Operability   Eight of the 11 responses state that more than one implementation   (and as many as four different ones) are deployed in the same   network.   The consensus is that although implementations differ, no inter-   operability issues exist.  The challenges listed by providers running   multiple implementations are:      o  Different flexibility in picking for which FECs to advertise         labels.      o  Different flexibility in setting transport and LDP router-id         addresses.      o  Different default utilization of LDP labels for traffic         resolution.  Some vendors use LDP for both VPN and IPv4 traffic         forwarding, 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.Andersson, et al.            Informational                      [Page 4]

RFC 5037            Experience with the LDP Protocol        October 2007      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, and 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 traffic for a link-            up event (not a failure but a restoration).  This issue is            described in more detail in [LDP-SYNC].         -  Silent failures.  Failure not being propagated to the head            end of the LSP when setting up LSPs using independent            control.3.  Security Considerations   This document is a survey of experiences from deployment of LDP   implementations; it does not specify any protocol behavior.  Thus,   security issues introduced by the document are not discussed.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.            Informational                      [Page 5]

RFC 5037            Experience with the LDP Protocol        October 20075.  References5.1.  Normative References   [RFC1264]  Hinden, R., "Internet Engineering Task Force Internet              Routing Protocol Standardization Criteria",RFC 1264,              October 1991.   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and              B. Thomas, "LDP Specification",RFC 3036, January 2001.   [RFC3815]  Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions              of Managed Objects for the Multiprotocol Label Switching              (MPLS), Label Distribution Protocol (LDP)",RFC 3815, June              2004.5.2.  Informative References   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP              Specification",RFC 5036, October 2007.   [LDP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP              Synchronization", Work in Progress, July 2007.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   EMail: ina@juniper.net   Bob Thomas   Cisco Systems, Inc.   1414 Massachusetts Ave   Boxborough, MA 01719   EMail: rhthomas@cisco.comAndersson, et al.            Informational                      [Page 6]

RFC 5037            Experience with the LDP Protocol        October 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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, THE IETF TRUST 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.Intellectual Property   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 inBCP 78 andBCP 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 athttp://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.Andersson, et al.            Informational                      [Page 7]