idnits 2.17.1 draft-ietf-mpls-ldp-igp-sync-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 abstract seems to contain references ([RFC1918]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (December 17, 2008) is 5607 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) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: June 17, 2009 British Telecom 6 L. Fang 7 Cisco Systems, Inc. 9 December 17, 2008 11 LDP IGP Synchronization 12 draft-ietf-mpls-ldp-igp-sync-04.txt 14 Status of This Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 This memo provides information for the Internet community. It does 20 not specify an Internet standard of any kind. Distribution of this 21 memo is unlimited. 23 By submitting this Internet-Draft, each author represents that any 24 applicable patent or other IPR claims of which he or she is aware 25 have been or will be disclosed, and any of which he or she becomes 26 aware will be disclosed, in accordance with BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 18, 2009. 46 Copyright and License Notice 48 Copyright (c) 2008 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 LDP IGP Synchronization December 2008 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. 60 Abstract 62 In certain networks there is a dependency on edge-to-edge Label 63 Switched Paths (LSPs) setup by Label Distribution Protocol (LDP), 64 e.g., networks that are used for MultiProtocol Label Switching 65 (MPLS) Virtual Private Network (VPN) applications. For such 66 applications it is not possible to rely on Internet Protocol (IP) 67 forwarding if the MPLS LSP is not operating appropriately. 68 Blackholing of labeled traffic can occur in situations where the 69 Interior Gateway Protocol (IGP) is operational on a link but LDP is 70 not operational on that link. While the link could still be used for 71 IP forwarding, it is not useful for MPLS forwarding, for example, 72 MPLS VPN; Border Gateway Protocol (BGP) route free core; or IP 73 address carried in the packet is out of the RFC 1918 [RFC 1918] 74 space. This document describes a mechanism to avoid traffic loss due 75 to this condition without introducing any protocol changes. 77 Table of Contents 79 1. Introduction..................................................3 80 2. Proposed Solution.............................................3 81 3. Applicability.................................................5 82 4. Interaction with TE Tunnels...................................5 83 5. Security Considerations.......................................6 84 6. IANA Considerations...........................................6 85 7. Normative References..........................................6 86 8. Informational References......................................6 87 9. Authors' Addresses............................................7 88 10. Acknowledgments..............................................7 90 Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 94 this document are to be interpreted as described in RFC2119 [RFC 95 2119]. 97 LDP IGP Synchronization December 2008 99 1. Introduction 101 LDP [RFC 5036] establishes MPLS LSPs along the shortest path to a 102 destination as determined by IP forwarding. In a common network 103 design, LDP is used to provide label switched paths throughout the 104 complete network domain covered by an IGP such as Open Shortest 105 Path First (OSPF) [RFC 2328] or Intermediate system to intermediate 106 system (IS-IS) [ISO.10589.1992], i.e., all links in the domain have 107 IGP as well as LDP adjacencies. 109 A variety of services a network provider may want to deploy over an 110 LDP enabled network depend on the availability of edge to edge 111 label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN 112 scenario for example, a given Provider-Edge(PE) router relies on 113 the availability of a complete MPLS forwarding path to the other PE 114 routers for the VPNs it serves. This means that along the IP 115 shortest path from one PE router to the other, all the links need 116 to have operational LDP sessions and the necessary label binding 117 must have been exchanged over those sessions. If only one link 118 along the IP shortest path is not covered by an LDP session, a 119 blackhole exists and services depending on MPLS forwarding will 120 fail. This might be a transient or a persistent error condition. 121 Some of the reasons for it could be 123 - A configuration error 125 - An implementation bug 127 - The link has just come up and has an IGP adjacency but LDP has 128 either not yet established an adjacency or session or 129 distributed all the label bindings. 131 LDP protocol has currently no way to correct the issue, LDP is not 132 a routing protocol; it cannot re-direct traffic to an alternate IGP 133 path. 135 2. Proposed Solution 137 The problem described above exists because LDP is tied to IP 138 forwarding decisions but no coupling between the IGP and LDP 139 operational state on a given link exists. If IGP is operational on 140 a link but LDP is not, a potential network problem exists. So the 141 solution described by this document is to discourage a link from 142 being used for IP forwarding as long as LDP is not fully 143 operational. 145 LDP IGP Synchronization December 2008 147 This has some similarity to the mechanism specified in [RFC 3137] 148 which allows an OSPF router to advertise that it should not be used 149 as a transit router. One difference is that [RFC 3137] raises the 150 link costs on all (stub) router links, while the mechanism 151 described in here applies on a per-link basis. 153 In detail: when LDP is not "fully operational" (see below) on a 154 given link, the IGP will advertise the link with maximum cost to 155 avoid any transit traffic over it if possible. In the case of 156 OSPF, this cost is LSInfinity (16-bit value 0xFFFF) as proposed in 157 [RFC 3137]. In the case of ISIS, the max metric value is 2^24-2 158 (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the 159 maximum link metric per [RFC 5305]) then this link is not 160 advertised in the topology. It is important to keep the link in the 161 topology to allow for IP traffic to use the link as a last resort 162 in case of massive failure. 164 LDP is considered fully operational on a link when an LDP hello 165 adjacency exists on it, a suitable associated LDP session (matching 166 the LDP Identifier of the hello adjacency) is established to the 167 peer at the other end of the link and all label bindings have been 168 exchanged over the session. At the present time, the latter 169 condition cannot generally be verified by a router and some 170 estimated may have to be used. A simple implementation strategy is 171 to use a configurable hold down timer to allow LDP session 172 establishment before declaring LDP fully operational. The default 173 timer is not defined in this document due to the concerns of the 174 large variations of the Label Information Base (LIB) table size and 175 the equipment capabilities. In addition, this is a current work in 176 progress on LDP End-of-LIB as specified in [LDP End-of-LIB], it 177 enables the LDP speaker to signal the completion of its initial 178 advertisement following session establish. When LDP End-of-LIB is 179 implemented, the configurable hold down timer is no longer needed. 180 The neighbor LDP session is considered fully operational when the 181 End-of-LIB notification message is received. 183 This is typically sufficient to deal with the link when it is being 184 brought up. LDP protocol extensions to indicate the complete 185 transmission of all currently available label bindings after a 186 session has come up are conceivable but not addressed in this 187 document. 189 The mechanism described in this document does not entail any 190 protocol changes and is a local implementation issue. 192 The problem space and solution specified in this document have also 193 been discussed in an IEEE Communications Magazine paper [LDP 194 Failure Recovery]. 196 LDP IGP Synchronization December 2008 198 3. Applicability 200 In general, the proposed procedure is applicable in networks where 201 the availability of LDP signaled MPLS LSPs and avoidance of 202 blackholes for MPLS traffic is more important than always choosing 203 an optimal path for IP forwarded traffic. Note however that non- 204 optimal IP forwarding only occurs for a short time after a link 205 comes up or when there is a genuine problem on a link. In the 206 latter case an implementation should issue network management alerts 207 to report the error condition and enable the operator to address it. 209 Example network scenarios that benefit from the mechanism described 210 here are MPLS VPNs and BGP-free core network designs where traffic 211 can only be forwarded through the core when LDP forwarding state is 212 available throughout. 214 The usefulness of this mechanism also depends on the availability 215 of alternate paths with sufficient bandwidth in the network should 216 one link be assigned to the maximum cost due to unavailability of 217 LDP service over it. 219 On broadcast links with more than one IGP/LDP peer, the cost-out 220 procedure can only be applied to the link as a whole and not an 221 individual peer. So a policy decision has to be made whether the 222 unavailability of LDP service to one peer should result in the 223 traffic being diverted away from all the peers on the link. 225 4. Interaction with TE Tunnels 227 In some networks, LDP is used in conjunction with RSVP-TE which sets 228 up traffic-engineered tunnels. The path computation for the TE 229 tunnels is based on the TE link cost which is flooded by the IGP in 230 addition to the regular IP link cost. The mechanism described in 231 this document should only be applied to the IP link cost to prevent 232 any unnecessary TE tunnel reroutes. 234 In order to establish LDP LSPs across a TE tunnel, a targeted LDP 235 session between the tunnel endpoints needs to exist. This presents 236 a problem very similar to the case of a regular LDP session over a 237 link (the case discussed so far): when the TE tunnel is used for IP 238 forwarding, the targeted LDP session needs to be operational to 239 avoid LDP connectivity problems. Again, raising the IP cost of the 240 tunnel while there is no operational LDP session will solve the 241 problem. When there is no IGP adjacency over the tunnel and the 242 tunnel is not advertised as link into the IGP, this becomes a local 243 issue of the tunnel headend router. 245 LDP IGP Synchronization December 2008 247 5. Security Considerations 249 A DoS attack that brings down LDP service on a link or prevents it 250 from becoming operational on a link could be one of the 251 possibilities that causes LDP related traffic blackholing. This 252 document does not address how to prevent LDP session failure. The 253 mechanism described here prevents the use of the link when LDP is 254 not operational while IGP is. Assigning the IGP cost to maximum on 255 the link where LDP is failed and IGP is not should not introduce 256 new security threats. The operation is internal in the router to 257 allow LDP and IGP to communicate and react. Making many LDP links 258 unavailable, however, is a security threat which can cause traffic 259 being dropped due to limited available network capacity. This may 260 be triggered by operational error or implementation error. They are 261 considered as general Security issues and should follow the current 262 best security practice [MPLS-GMPLS-Security]. 264 6. IANA Considerations 266 This document has no actions for IANA. 268 7. Normative References 270 [RFC 5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., 271 and B. Thomas, "LDP Specification", RFC 5036, October 2007. 273 [RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 274 1998. 276 8. Informational References 278 [RFC 1918] Rekhter, Y., "Address Allocation for Private Internets", 279 BCP: 5, RFC 1918, February 1996. 281 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997 284 [RFC 3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 285 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. 287 [RFC 5305] Li, T., Smit, H., Intermediate System to Intermediate 288 System (IS-IS) Extension for Traffic Engineering, October 2008. 290 LDP IGP Synchronization December 2008 292 [ISO.10589.1992]International Organization for 293 Standardization,"Intermediate system to intermediate system intra- 294 domain-routing routine information exchange protocol for use in 295 conjunction with the protocol for providing the connectionless-mode 296 Network Service (ISO 8473)", ISO Standard 10589, 1992. 298 [LDP Failure Recovery] Fang, L., Atlas, A., Chiussi, F., Kompella, 299 K., and Swallow, G., "LDP Failure Detection and Recovery", IEEE 300 Communications Magazine, Vol.42, No.10, October 2004. 302 [LDP End-of-LIB] Asati, R., LDP End-of-LIB, draft-ietf-mpls-ldp- 303 end-of-lib-01.txt, work in progress, September 2008. 305 [MPLS-GMPLS-Security] Fang. L., Ed., "Security Framework for MPLS 306 and GMPLS Networks", draft-ietf-mpls-mpls-and-gmpls-security- 307 framework-04.txt, work in progress, November 2008. 309 9. Authors' Addresses 311 Markus Jork 312 NextPoint Networks 313 3 Fedral St. 314 Billerica, MA 01821 315 USA 316 Email: mjork@nextpointnetworks.com 318 Alia Atlas 319 British Telecom 320 Email: alia.atlas@bt.com 322 Luyuan Fang 323 Cisco Systems, Inc. 324 300 Beaver Brook Road 325 Boxborough, MA 01719 326 USA 327 Email: lufang@cisco.com 328 Phone: 1 (978) 936-1633 330 10. Acknowledgments 332 Funding for the RFC Editor function is provided by the IETF 333 Administrative Support Activity (IASA). 335 The authors would like to thank Bruno Decraene for his in depth 336 discussion and comments; thank Dave Ward for his helpful review and 337 input; and thank Loa Andersson, Ross Callon, Amanda Baber, Francis 338 Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, 339 LDP IGP Synchronization December 2008 341 Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their review 342 and comments.