idnits 2.17.1 draft-decraene-mpls-ldp-interarea-04.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 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. 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 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (March 2007) is 6251 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) == Unused Reference: 'MPLS' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'MP-BGP' is defined on line 343, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 3107 (ref. 'MPLS-BGP') (Obsoleted by RFC 8277) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B Decraene 3 Internet Draft JL Le Roux 4 Document: draft-decraene-mpls-ldp-interarea-04.txt France Telecom 5 Expiration Date: September 2007 6 I Minei 7 Juniper Networks, Inc. 9 March 2007 11 LDP extension for Inter-Area LSP 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 To facilitate the establishment of Label Switched Paths (LSP) that 38 would span multiple IGP areas in a given Autonomous System (AS), this 39 document proposes a new optional label mapping procedure for the 40 Label Distribution Protocol (LDP). 42 This procedure allows the use of a label if the Forwarding 43 Equivalence Class (FEC) Element matches an entry in the routing table 44 (RIB). Matching is defined by an IP longest match search and does not 45 mandate an exact match. 47 1. Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119. 53 2. Terminology 55 IGP Area: OSPF Area or IS-IS level 57 ABR: OSPF Area Border Router or IS-IS L1/L2 router 59 LSP: Label Switched Path 61 Intra-area LSP: LSP that does not traverse any IGP area boundary. 63 Inter-area LSP: LSP that traverses at least one IGP area boundary. 65 3. Introduction 67 Link state IGPs such as OSPF [OSPFv2] and IS-IS [IS-IS] allow the 68 partition of an autonomous system into areas or levels so as to 69 increase routing scalability within a routing domain. 71 However, [LDP] requires that the IP address of the FEC Element should 72 *exactly* match an entry in the IP RIB: according to [LDP] section 73 3.5.7.1 (Label Mapping Messages Procedures) "An LSR receiving a Label 74 Mapping message from a downstream LSR for a Prefix or Host Address 75 FEC Element should not use the label for forwarding unless its 76 routing table contains an entry that exactly matches the FEC 77 Element". 79 Therefore, MPLS LSPs between LERs in different areas/levels are not 80 setup unless the exact (/32 for IPv4) loopback addresses of all the 81 LERs are redistributed across all areas. 83 The problem statement is discussed in section 3. Then, in section 4 84 we extend the Label Mapping Procedure defined in [LDP] so as to 85 support the setup of contiguous inter-area LSPs while maintaining IP 86 prefix aggregation on the ABRs. This basically consists of allowing 87 for "Longest Match Based" Label Mapping. 89 4. Problem statement 91 Provider based MPLS VPN networks are expanding with the success of 92 Layer 3 VPN ([L3-VPN]) and the new deployments of layer 2 VPNs 93 ([VPLS-BGP], [VPLS-LDP]). Service Provider MPLS backbones are 94 significantly growing both in terms of density with the addition of 95 PEs to connect new customers and in terms of footprint as traditional 96 layer two aggregation networks are being replaced by IP/MPLS 97 networks. As a consequence many providers need to introduce IGP 98 areas. Inter-area LSPs, that is LSPs that traverse at least two IGP 99 areas are required to ensure MPLS connectivity between PEs located in 100 distinct IGP areas. 102 To set up the required MPLS LSPs between PEs in different IGP areas, 103 services providers have currently three solutions: LDP with IGP route 104 leaking, BGP [MPLS-BGP] over LDP with MPLS hierarchy, or also inter- 105 area RSVP-TE [ID-RSVP-TE]. 107 IGP route leaking consists in redistributing all /32 PE loopback 108 addresses across area boundaries. As a result, LDP finds in the RIB 109 an exact match for its FEC and sets up the LSP. 110 As a consequence, the potential benefits that a multi-area domain may 111 yield are significantly diminished since a lot of addresses have to 112 be redistributed by ABRs, and the number of IP entries in the LSDB 113 and RIB maintained by every LSR of the domain (whatever the 114 area/level it belongs to) cannot be minimized. 116 Service providers may also set up these inter-area LSPs by using MPLS 117 hierarchy with BGP [MPLS-BGP] as a label distribution protocol 118 between areas. The BGP next hop would typically be the ABRs and the 119 BGP-created LSPs would be nested within intra-area LSPs setup by LDP 120 between PEs and ABRs and between ABRs. 121 This solution is not adequate for Service Providers which don't want 122 to run BGP on their P routers as it requires BGP on all ABRs. In 123 addition, this scheme has an impact on the availability, as the 124 recovery upon ABR failure relies on BGP convergence. Also MPLS 125 hierarchy does not allow locally protecting the LSP against ABR 126 failures (LDP Fast Reroute), and hence ensuring sub-50ms recovery 127 upon ABR failure. The resulting convergence time may not be 128 acceptable for stringent SLAs required for voice or mission critical 129 applications. Finally, this solution requires a significant migration 130 effort for Service Providers which started with LDP and IGP route 131 leaking to quickly set-up the fist inter-area LSPs. 133 Service providers may also setup these inter-area LSPs by using 134 inter-area RSVP-TE [ID-RSVP-TE]. This is a relevant solution when 135 RSVP-TE is already used for setting up intra-area LSPs, and inter- 136 area traffic engineering features are required. In return this is not 137 a desired solution when LDP is already used for setting up intra-area 138 LSPs, and inter-area traffic engineering features are not required. 140 To avoid the above drawbacks, there is a need for an LDP based 141 solution which allows setting up contiguous inter-area LSPs while 142 avoiding leaking of /32 PE loopback addresses across area boundaries, 143 and hence keeping all the benefits of IGP hierarchy. 145 In that context, this document defines a new LDP Label Mapping 146 Procedure so as to support the setup of contiguous inter-area LSPs 147 while maintaining IP prefix aggregation on the ABRs. This procedure 148 is similar to the one defined in [LDP] but performs a longest match 149 when searching the FEC element in the RIB. 151 5. Label Mapping Procedure 153 This document defines a new label mapping procedure for LDP. It MUST 154 be possible to activate/deactivate this procedure by configuration 155 and it SHOULD be deactivated by default. It MAY be possible to 156 activate it on a per prefix basis. 158 With this new longest match label mapping procedure, a LSR receiving 159 a Label Mapping message from a neighbor LSR for a Prefix Address FEC 160 Element SHOULD use the label for MPLS forwarding if its routing table 161 contains an entry that matches the FEC Element and the advertising 162 LSR is a next hop to reach the FEC. If so, it SHOULD advertise the 163 FEC Element and a label to its LDP peers. 165 By "matching FEC Element", one should understand an IP longest match. 166 That is, either the LDP FEC element exactly matches an entry in the 167 IP RIB or the FEC element is a subset of an IP RIB entry. There is no 168 match for other cases such as the FEC element is a superset of a RIB 169 entry. 171 Note that with this longest match Label Mapping Procedure, each LSP 172 established by LDP still strictly follows the shortest path(s) 173 defined by the IGP. 175 FECs selected by this "Longest Match" label mapping procedure will be 176 distributed in an ordered way. However this procedure is applicable 177 to both independent and ordered distribution control mode. 179 As per RFC 3036, LDP has already some interactions with the RIB. In 180 particular, it needs to be aware of the following events: 181 - prefix UP when a new IP prefix appears in the RIB 182 - prefix DOWN when an existing prefix disappears 183 - next-hop change when an existing prefix have new next hop 184 following a routing change. 186 With the longest match procedure, multiple FECs may be concerned by a 187 single RIB prefix change. The LSR must check all the FECs which are a 188 subset of this RIB prefix. So some LDP reactions following a RIB 189 event are changed: 190 - When a new prefix appears in the RIB, the LSR MUST check if this 191 prefix is a better match for some existing FECs. E.g. the FEC 192 elements 192.0.2.1/32 and 192.0.2.2/32 used the IP RIB entry 193 192.0.0/16 and a new more specific IP RIB entry 192.0.2/24 194 appears. This may result in changing the LSR used as next hop 195 and hence the NHLFE for this FEC. 196 - When a prefix disappears in the RIB, the LSR MUST check all FEC 197 elements which are using this RIB prefix as best match. For each 198 FEC, if another RIB prefix is found as best match, LDP MUST use 199 it. This may result in changing the LSR used as next hop and 200 hence the NHLFE for this FEC. Otherwise, the LSR MUST remove the 201 FEC binding and send a label withdraw message. 202 - When the next-hop of a RIB prefix change, the LSR must change 203 the NHLFE of all the FEC elements using this prefix. 205 6. Application examples 207 6.1. Inter-area LSPs 209 Consider the following example of an autonomous system with one 210 backbone area and two edge areas: 212 Area "B" 214 Level 2 / Backbone area 216 +--------------------------+ 217 Area "A" | | Area "C" 218 | | 219 Level 1 | | Level 1 / area 220 | P1 | 221 +----------+ +-------------+ 222 | | P2 | PE1 | 192.0.2.1/32 223 | | | | 224 |PE4 ABR2 ABR1 PE2 | 192.0.2.2/32 225 | | P3 | | 226 | | | PE3 | 192.0.2.3/32 227 +----------+ +-------------+ 228 | | 229 +--------------------------+ 231 Figure 1: An IGP domain with two areas attached to the Backbone 232 Area. 234 Note that this applies equally to IS-IS and OSPF. An ABR refers here 235 either to an OSPF ABR or to an IS-IS L1/L2 node. 237 All routers are MPLS enabled and MPLS connectivity (ie an LSP) is 238 required between all PE routers. 240 In the "egress" area "C", the records available are: 241 IGP RIB LDP FEC elements: 242 192.0.2.1/32 192.0.2.1/32 243 192.0.2.2/32 192.0.2.2/32 244 192.0.2.3/32 192.0.2.3/32 246 The area border router ABR1 advertises in the backbone area: 247 - the aggregated IP prefix 192.0.2/24 in the IGP 248 - all the individual IP FEC elements (/32) in LDP 250 In the "backbone" area "B", the records available are: 251 IGP RIB LDP FEC elements: 252 192.0.2/24 192.0.2.1/32 253 192.0.2.2/32 254 192.0.2.3/32 256 The area border router ABR2 advertises in the area "A": 257 - an aggregated IP prefix 192.0/16 in the IGP 258 - all the individual IP FEC elements (/32) in LDP 260 In the "ingress" area "A", the records available are: 261 IGP RIB LDP FEC elements: 262 192.0/16 192.0.2.1/32 263 192.0.2.2/32 264 192.0.2.3/32 266 In this situation, one LSP is established between the ingress PE4 and 267 every egress PE of area C while maintaining IP prefix aggregation on 268 the ASBRs. 270 6.2. Use of static routes 272 Consider the following example where a LER is dual-connected to two 273 LSRs: 275 +--------LSR1---- 276 | | 277 LER | 278 | | 279 +--------LSR2---- 281 Figure 2: LER dual-connected to two LSRs. 283 In some situations, especially on the edge of the network, it is 284 valid to use static IP routes between the LER and the two LSRs. If 285 necessary, the BFD protocol can be used to quickly detect loss of 286 connectivity. 288 The LDP specification defined in [LDP] would require on the ingress 289 LER the configuration and the maintenance of one IP route per egress 290 LER and per outgoing interface. 292 The longest match Label Mapping Procedure described in this document 293 only requires one IP route per outgoing interface. 295 7. Caveats for deployment 297 7.1. Deployment consideration 299 LSRs compliant with this document are backward compatible with LSRs 300 that comply with [LDP]. 302 For the successful establishment of end-to-end MPLS LSPs whose FEC 303 are aggregated in the RIB, this specification must be implemented on 304 all LSRs in all areas where IP aggregation is used. 306 If all IP prefixes are leaked in the IGP backbone area and only stub 307 areas use IP aggregation, LSRs in the backbone area don't need to be 308 compliant with this document. 310 7.2. Impact on routing convergence time 312 In case of an egress LER failure, performing IP route aggregation on 313 ABRs will change the routing convergence behavior. The IGP will not 314 propagate the notification of the egress LER failure outside of the 315 egress area and failure notification will rely on LDP signaling 316 through the end-to-end propagation of the LDP withdraw message. This 317 failure notification may be faster or slower depending on the 318 implementations, the IGP timers used and the network topology 319 (network diameter). 321 For failure of links and other nodes (Ps, ABRs), the failure 322 notification and the convergence is unchanged. The convergence time 323 may be improved because the RIB has fewer entries to update. 325 8. Security Considerations 327 The longest match Label Mapping procedure described in this document 328 does not introduce any change as far as the Security Consideration 329 section of [LDP] is concerned. 331 9. References 333 9.1. Normative References 335 [LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. 336 Thomas, "LDP Specification", RFC 3036, January 2001 338 [MPLS] E. Rosen, A. Viswanathan, R. Callon, " Multiprotocol 339 Label Switching Architecture", RFC 3031, January 2001 341 9.2. Informative References 343 [MP-BGP] Bates, T., Chandra, R., Katz, D. and Rekhter, Y, 344 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 346 [L3-VPN] Rosen, E., Rekhter, Y. ," BGP/MPLS IP Virtual Private 347 Networks (VPNs) ", RFC 4374, February 2006 349 [MPLS-BGP] Rekhter, Y., Rosen, E., "Carrying Label Information in 350 BGP-4", RFC 3107, May 2001 352 [OSPFv2] Moy, J.,"OSPF Version 2", RFC 2328, April 1998 354 [IS-IS] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 355 Dual Environments", RFC 1195, December 1990 357 [VPLS-BGP] Kompella, K., Rekhter, Y., "Virtual Private LAN Service 358 (VPLS) Using BGP for Auto-discovery and Signaling", RFC 4761, 359 January 2007. 361 [VPLS-LDP] Lasserre, M., Kompella, V., "Virtual Private LAN Service 362 (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 363 4762, January 2007. 365 [ID-RSVP-TE] Farrel, Ayyangar, Vasseur, " Inter domain MPLS and 366 GMPLS Traffic Engineering - RSVP-TE extensions", draft-ietf- 367 ccamp-inter-domain-rsvp-te, work in progress. 369 10. Acknowledgments 371 Authors would like to thank Yakov Rekhter, Stefano Previdi, Vach 372 Kompella, Benoit Fondeviole, Gilles Bourdon and Christian Jacquenet 373 for the useful discussions on this subject, their review and 374 comments. 376 11. Author's Addresses 378 Bruno Decraene 379 France Telecom 380 38-40 rue du General Leclerc 381 92794 Issy Moulineaux cedex 9 382 France 383 bruno.decraene@orange-ftgroup.com 385 Jean-Louis Le Roux 386 France Telecom 387 2, avenue Pierre-Marzin 388 22307 Lannion Cedex 389 France 390 jeanlouis.leroux@orange-ftgroup.com 391 Ina Minei 392 Juniper Networks 393 1194 N. Mathilda Ave. 394 Sunnyvale, CA 94089 395 ina@juniper.net 397 Intellectual Property Considerations 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at ietf- 419 ipr@ietf.org. 421 Copyright Statement 423 Copyright (C) The IETF Trust (2007). 425 This document is subject to the rights, licenses and restrictions 426 contained in BCP 78, and except as set forth therein, the authors 427 retain all their rights. 429 Disclaimer of Validity 431 This document and the information contained herein are provided 432 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 433 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 434 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 435 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 436 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 437 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 438 FOR A PARTICULAR PURPOSE. 440 Acknowledgment 442 Funding for the RFC Editor function is currently provided by the 443 Internet Society.