Network Working GroupLoa Andersson Internet Draft Ina Minei Expiration Date: February 2006 Bob ThomasL. Andersson, Ed. Request for Comments: 5037 Acreo AB Category: InformationalEditors August 2005I. Minei, Ed. Juniper Networks B. Thomas, Ed. Cisco Systems, Inc. September 2007 Experience with theLDP protocol draft-ietf-mpls-ldp-experience-00.txtLabel Distribution Protocol (LDP) Status ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.this memo is unlimited. 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. Table of Contents11. Introduction.......................................... 3 2....................................................2 2. Operationalexperience ................................ 3 2.1Experience ..........................................2 2.1. Environment andduration .............................. 3 2.2Duration ...................................2 2.2. Applications andmotivation ........................... 4 2.3Motivation ................................3 2.3. Protocolfeatures ..................................... 4 2.4Features ..........................................3 2.4. Securityconcerns ..................................... 4 2.5Concerns ..........................................4 2.5. Implementations andinter-operability ................. 5 2.6Inter-Operability ......................4 2.6. Operationalexperience ................................ 5 3 Intellectual Property Statement ....................... 6 4Experience .....................................4 3. Security Considerations .........................................5 4. Acknowledgments....................................... 6 5.................................................5 5. References............................................ 7 5.1......................................................5 5.1. Normative References.................................. 7 5.2.......................................5 5.2. Informative References................................ 7 6 Editors' Addresses .................................... 7 Full Copyright Statement .............................. 8.....................................6 1. Introduction The purpose of this memo is to document how some of the requirements specified inRFC 1264[RFC1264] for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have beensat- isfiedsatisfied by LDP. Specifically, this report documents operationalexpe- rienceexperience with LDP, requirement 5 of section 5.0 in RFC 1264. LDP was originally published asRFC 3036[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, AndreFredetteFredette, and Bob Thomas. 2. OperationalexperienceExperience 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 buttwo2 requesting confidentiality. The survey results are summarized to maintain confidentiality. The networks surveyed span different geographic locations: US,EuropeEurope, and Asia. Both academic and commercial networks responded to the survey. 2.1. Environment anddurationDuration 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 edgeonlyonly, 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 oneadja- cencyadjacency (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 underone1 year to over 4 years. The responses are spread out asfol- lows:follows: under 1year -year: 3 responses, 2years -years: 2 responses, 3years -3 responsesyears: 3 responses, and over 4years -years: 3 responses. 2.2. Applications andmotivationMotivation Nineoutof the 11 responses listL3VPNsLayer 3 Virtual Private Networks (L3VPNs) as the application driving the LDP deployment in the network. The list of applications is asfollows.follows: L3VPNs: 9,pseudo-wires:pseudowires: 4 current (and one planned deployment), L2VPNs: 4, forwarding based on labels: 2, and BGP-free core:11. There are two major options for label distribution protocols, LDP andRSVP-TE.Resource Reservation Protocol-Traffic Engineering (RSVP-TE). One of the key differences between the two is that RSVP-TE has support forTraffic Engineering (TE),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 - 1 2.3. ProtocolfeaturesFeatures All deployments surveyed use thedownstream unsolicited label distri- butionDownstream Unsolicited Label Distribution mode. All but one deployment useliberal labelLiberal Label retention (one uses conservative). LSP setup is established with both independent andordered control.Ordered Control. Five of the deployments use both control modes in the same network. The number of LDPFECsForwarding 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 werereceived.received, 6 were in the first category and 2 in the second. 2.4. SecurityconcernsConcerns 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 andinter-operabilityInter-Operability Eightoutof the 11 responses state that more than one implementation (and as many as four different ones) are deployed in the samenet- work.network. The consensus is that although implementations differ, nointer-oper- abilityinter- operability issues exist. The challenges listed by providers runningmul- tiplemultiple implementations are: o Different flexibility in picking for which FECs to advertiselabels for.labels. o Different flexibility in setting transport and LDP router-id addresses. o Different default utilization of LDP labels for trafficresolu- tion.resolution. Some vendors use LDP for both VPN and IPv4 trafficforward- ing,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. OperationalexperienceExperience 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, sessionresetsresets, 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 werereported.reported: 1)Slowslow convergence, due to the fact that LDP convergence time is tied to the IGP convergencetime.time, and 2)Traffictraffic 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 MPLStraf- fictraffic for alink-uplink- 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.Intellectual Property Statement The IETF takes no position regarding the validity or scopeSecurity Considerations This document is a survey of experiences from deployment of LDP implementations; it does not specify anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use ofprotocol behavior. Thus, security issues introduced by thetechnology described in thisdocumentor the extent to which any license under such rights might or mightare notbe 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.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, LeiWangWang, 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 ScottBradnerBradner, who acted as an independent third party ensuring anonymity of the responses. The editors would like to thank Rajiv Papneja, HalitUstundagUstundag, and Loa Andersson for their input to the survey questionnaire. 5. References 5.1. Normative References [RFC1264] Hinden, R., "Internet Engineering Task Force InternetRout- ingRouting Protocol Standardization Criteria", RFC 1264, October 1991. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette,A.A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3815]Cucchiara,J.,Cucchiara, J., Sjostrand,H.H., and J. 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-DigestAlgorithm,"Algorithm", RFC 1321, April 1992. [LDP-SYNC] Jork, M., Atlas,A.A., and L. Fang,L.,"LDP IGPSynchroniza- tion", draft-jork-ldp-igp-sync-00 6.Synchronization", Work in Progress, July 2007. Editors' Addresses Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Swedenemail:EMail: loa.andersson@acreo.se loa@pi.se Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089e-mail:EMail: ina@juniper.net Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719email:EMail: rhthomas@cisco.com Full Copyright Statement Copyright (C) TheInternet Society (2005).IETF Trust (2007). 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 INTERNETSOCIETYSOCIETY, 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 THEINFOR- MATIONINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement Funding forIntellectual 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 RFCEditor function is currently provideddocuments 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 theInternet Society.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.