idnits 2.17.1 draft-ietf-mpls-ldp-igp-sync-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 348. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 28, 2008) is 5779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jork 3 Internet Draft NextPoint Networks 4 Category: Informational Alia Atlas 5 Expires: December 2008 British Telecom 6 L. Fang 7 Cisco Systems, Inc. 9 June 28, 2008 11 LDP IGP Synchronization 12 draft-ietf-mpls-ldp-igp-sync-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 In certain networks there is a dependency on edge-to-edge LSPs setup 43 by LDP, e.g. networks that are used for MPLS VPN applications. For 44 such applications it is not possible to rely on IP forwarding if the 45 MPLS LSP is not operating appropriately. Blackholing of labeled 46 traffic can occur in situations where the IGP is operational on a 47 link but LDP is not operational on that link. While the link could 48 still be used for IP forwarding, it is not useful for MPLS 49 forwarding, for example, MPLS VPN; BGP route free core; or IP 50 address carried in the packet is out of the RFC1918 space. This 51 document describes a mechanism to avoid traffic loss due to this 52 condition without introducing any protocol changes. 54 Table of Contents 56 1. Introduction..................................................2 57 2. Proposed Solution.............................................3 58 3. Applicability.................................................4 59 4. Interaction With TE Tunnels...................................5 60 5. Security Considerations.......................................5 61 6. IANA Considerations...........................................5 62 7. Normative References..........................................6 63 8. Informational References......................................6 64 9. Author's Addresses............................................6 65 10. Acknowledgements............................................8 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in RFC2119 [RFC 72 2119]. 74 1. Introduction 76 LDP [RFC5036] establishes MPLS LSPs along the shortest path to a 77 destination as determined by IP forwarding. In a common network 78 design, LDP is used to provide label switched paths throughout the 79 complete network domain covered by an IGP such as OSPF [RFC2328] or 80 IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as 81 well as LDP adjacencies. 83 A variety of services a network provider may want to deploy over an 84 LDP enabled network depend on the availability of edge to edge 85 label switched paths. In a L2 or L3 VPN scenario for example, a 86 given PE router relies on the availability of a complete MPLS 87 forwarding path to the other PE routers for the VPNs it serves. 88 This means that along the IP shortest path from one PE router to 89 the other, all the links need to have operational LDP sessions and 90 the necessary label binding must have been exchanged over those 91 sessions. If only one link along the IP shortest path is not 92 covered by an LDP session, a blackhole exists and services 93 depending on MPLS forwarding will fail. This might be a transient 94 or a persistent error condition. Some of the reasons for it could 95 be 97 - A configuration error 99 - An implementation bug 101 - The link has just come up and has an IGP adjacency but LDP has 102 either not yet established an adjacency or session or 103 distributed all the label bindings. 105 LDP protocol has currently no way to correct the issue, LDP is not 106 a routing protocol; it can not re-direct traffic to an alternate 107 IGP path. 109 2. Proposed Solution 111 The problem described above exists because LDP is tied to IP 112 forwarding decisions but no coupling between the IGP and LDP 113 operational state on a given link exists. If IGP is operational on 114 a link but LDP is not, a potential network problem exists. So the 115 solution described by this document is to discourage a link from 116 being used for IP forwarding as long as LDP is not fully 117 operational. 119 This has some similarity to the mechanism specified in [RFC3137] 120 which allows an OSPF router to advertise that it should not be used 121 as a transit router. One difference is that [RFC3137] raises the 122 link costs on all (stub) router links, while the mechanism 123 described in here applies on a per-link basis. 125 In detail: when LDP is not "fully operational" (see below) on a 126 given link, the IGP will advertise the link with maximum cost to 127 avoid any transit traffic over it if possible. In the case of 128 OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in 129 [RFC3137]. In the case of ISIS, the max matrix value is 0xFFFFFE 130 per [RFC 3784]. Note that the link is not just simply removed from 131 the topology because LDP depends on the IP reachability to 132 establish its adjacency and session. Also, if there is no other 133 link in the network to reach a particular destination, no 134 additional harm is done by making this link available for IP 135 forwarding at maximum cost. 137 LDP is considered fully operational on a link when an LDP hello 138 adjacency exists on it, a suitable associated LDP session (matching 139 the LDP Identifier of the hello adjacency) is established to the 140 peer at the other end of the link and all label bindings have been 141 exchanged over the session. At the present time, the latter 142 condition can not generally be verified by a router and some 143 estimated may have to be used. A simple implementation strategy is 144 to use a configurable hold down timer to allow LDP session 145 establishment before declaring LDP fully operational. The default 146 timer is not defined in this document due to the concerns of the 147 large variations of the LIB table size and the equipment 148 capabilities. In addition, this is a current work in progress on LDP 149 End-of-LIB as specified in [LDP End-of-LIB], it enables the LDP 150 speaker to signal the completion of its initial advertisement 151 following session establish. When LDP End-of-LIB is implemented, the 152 configurable hold down timer is no longer needed. The neighbor LDP 153 session is considered fully operational when the End-of-LIB 154 notification message is received. 156 This is typically sufficient to deal with the link when it is being 157 brought up. LDP protocol extensions to indicate the complete 158 transmission of all currently available label bindings after a 159 session has come up are conceivable but not addressed in this 160 document. 162 The mechanism described in this document does not entail any 163 protocol changes and is a local implementation issue. 165 The problem space and solution specified in this document have also 166 been discussed in an IEEE Communications Magazine paper [LDP-Fail]. 168 3. Applicability 170 In general, the proposed procedure is applicable in networks where 171 the availability of LDP signaled MPLS LSPs and avoidance of 172 blackholes for MPLS traffic is more important than always choosing 173 an optimal path for IP forwarded traffic. Note however that non- 174 optimal IP forwarding only occurs for a short time after a link 175 comes up or when there is a genuine problem on a link. In the 176 latter case an implementation should issue network management alerts 177 to report the error condition and enable the operator to address it. 179 Example network scenarios that benefit from the mechanism described 180 here are MPLS VPNs and BGP-free core network designs where traffic 181 can only be forwarded through the core when LDP forwarding state is 182 available throughout. 184 The usefulness of this mechanism also depends on the availability 185 of alternate paths with sufficient bandwidth in the network should 186 one link be assigned to the maximum cost due to unavailability of 187 LDP service over it. 189 On broadcast links with more than one IGP/LDP peer, the cost-out 190 procedure can only be applied to the link as a whole and not an 191 individual peer. So a policy decision has to be made whether the 192 unavailability of LDP service to one peer should result in the 193 traffic being diverted away from all the peers on the link. 195 4. Interaction With TE Tunnels 197 In some networks, LDP is used in conjunction with RSVP-TE which sets 198 up traffic-engineered tunnels. The path computation for the TE 199 tunnels is based on the TE link cost which is flooded by the IGP in 200 addition to the regular IP link cost. The mechanism described in 201 this document should only be applied to the IP link cost to prevent 202 any unnecessary TE tunnel reroutes. 204 In order to establish LDP LSPs across a TE tunnel, a targeted LDP 205 session between the tunnel endpoints needs to exist. This presents 206 a problem very similar to the case of a regular LDP session over a 207 link (the case discussed so far): when the TE tunnel is used for IP 208 forwarding, the targeted LDP session needs to be operational to 209 avoid LDP connectivity problems. Again, raising the IP cost of the 210 tunnel while there is no operational LDP session will solve the 211 problem. When there is no IGP adjacency over the tunnel and the 212 tunnel is not advertised as link into the IGP, this becomes a local 213 issue of the tunnel headend router. 215 5. Security Considerations 217 A DoS attack brings down LDP service on a link or prevents it from 218 becoming operational on a link could be one of the possibilities 219 that causes LDP related traffic blackholing. This document does not 220 address how to prevent LDP session failure. The mechanism described 221 here is to prevent the link to be used when LDP is not operational 222 while IGP is. Assigning the IGP cost to maximum on the link where 223 LDP is failed and IGP is not should not introduce new security 224 threats. The operation is internal in the router to allow LDP and 225 IGP to communicate and react. Making many LDP links unavailable, 226 however, is a security threat which can cause traffic being dropped 227 due to limited available network capacity. This may be trigged by 228 operational error or implementation error. They are considered as 229 general Security issues and should follow the current best security 230 practice. 232 6. IANA Considerations 233 This document has no actions for IANA. 235 7. Normative References 237 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., 238 and B. Thomas, "LDP Specification", RFC 5036, October 2007. 240 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 242 8. Informational References 244 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997 247 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 248 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. 250 [RFC 3784] Smit, H., Li, T., Intermediate System to Intermediate 251 System (IS-IS) Extension for Traffic Engineering, June 2004. 253 [ISO.10589.1992]International Organization for 254 Standardization,"Intermediate system to intermediate system intra- 255 domain-routing routine information exchange protocol for use in 256 conjunction with the protocol for providing the connectionless-mode 257 Network Service (ISO 8473)", ISO Standard 10589, 1992. 259 [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and 260 Swallow, G., "LDP Failure Detection and Recovery", IEEE 261 Communications Magazine, Vol.42, No.10, October 2004. 263 [LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-asati-mpls-ldp- 264 end-of-lib-01.txt, November 2007. 266 9. Author's Addresses 268 Markus Jork 269 NextPoint Networks 270 3 Fedral St. 271 Billerica, MA 01821 272 USA 273 Email: mjork@nextpointnetworks.com 275 Alia Atlas 276 British Telecom 277 Email: alia.atlas@bt.com 278 Luyuan Fang 279 Cisco Systems, Inc. 280 300 Beaver Brook Road 281 Boxborough, MA 01719 282 USA 283 Email: lufang@cisco.com 285 Intellectual Property 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed 289 to pertain to the implementation or use of the technology described 290 in this document or the extent to which any license under such 291 rights might or might not be available; nor does it represent that 292 it has made any independent effort to identify any such rights. 293 Information on the procedures with respect to rights in RFC 294 documents can be found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use 299 of such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository 301 at http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at ietf- 307 ipr@ietf.org. 309 Full Copyright Statement 311 Copyright (C) The IETF Trust (2008). 313 This document is subject to the rights, licenses and restrictions 314 contained in BCP 78, and except as set forth therein, the authors 315 retain all their rights. 317 This document and the information contained herein are provided on 318 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 319 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 320 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 321 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 322 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 323 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 324 FOR A PARTICULAR PURPOSE. 326 Intellectual Property 328 The IETF takes no position regarding the validity or scope of any 329 Intellectual Property Rights or other rights that might be claimed 330 to pertain to the implementation or use of the technology described 331 in this document or the extent to which any license under such 332 rights might or might not be available; nor does it represent that 333 it has made any independent effort to identify any such rights. 334 Information on the procedures with respect to rights in RFC 335 documents can be found in BCP 78 and BCP 79. 337 Copies of IPR disclosures made to the IETF Secretariat and any 338 assurances of licenses to be made available, or the result of an 339 attempt made to obtain a general license or permission for the use 340 of such proprietary rights by implementers or users of this 341 specification can be obtained from the IETF on-line IPR repository 342 at http://www.ietf.org/ipr. 344 The IETF invites any interested party to bring to its attention any 345 copyrights, patents or patent applications, or other proprietary 346 rights that may cover technology that may be required to implement 347 this standard. Please address the information to the IETF at ietf- 348 ipr@ietf.org. 350 10. Acknowledgements 352 Funding for the RFC Editor function is provided by the IETF 353 Administrative Support Activity (IASA). 355 The authors would like to thank Loa Andersson for his review and 356 comments, and thank Bruno Decraene for his in depth discussion, 357 comments and helpful suggestions.