From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5037.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc5037.txt (limited to 'doc/rfc/rfc5037.txt') 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] + -- cgit v1.2.3