idnits 2.17.1 draft-ietf-mpls-ldp-experience-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 219. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2005) is 6826 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1264' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC3815' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1264 (Obsoleted by RFC 4794) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-03) exists of draft-jork-ldp-igp-sync-00 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Loa Andersson 3 Internet Draft Ina Minei 4 Expiration Date: February 2006 Bob Thomas 5 Category: Informational Editors 7 August 2005 9 Experience with the LDP protocol 11 draft-ietf-mpls-ldp-experience-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The purpose of this memo is to document how some of the requirements 38 specified in RFC 1264 for advancing protocols developed by working 39 groups within the IETF Routing Area to Draft Standard have been 40 satisfied by LDP (Label Distribution Protocol). Specifically, this 41 report documents operational experience with LDP, requirement 5 of 42 section 5.0 in RFC 1264. 44 Table of Contents 46 1 Introduction .......................................... 3 47 2 Operational experience ................................ 3 48 2.1 Environment and duration .............................. 3 49 2.2 Applications and motivation ........................... 4 50 2.3 Protocol features ..................................... 4 51 2.4 Security concerns ..................................... 4 52 2.5 Implementations and inter-operability ................. 5 53 2.6 Operational experience ................................ 5 54 3 Intellectual Property Statement ....................... 6 55 4 Acknowledgments ....................................... 6 56 5 References ............................................ 7 57 5.1 Normative References .................................. 7 58 5.2 Informative References ................................ 7 59 6 Editors' Addresses .................................... 7 60 Full Copyright Statement .............................. 8 62 1. Introduction 64 The purpose of this memo is to document how some of the requirements 65 specified in RFC 1264 for advancing protocols developed by working 66 groups within the IETF Routing Area to Draft Standard have been sat- 67 isfied by LDP. Specifically, this report documents operational expe- 68 rience with LDP, requirement 5 of section 5.0 in RFC 1264. 70 LDP was originally published as RFC 3036 in January 2001. It was 71 produced by the MPLS Working Group of the IETF and was jointly 72 authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette 73 and Bob Thomas. 75 2. Operational experience 77 This section discusses operational experience with the protocol. The 78 information is based on a survey sent to the MPLS Working Group in 79 October 2004. The questionnaire can be found in the MPLS Working 80 Group mail archives for October 2004. 82 11 responses were received, all but two requesting confidentiality. 83 The survey results are summarized to maintain confidentiality. The 84 networks surveyed span different geographic locations: US, Europe and 85 Asia. Both academic and commercial networks responded to the survey. 87 2.1. Environment and duration 89 The size of the deployments ranges from less than 20 Label Switching 90 Routers (LSRs) to over 1000 LSRs. Eight out of the 11 deployments 91 use LDP in the edge and the core, two on the edge only and one in the 92 core only. 94 Sessions exist to peers discovered via both the basic and the 95 extended discovery mechanisms. In half the cases, more than one adja- 96 cency (and as many as four adjacencies) are maintained per session. 97 The average number of LDP sessions on an LSR ranges from under 10 to 98 just over 80. The responses are spread as follows: under 10: 4 99 responses, 20-50: 4 responses, over 80: 1 response. 101 In the surveyed networks, the time LDP has been deployed ranges from 102 under one year to over 4 years. The responses are spread out as fol- 103 lows: under 1 year - 3 responses, 2 years - 2 responses, 3 years -3 104 responses and over 4 years - 3 responses. 106 2.2. Applications and motivation 108 Nine out of the 11 responses list L3VPNs as the application driving 109 the LDP deployment in the network. 111 The list of applications is as follows. L3VPNs: 9, pseudo-wires: 4 112 current (and one planned deployment), L2VPNs: 4, forwarding based on 113 labels: 2, BGP-free core: 1 115 There are two major options for label distribution protocols, LDP and 116 RSVP-TE. One of the key differences between the two is that RSVP-TE 117 has support for Traffic Engineering (TE), while LDP does not. The 118 reasons cited for picking LDP as the label distribution protocol are: 119 o The deployment does not require traffic engineering - 6 120 o Inter-operability concerns if a different protocol is used - 5 121 o Equipment vendor only supports LDP - 5 122 o Ease of configuration - 4 123 o Ease of management - 3 124 o Scalability concerns with other protocols - 3 125 o Required for a service offering of the service provider - 1 127 2.3. Protocol features 129 All deployments surveyed use the downstream unsolicited label distri- 130 bution mode. All but one deployment use liberal label retention (one 131 uses conservative). 133 LSP setup is established with both independent and ordered control. 134 Five of the deployments use both control modes in the same network. 136 The number of LDP FECs advertised and LDP routes installed falls in 137 one of two categories: 1) roughly the same as the number of LSRs in 138 the network and 2) roughly the same as the number of IGP routes in 139 the network. Of the 8 responses were received. 6 were in the first 140 category and 2 in the second. 142 2.4. Security concerns 144 A security concern was raised by one of the operators with respect 145 to the lack of a mechanism for securing LDP Hellos. 147 2.5. Implementations and inter-operability 149 Eight out of the 11 responses state that more than one implementation 150 (and as many as four different ones) are deployed in the same net- 151 work. 153 The consensus is that although implementations differ, no inter-oper- 154 ability issues exist. The challenges listed by providers running mul- 155 tiple implementations are: 156 o Different flexibility in picking which FECs to advertise labels 157 for. 158 o Different flexibility in setting transport and LDP router-id 159 addresses. 160 o Different default utilization of LDP labels for traffic resolu- 161 tion. Some vendors use LDP for both VPN and IPv4 traffic forward- 162 ing, while other vendors allow only VPN traffic to resolve via 163 LDP. The challenge is to restrict the utilization of LDP labels 164 to VPN traffic in a mixed-vendor environment. 165 o Understanding the differences in the implementations. 167 2.6. Operational experience 169 In general, operators reported stable implementations and steady 170 improvement in resiliency to failure and convergence times over the 171 years. Some operators reported that no issues were found with the 172 protocol since deploying. 174 The operational issues reported fall in three categories: 175 1. Configuration issues. Both the session and adjacency endpoints 176 must be allowed by the firewall filters. Misconfiguration of 177 the filters causes sessions to drop (if already established) or 178 not to establish. 179 2. Vendor bugs. These include traffic blackholing, unnecessary 180 label withdrawals and changes, session resets and problems 181 migrating from older versions of the technology. Most reports 182 stated that the problems reported occurred in early versions of 183 the implementations. 184 3. Protocol issues. 185 - The synchronization required between LDP and the IGP was listed 186 as the main protocol issue. Two issues were reported. 1) Slow 187 convergence, due to the fact that LDP convergence time is tied to 188 the IGP convergence time. 2) Traffic blackholing on a link-up 189 event. When an interface comes up, the LDP session may come up 190 slower than the IGP session. This results in dropping MPLS traf- 191 fic for a link-up event (not a failure but a restoration). This 192 issue is described in more detail in [LDP-SYNC]. 194 - Silent failures. Failure not being propagated to the head end of 195 the LSP when setting up LSPs using independent control. 197 3. Intellectual Property Statement 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in 202 this document or the extent to which any license under such rights 203 might or might not be available; nor does it represent that it has 204 made any independent effort to identify any such rights. Information 205 on the procedures with respect to rights in RFC documents can be 206 found in BCP 78 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any assur- 209 ances of licenses to be made available, or the result of an attempt 210 made to obtain a general license or permission for the use of such 211 proprietary rights by implementers or users of this specification can 212 be obtained from the IETF on-line IPR repository at 213 http://www.ietf.org/ipr. 215 The IETF invites any interested party to bring to its attention any 216 copyrights, patents or patent applications, or other proprietary 217 rights that may cover technology that may be required to implement 218 this standard. Please address the information to the IETF at ietf- 219 ipr@ietf.org. 221 4. Acknowledgments 223 The editors would like to thank the operators who participated in the 224 survey for their valuable input: Shane Amante, Niclas Comstedt, Bruno 225 Decraene, Mourad Kaddache, Kam Lee Yap, Lei Wang and Otto Kreiter. 226 Not all who participated are listed here, due to confidentiality 227 requests. Those listed have given their consent. 229 Also, a big thank you to Scott Bradner who acted as an independent 230 third party ensuring anonymity of the responses. 232 The editors would like to thank Rajiv Papneja, Halit Ustundag and Loa 233 Andersson for their input to the survey questionnaire. 235 5. References 237 5.1. Normative References 239 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet Rout- 240 ing Protocol Standardization Criteria", RFC 1264, October 1991. 242 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 243 3", RFC 2026, October 1996. 245 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 246 B. Thomas, "LDP Specification", RFC 3036, January 2001. 248 [RFC3815] Cucchiara,J., Sjostrand, H. and Luciani, J., "Definitions 249 of Managed Objects for the Multiprotocol Label Switching (MPLS), 250 Label Distribution Protocol (LDP)", RFC 3815, June 2004. 252 5.2. Informative References 254 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, 255 April 1992. 257 [LDP-SYNC] Jork, M., Atlas, A. and Fang, L., "LDP IGP Synchroniza- 258 tion", draft-jork-ldp-igp-sync-00 260 6. Editors' Addresses 262 Loa Andersson 263 Acreo AB 264 Isafjordsgatan 22 265 Kista, Sweden 266 email: loa.andersson@acreo.se 267 loa@pi.se 269 Ina Minei 270 Juniper Networks 271 1194 N.Mathilda Ave 272 Sunnyvale, CA 94089 273 e-mail: ina@juniper.net 275 Bob Thomas 276 Cisco Systems, Inc. 277 1414 Massachusetts Ave 278 Boxborough, MA 01719 279 email: rhthomas@cisco.com 281 Full Copyright Statement 283 Copyright (C) The Internet Society (2005). This document is subject 284 to the rights, licenses and restrictions contained in BCP 78, and 285 except as set forth therein, the authors retain all their rights. 287 Additional copyright notices are not permitted in IETF Documents 288 except in the case where such document is the product of a joint 289 development effort between the IETF and another standards development 290 organization or the document is a republication of the work of 291 another standards organization. Such exceptions must be approved on 292 an individual basis by the IAB. 294 This document and the information contained herein are provided on an 295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 297 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 298 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 299 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 300 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 Acknowledgement 304 Funding for the RFC Editor function is currently provided by the 305 Internet Society.