idnits 2.17.1 draft-ietf-mpls-igp-sync-01.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 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 367. 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: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: 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 == 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 (February 2008) is 5913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 78, but not defined -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 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: August 2008 British Telecom 6 L. Fang 7 Cisco Systems, Inc. 9 February 2008 11 LDP IGP Synchronization 12 draft-ietf-mpls-igp-sync-01.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 49 Fang, et al. Informational 1 50 MPLS/GMPLS Security framework 51 February 2008 53 still be used for IP forwarding, it is not useful for traffic with 54 packets carrying a label stack of more than one label or when the IP 55 address carried in the packet is out of the RFC1918 space. This 56 document describes a mechanism to avoid traffic loss due to this 57 condition without introducing any protocol changes. 59 Table of Contents 61 1. Introduction..................................................2 62 2. Proposed Solution.............................................3 63 3. Applicability.................................................4 64 4. Interaction With TE Tunnels...................................5 65 5. Security Considerations.......................................5 66 6. IANA Considerations...........................................5 67 7. Normative References..........................................6 68 8. Informational References......................................6 69 9. Author's Addresses............................................6 70 10. Acknowledgements.............................................8 72 Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 76 this document are to be interpreted as described in RFC2119 [RFC 77 2119]. 79 1. Introduction 81 LDP [RFC5036] establishes MPLS LSPs along the shortest path to a 82 destination as determined by IP forwarding. In a common network 83 design, LDP is used to provide label switched paths throughout the 84 complete network domain covered by an IGP such as OSPF [RFC2328] or 85 IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as 86 well as LDP adjacencies. 88 A variety of services a network provider may want to deploy over an 89 LDP enabled network depend on the availability of edge to edge 90 label switched paths. In a L2 or L3 VPN scenario for example, a 91 given PE router relies on the availability of a complete MPLS 92 forwarding path to the other PE routers for the VPNs it serves. 93 This means that along the IP shortest path from one PE router to 94 the other, all the links need to have operational LDP sessions and 96 Fang, et al. Informational 2 97 MPLS/GMPLS Security framework 98 February 2008 100 the necessary label binding must have been exchanged over those 101 sessions. If only one link along the IP shortest path is not 102 covered by an LDP session, a blackhole exists and services 103 depending on MPLS forwarding will fail. This might be a transient 104 or a persistent error condition. Some of the reasons for it could 105 be 107 - a configuration error, 109 - an implementation bug, 111 - the link has just come up and has an IGP adjacency but LDP has 112 either not yet established an adjacency or session or 113 distributed all the label bindings. 115 The LDP protocol itself has currently no means to indicate to a 116 service depending on it whether there is an uninterrupted label 117 switched path available to the desired destination or not. 119 2. Proposed Solution 121 The problem described above exists because LDP is tied to IP 122 forwarding decisions but no coupling between the IGP and LDP 123 operational state on a given link exists. If IGP is operational on 124 a link but LDP is not, a potential network problem exists. So the 125 solution described by this document is to discourage a link from 126 being used for IP forwarding as long as LDP is not fully 127 operational. 129 This has some similarity to the mechanism specified in [RFC3137] 130 which allows an OSPF router to advertise that it should not be used 131 as a transit router. One difference is that [RFC3137] raises the 132 link costs on all (stub) router links, while the mechanism 133 described in here applies on a per-link basis. 135 In detail: when LDP is not "fully operational" (see below) on a 136 given link, the IGP will advertise the link with maximum cost to 137 avoid any transit traffic over it if possible. In the case of OSPF 138 this cost is LSInfinity (16-bit value 0xFFFF) as proposed in 139 [RFC3137]. Note that the link is not just simply removed from the 140 topology because LDP depends on the IP reachability to establish 141 its adjacency and session. Also, if there is no other link in the 142 network to reach a particular destination, no additional harm is 143 done by making this link available for IP forwarding at maximum 144 cost. 146 Fang, et al. Informational 3 147 MPLS/GMPLS Security framework 148 February 2008 150 LDP is considered fully operational on a link when an LDP hello 151 adjacency exists on it, a suitable associated LDP session (matching 152 the LDP Identifier of the hello adjacency) is established to the 153 peer at the other end of the link and all label bindings have been 154 exchanged over the session. The latter condition can not generally 155 be verified by a router and some heuristics may have to be used. A 156 simple implementation strategy is to wait some time after LDP 157 session establishment before declaring LDP fully operational in 158 order to allow for the exchange of label bindings. This is 159 typically sufficient to deal with the link when it is being brought 160 up. LDP protocol extensions to indicate the complete transmission of 161 all currently available label bindings after a session has come up 162 are conceivable but not addressed in this document. 164 The mechanism described in this document does not entail any 165 protocol changes and is a local implementation issue. However, it 166 is recommended that both sides of a link implement this mechanism 167 to be effective and to avoid asymmetric link costs which could 168 cause problems with IP multicast forwarding. 170 The problem space and solution specified in this document have also 171 been discussed in an IEEE Communications Magazine paper [LDP-Fail]. 173 3. Applicability 175 In general, the proposed procedure is applicable in networks where 176 the availability of LDP signaled MPLS LSPs and avoidance of 177 blackholes for MPLS traffic is more important than always choosing 178 an optimal path for IP forwarded traffic. Note however that non- 179 optimal IP forwarding only occurs for a short time after a link 180 comes up or when there is a genuine problem on a link. In the 181 latter case an implementation should issue network management alerts 182 to report the error condition and enable the operator to address it. 184 Example network scenarios that benefit from the mechanism described 185 here are MPLS VPNs and BGP-free core network designs where traffic 186 can only be forwarded through the core when LDP forwarding state is 187 available throughout. 189 The usefulness of this mechanism also depends on the availability 190 of alternate paths with sufficient bandwidth in the network should 191 one link be assigned to the maximum cost due to unavailability of 192 LDP service over it. 194 On broadcast links with more than one IGP/LDP peer, the cost-out 195 procedure can only be applied to the link as a whole and not an 196 individual peer. So a policy decision has to be made whether the 198 Fang, et al. Informational 4 199 MPLS/GMPLS Security framework 200 February 2008 202 unavailability of LDP service to one peer should result in the 203 traffic being diverted away from all the peers on the link. 205 4. Interaction With TE Tunnels 207 In some networks, LDP is used in conjunction with RSVP-TE which sets 208 up traffic-engineered tunnels. The path computation for the TE 209 tunnels is based on the TE link cost which is flooded by the IGP in 210 addition to the regular IP link cost. The mechanism described in 211 this document should only be applied to the IP link cost to prevent 212 any unnecessary TE tunnel reroutes. 214 In order to establish LDP LSPs across a TE tunnel, a targeted LDP 215 session between the tunnel endpoints needs to exist. This presents 216 a problem very similar to the case of a regular LDP session over a 217 link (the case discussed so far): when the TE tunnel is used for IP 218 forwarding, the targeted LDP session needs to be operational to 219 avoid LDP connectivity problems. Again, raising the IP cost of the 220 tunnel while there is no operational LDP session will solve the 221 problem. When there is no IGP adjacency over the tunnel and the 222 tunnel is not advertised as link into the IGP, this becomes a local 223 issue of the tunnel headend router. 225 5. Security Considerations 227 A DoS attack brings down LDP service on a link or prevents it from 228 becoming operational on a link could be one of the possibilities 229 that causes LDP related traffic blackholing. This document does not 230 address how to prevent LDP session failure. The mechanism described 231 here is to prevent the link to be used when LDP is not operational 232 while IGP is. Assigning the IGP cost to maximum on the link where 233 LDP is failed and IGP is not should not introduce new security 234 threats. The operation is internal in the router to allow LDP and 235 IGP to communicate and react. Making many LDP links unavailable, 236 however, is a security threat which can cause traffic being dropped 237 due to limited available network capacity. This may be trigged by 238 operational error or implementation error. They are considered as 239 general Security issues and should follow the current best security 240 practice. 242 6. IANA Considerations 244 This document has no actions for IANA. 246 Fang, et al. Informational 5 247 MPLS/GMPLS Security framework 248 February 2008 250 7. Normative References 252 [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., 253 and B. Thomas, "LDP Specification", RFC 5036, October 2007. 255 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 257 8. Informational References 259 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 260 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001. 262 [ISO.10589.1992]International Organization for 263 Standardization,"Intermediate system to intermediate system intra- 264 domain-routing routine information exchange protocol for use in 265 conjunction with the protocol for providing the connectionless-mode 266 Network Service (ISO 8473)", ISO Standard 10589, 1992. 268 [LDP-Fail] Fang, L., Atlas, A., Chiussi, F., K., Kompella, , and 269 Swallow, G., "LDP Failure Detection and Recovery", IEEE 270 Communications Magazine, Vol.42 No.10, October 2004. 272 9. Author's Addresses 274 Markus Jork 275 NextPoint Networks 276 3 Fedral St. 277 Billerica, MA 01821 278 USA 280 Email:mjork@nextpointnetworks.com 282 Alia Atlas 283 British Telecom 285 Email: alia.atlas@bt.com 287 Luyuan Fang 288 Cisco Systems, Inc. 289 300 Beaver Brook Road 290 Boxborough, MA 01719 291 USA 293 Email: lufang@cisco.com 295 Fang, et al. Informational 6 296 MPLS/GMPLS Security framework 297 February 2008 299 Intellectual Property 301 The IETF takes no position regarding the validity or scope of any 302 Intellectual Property Rights or other rights that might be claimed 303 to pertain to the implementation or use of the technology described 304 in this document or the extent to which any license under such 305 rights might or might not be available; nor does it represent that 306 it has made any independent effort to identify any such rights. 307 Information on the procedures with respect to rights in RFC 308 documents can be found in BCP 78 and BCP 79. 310 Copies of IPR disclosures made to the IETF Secretariat and any 311 assurances of licenses to be made available, or the result of an 312 attempt made to obtain a general license or permission for the use 313 of such proprietary rights by implementers or users of this 314 specification can be obtained from the IETF on-line IPR repository 315 at http://www.ietf.org/ipr. 317 The IETF invites any interested party to bring to its attention any 318 copyrights, patents or patent applications, or other proprietary 319 rights that may cover technology that may be required to implement 320 this standard. Please address the information to the IETF at ietf- 321 ipr@ietf.org. 323 Full Copyright Statement 325 Copyright (C) The IETF Trust (2008). 327 This document is subject to the rights, licenses and restrictions 328 contained in BCP 78, and except as set forth therein, the authors 329 retain all their rights. 331 This document and the information contained herein are provided on 332 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 333 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 334 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 335 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 336 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 337 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 338 FOR A PARTICULAR PURPOSE. 340 Intellectual Property 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed 344 to pertain to the implementation or use of the technology described 346 Fang, et al. Informational 7 347 MPLS/GMPLS Security framework 348 February 2008 350 in this document or the extent to which any license under such 351 rights might or might not be available; nor does it represent that 352 it has made any independent effort to identify any such rights. 353 Information on the procedures with respect to rights in RFC 354 documents can be found in BCP 78 and BCP 79. 356 Copies of IPR disclosures made to the IETF Secretariat and any 357 assurances of licenses to be made available, or the result of an 358 attempt made to obtain a general license or permission for the use 359 of such proprietary rights by implementers or users of this 360 specification can be obtained from the IETF on-line IPR repository 361 at http://www.ietf.org/ipr. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights that may cover technology that may be required to implement 366 this standard. Please address the information to the IETF at ietf- 367 ipr@ietf.org. 369 10. Acknowledgements 371 Funding for the RFC Editor function is provided by the IETF 372 Administrative Support Activity (IASA). 374 The authors would like to thank Loa Andersson for his review and 375 comments. 377 Fang, et al. Informational 8