idnits 2.17.1 draft-ietf-mpls-igp-sync-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 3978, Section 5.5, updated by RFC 4748 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 280. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 6, 2007) is 6077 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3137 (Obsoleted by RFC 6987) -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP-Fail' Summary: 4 errors (**), 0 flaws (~~), 2 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 Reef Point 4 Expires: March 9, 2008 A. Atlas 5 Google 6 L. Fang 7 Cisco Systems, Inc. 8 September 6, 2007 10 LDP IGP Synchronization 11 draft-ietf-mpls-igp-sync-00 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 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 9, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 In networks depending on edge-to-edge establishment of MPLS 45 forwarding paths via LDP, blackholing of traffic can occur in 46 situations where the IGP is operational on a link and thus the link 47 is used for IP forwarding but LDP is not operational on that link for 48 whatever reason. This document describes a mechanism to avoid 49 traffic loss due to this condition without introducing any protocol 50 changes. 52 1. Introduction 54 LDP [RFC3036] establishes MPLS LSPs along the shortest path to a 55 destination as determined by IP forwarding. In a common network 56 design, LDP is used to provide label switched paths throughout the 57 complete network domain covered by an IGP such as OSPF [RFC2328] or 58 IS-IS [ISO.10589.1992], i.e. all links in the domain have IGP as well 59 as LDP adjacencies. 61 A variety of services a network provider may want to deploy over an 62 LDP enabled network depend on the availability of edge to edge label 63 switched paths. In a L2 or L3 VPN scenario for example, a given PE 64 router relies on the availability of a complete MPLS forwarding path 65 to the other PE routers for the VPNs it serves. This means that 66 along the IP shortest path from one PE router to the other, all the 67 links need to have operational LDP sessions and the necessary label 68 binding must have been exchanged over those sessions. If only one 69 link along the IP shortest path is not covered by an LDP session, a 70 blackhole exists and services depending on MPLS forwarding will fail. 71 This might be a transient or a persistent error condition. Some of 72 the reasons for it could be 74 o a configuration error, 76 o an implementation bug, 78 o the link has just come up and has an IGP adjacency but LDP has 79 either not yet established an adjacency or session or distributed 80 all the label bindings. 82 The LDP protocol itself has currently no means to indicate to a 83 service depending on it whether there is an uninterrupted label 84 switched path available to the desired destination or not. 86 2. Proposed Solution 88 The problem described above exists because LDP is tied to IP 89 forwarding decisions but no coupling between the IGP and LDP 90 operational state on a given link exists. If IGP is operational on a 91 link but LDP is not, a potential network problem exists. So the 92 solution described by this document is to prevent a link from being 93 used for IP forwarding as long as LDP is not fully operational. This 94 has some similarity to the mechanism specified in [RFC3137] which 95 allows an OSPF router to advertise that it should not be used as a 96 transit router. One difference is that [RFC3137] raises the link 97 costs on all (stub) router links, while the mechanism described in 98 here applies on a per-link basis. 100 In detail: when LDP is not "fully operational" (see below) on a given 101 link, the IGP will advertise the link with maximum cost to avoid any 102 transit traffic over it if possible. In the case of OSPF this cost 103 is LSInfinity (16-bit value 0xFFFF) as proposed in [RFC3137]. Note 104 that the link is not just simply removed from the topology because 105 LDP depends on the IP reachability to establish its adjacency and 106 session. Also, if there is no other link in the network to reach a 107 particular destination, no additional harm is done by making this 108 link available for IP forwarding at maximum cost. 110 LDP is considered fully operational on a link when an LDP hello 111 adjacency exists on it, a suitable associated LDP session (matching 112 the LDP Identifier of the hello adjacency) is established to the peer 113 at the other end of the link and all label bindings have been 114 exchanged over the session. The latter condition can not generally 115 be verified by a router and some heuristics may have to be used. A 116 simple implementation strategy is to wait some time after LDP session 117 establishment before declaring LDP fully operational in order to 118 allow for the exchange of label bindings. This is typically 119 sufficient to deal with the link when it is being brought up. LDP 120 protocol extensions to indicate the complete transmission of all 121 currently available label bindings after a session has come up are 122 conceivable but not addressed in this document. 124 The mechanism described in this document does not entail any protocol 125 changes and is a local implementation issue. However, it is 126 recommended that both sides of a link implement this mechanism to be 127 effective and to avoid asymmetric link costs which could cause 128 problems with IP multicast forwarding. 130 The problem space and solution specified in this document have also 131 been discussed in an IEEE Communications Magazine paper [LDP-Fail]. 133 3. Applicability 135 Example network scenarios that benefit from the mechanism described 136 in here are MPLS VPNs and BGP-free core network designs where traffic 137 can only be forwarded through the core when LDP forwarding state is 138 available throughout. 140 In general, the proposed procedure is applicable in networks where 141 the availability of LDP signaled MPLS LSPs and avoidance of 142 blackholes for MPLS traffic is more important than always choosing an 143 optimal path for IP forwarded traffic. Note however that non-optimal 144 IP forwarding only occurs for a short time after a link comes up or 145 when there is a genuine problem on a link. In the latter case an 146 implementation should issue network management alerts to report the 147 error condition and enable the operator to address it. 149 The usefulness of this mechanism also depends on the availability of 150 alternate paths with sufficient bandwidth in the network should one 151 link get costed out due to unavailability of LDP service over it. 153 On broadcast links with more than one IGP/LDP peer, the cost-out 154 procedure can only be applied to the link as a whole and not an 155 individual peer. So a policy decision has to be made whether the 156 unavailability of LDP service to one peer should result in the 157 traffic being diverted away from all the peers on the link. 159 4. Interaction With TE Tunnels 161 In some networks, LDP is used in conjunction with RSVP-TE which sets 162 up traffic-engineered tunnels. The path computation for the TE 163 tunnels is based on the TE link cost which is flooded by the IGP in 164 addition to the regular IP link cost. The mechanism described in 165 this document should only be applied to the IP link cost to prevent 166 any unnecessary TE tunnel reroutes. 168 In order to establish LDP LSPs across a TE tunnel, a targeted LDP 169 session between the tunnel endpoints needs to exist. This presents a 170 problem very similar to the case of a regular LDP session over a link 171 (the case discussed so far): when the TE tunnel is used for IP 172 forwarding, the targeted LDP session needs to be operational to avoid 173 LDP connectivity problems. Again, raising the IP cost of the tunnel 174 while there is no operational LDP session will solve the problem. 175 When there is no IGP adjacency over the tunnel and the tunnel is not 176 advertised as link into the IGP, this becomes a local issue of the 177 tunnel headend router. 179 5. Security Considerations 181 A DoS attack that brings down LDP service on a link or prevents it 182 from becoming operational on a link will now additionally cause non- 183 optimal IP forwarding within the network. However, as discussed 184 above this is considered beneficial as it prevents MPLS traffic from 185 being dropped. 187 6. IANA Considerations 189 This document has no actions for IANA. 191 7. References 193 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 194 B. Thomas, "LDP Specification", RFC 3036, January 2001. 196 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 198 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 199 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 200 June 2001. 202 [ISO.10589.1992] 203 International Organization for Standardization, 204 "Intermediate system to intermediate system intra-domain- 205 routing routine information exchange protocol for use in 206 conjunction with the protocol for providing the 207 connectionless-mode Network Service (ISO 8473)", 208 ISO Standard 10589, 1992. 210 [LDP-Fail] 211 Fang, L., Atlas, A., Chiussi, F., Kompella, K., and G. 212 Swallow, "LDP Failure Detection and Recovery", IEEE 213 Communications Vol.42 No.10, October 2004. 215 Authors' Addresses 217 Markus Jork 218 Reef Point Systems 219 8 New England Executive Park 220 Burlington, MA 01803 221 US 223 Phone: +1 781 359 5071 224 Email: mjork@reefpoint.com 226 Alia Atlas 227 Google, Inc. 228 One Broadway, 7th Floor 229 Cambridge, MA 02142 230 US 232 Email: akatlas@google.com 234 Luyuan Fang 235 Cisco Systems, Inc. 236 300 Beaver Brook Road 237 Boxborough, MA 01719 238 US 240 Email: lufang@cisco.com 242 Full Copyright Statement 244 Copyright (C) The IETF Trust (2007). 246 This document is subject to the rights, licenses and restrictions 247 contained in BCP 78, and except as set forth therein, the authors 248 retain all their rights. 250 This document and the information contained herein are provided on an 251 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 252 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 253 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 254 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 255 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 256 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 258 Intellectual Property 260 The IETF takes no position regarding the validity or scope of any 261 Intellectual Property Rights or other rights that might be claimed to 262 pertain to the implementation or use of the technology described in 263 this document or the extent to which any license under such rights 264 might or might not be available; nor does it represent that it has 265 made any independent effort to identify any such rights. Information 266 on the procedures with respect to rights in RFC documents can be 267 found in BCP 78 and BCP 79. 269 Copies of IPR disclosures made to the IETF Secretariat and any 270 assurances of licenses to be made available, or the result of an 271 attempt made to obtain a general license or permission for the use of 272 such proprietary rights by implementers or users of this 273 specification can be obtained from the IETF on-line IPR repository at 274 http://www.ietf.org/ipr. 276 The IETF invites any interested party to bring to its attention any 277 copyrights, patents or patent applications, or other proprietary 278 rights that may cover technology that may be required to implement 279 this standard. Please address the information to the IETF at 280 ietf-ipr@ietf.org. 282 Acknowledgment 284 Funding for the RFC Editor function is provided by the IETF 285 Administrative Support Activity (IASA).