summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5037.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5037.txt')
-rw-r--r--doc/rfc/rfc5037.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5037.txt b/doc/rfc/rfc5037.txt
new file mode 100644
index 0000000..449499e
--- /dev/null
+++ b/doc/rfc/rfc5037.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group L. Andersson, Ed.
+Request for Comments: 5037 Acreo AB
+Category: Informational I. Minei, Ed.
+ Juniper Networks
+ B. Thomas, Ed.
+ Cisco Systems, Inc.
+ October 2007
+
+
+ Experience 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 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 Contents
+
+ 1. Introduction ....................................................2
+ 2. Operational Experience ..........................................2
+ 2.1. Environment and Duration ...................................2
+ 2.2. Applications and Motivation ................................3
+ 2.3. Protocol Features ..........................................3
+ 2.4. Security Concerns ..........................................4
+ 2.5. Implementations and Inter-Operability ......................4
+ 2.6. Operational Experience .....................................4
+ 3. Security Considerations .........................................5
+ 4. Acknowledgments .................................................5
+ 5. References ......................................................6
+ 5.1. Normative References .......................................6
+ 5.2. Informative References .....................................6
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Informational [Page 1]
+
+RFC 5037 Experience with the LDP Protocol October 2007
+
+
+1. 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 of section 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 2007
+
+
+2.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 - 1
+
+2.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 2007
+
+
+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.
+
+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 2007
+
+
+5. References
+
+5.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.com
+
+
+
+
+
+
+
+Andersson, et al. Informational [Page 6]
+
+RFC 5037 Experience with the LDP Protocol October 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The 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.
+
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al. Informational [Page 7]
+