idnits 2.17.1 draft-swallow-mpls-aggregate-fec-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (July 7, 2008) is 5765 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) == Missing Reference: 'LSR' is mentioned on line 102, but not defined == Missing Reference: 'RFC1700' is mentioned on line 259, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Unused Reference: 'RFC4364' is defined on line 315, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group George Swallow 3 Internet Draft Cisco Systems, Inc. 4 Category: Standards Track 5 Expiration Date: January 2009 6 Jim Guichard 7 Cisco Systems, Inc. 9 July 7, 2008 11 Network Scaling with Aggregate LSPs 13 draft-swallow-mpls-aggregate-fec-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document defines a means for an Multiprotocol Label Switched 41 network to summarize routes while maintaining end-to-end LSP 42 connectivity thereby reducing the number of host routes that need 43 to be carried within the interior gateway protocol. 45 Contents 47 1 Introduction .............................................. 3 48 1.1 Conventions ............................................... 3 49 1.2 Terminology ............................................... 3 50 2 Overview .................................................. 4 51 2.1 Inter-area LSP Construction ............................... 4 52 2.2 Label forwarding operation ................................ 6 53 3 Aggregate FEC ............................................. 7 54 3.1 Aggregate FEC Element ..................................... 7 55 3.2 Label distribution procedures ............................. 7 56 4 Algorithmically derived de-aggregation label .............. 8 57 5 Security Considerations ................................... 8 58 6 IANA Considerations ....................................... 8 59 7 References ................................................ 8 60 7.1 Normative References ...................................... 8 61 7.2 Informative References .................................... 9 62 8 Authors' Addresses ........................................ 9 64 1. Introduction 66 The growth of next-generation Multiprotocol Label Switched 67 (MPLS)-based services such as l2vpn, l3vpn and so on, have introduced 68 an explosion in the number of edge devices that are needed to deploy 69 such services. Typically these services require an end-to-end label- 70 switched path LSP, from ingress Label-Switching Router (LSR) to 71 egress LSR. These LSPs are maintained between the host IP addresses 72 of the LSRs. This requirement forces the operator to carry each host 73 address for every edge device within their interior gateway protocol 74 (IGP) which has a negative impact on the scale and convergence goals 75 of their IGP. 77 This document defines extensions to the Label Distribution Protocol 78 (LDP) to provide a means for the end-to-end LSP path to be maintained 79 between edge devices without the necessity of carry each and every 80 host address within the IGP or to distribute labels throughout a 81 domain for host addresses. This is achieved by defining an Aggregate 82 Forwarding Equivalence Class (FEC) and an algorithmically derived 83 label per aggregated host route which stacked together form end-to- 84 end LSPs. 86 1.1. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 92 1.2. Terminology 94 ABR Area border router 95 FEC Forwarding equivalence class 96 IGP Interior gateway protocol 97 LDP Label Distribution Protocol 98 LIB Label information base 99 LSP Label-switched path 100 LSR label-switching router 101 NHLFE Next-hop label forwarding entry 102 PE Provider edge [LSR] 103 RIB Routing information base 104 VPN Virtual private network 106 2. Overview 108 In a typical MPLS deployment today, Service Providers are either 109 running a flat IGP or leaking the loopback addresses of their PEs 110 between the area of their IGPs. LDP then creates LSPs based on all 111 of these host routes. Our objective here is to eliminate the need 112 for a full mesh of LSPs between all PE pairs. This will enable 113 Service Providers to scale and improve the convergence of their IGPs. 115 The basic idea is to use an LSP bound to a summarized IP prefix to 116 deliver MPLS packets from the ingress PE, across the core, to the 117 ABRs serving the egress PEs. Nested within these LSPs are LSPs for 118 each of the specific hosts covered by that prefix. This is 119 accomplished by defining two new FECs, the Aggregate FEC and the De- 120 aggregation FEC. 122 The Aggregate FEC is exactly like the Prefix FEC as far as routing is 123 concerned. An Aggregate FEC differs in that at the end of the LSP, 124 it forms the context for interpreting the next label which is bound 125 to a De-aggregation FEC. In that regard, an aggregate LSP never uses 126 penultimate-hop popping. Further, to ensure that an LSP exists all 127 the way to an LSR capable of de-aggregating the FEC, labels bound to 128 these FECs are always distributed in ordered mode. 130 A De-aggregation FEC represents a specific host route. It is exactly 131 the same as a Host Address FEC except that labels bound to these FECs 132 are not distributed in LDP. Instead, the label value bound to a 133 particular host is algorithmically derived from the host address and 134 the prefix length of the aggregate FEC using a simple algorithm 135 described in section 4 below. 137 The use of these FECs is illustrated in the example below. 139 2.1. Inter-area LSP Construction 141 To illustrate the construction of inter-area LSPs consider the 142 following simple topology with one backbone area and two stub areas. 143 Using the mechanisms described within this document, we describe an 144 LSP is built from ingress PE4 to egress PE1 with traffic destined to 145 192.169.0.22/32 in VPN_1: 147 Area 0 148 +----------------+ 149 Area 1 | | Area 2 150 +----------+ +----------+ 151 | | | | 152 | | | +-----+ VPN_1 153 | | | | PE1 |------192.169.0.22 154 | | | +-----+ 155 | | | | 10.10.2.1 156 | | | | 157 +-----+ +------+ +------+ +-----+ 158 | PE4 | | ABR1 | | ABR2 | | PE2 | 159 +-----+ +------+ +------+ +-----+ 160 | | | | 10.10.2.2 161 | | | | 162 | | | +-----+ 163 | | | | PE3 | 164 | | | +-----+ 165 | | | | 10.10.2.3 166 +----------+ +----------+ 167 | | 168 +----------------+ 170 Figure 1: Example network 172 All routers are MPLS enabled and MPLS connectivity is required 173 between all PE routers to facilitate edge services. 175 In the egress area (area 2), the records available are: 177 RIB LIB 178 10.10.2.1/32 Labels bound to: 10.10.2.1/32 179 10.10.2.2/32 10.10.2.2/32 180 10.10.2.3/32 10.10.2.3/32 182 The area border router ABR2 advertises in the backbone area: 184 - the IP prefix 10.10.2/24 (which covers all available 185 PE routers in area 2) in the IGP 187 - a label (say 51) bound to the Aggregate FEC 10.10.2/24 188 in LDP to its neighbors in area 0. 190 ABR2 algorithmically creates a label entry for each host route 191 covered by the summary 10.10.2/24 (see section 4). It then creates 192 NHLFEs for each of these binding them to the next-hop labels it 193 received for each of the specific routes. 195 In the backbone (area 0), the records available are: 197 RIB LIB 198 10.10.2/24 Labels bound to: 10.10.2/24 200 The area border router ABR1 receives the route 10.10.2/24 via the IGP 201 and labels from its neighbors in area 0 bound to the Aggregate FEC 202 10.10.2/24 {22} via LDP from the next-hop router towards the route 203 10.10.2/24. It redistributes both the route and a label bound to the 204 FEC into area 1. 206 The routers in area 1, including PE4, receive the route 10.10.2/24 207 via the IGP and and labels from their neighbors bound to the 208 Aggregate FEC 10.10.2/24 via LDP. 210 In the ingress area (area 1), the records available are: 212 RIB LIB 213 10.10.2/24 Labels bound to: 10.10.2/24 215 2.2. Label forwarding operation 217 Using the information presented in the previous section, the label 218 forwarding from ingress PE4 to egress PE1 is as follows: 220 PE4 has a VPN destination 192.169.0.22/32 reachable via remote PE1 221 whose next-hop is 10.10.2.1/32 which is bound to say 47. PE4 only 222 has a summary route 10.10.2/24 covering the more specific next-hop 223 10.10.2.1/32, but has label bindings for that aggregate FEC. Using 224 the same algorithm as the egress ABR2, PE4 determines that the de- 225 aggregation label for PE1 is 17. PE1 creates a VRF entry for 226 192.169.0.22/32 which includes a three label stack consisting of its 227 next-hop label for 10.10.2/24, say 22, stacked upon the de- 228 aggregation label (17) stacked upon the VPN label (47). 230 Thus to forward a packet 192.169.0.22/32 in VPN_1, PE4 pushes on a 231 label stack {22, 17, 47}. This is forwarded via normal label- 232 switching to ABR2 where it arrives with the label stack {51, 17, 47}. 233 ABR2 recognizes label 51 as context label and pops it. It then looks 234 up label 17 in the context associated 51. ABR2 then pushes onto the 235 label stack the LDP derived label for the local PE. Forwarding 236 continues at this point as per normal RFC4364 procedures. 238 3. Aggregate FEC 240 A FEC TLV is defined in [LDP] section 3.4.1. This TLV serves as a 241 container for FEC Elements. To enable distribution of the Aggregate 242 FEC, we define a new FEC Element. 244 3.1. Aggregate FEC Element 246 Aggregate FEC Element value encoding: 248 0 1 2 3 249 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | FEC Type (TBD)| Address Family | PreLen | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Prefix | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Address Family 258 Two octet quantity containing a value from ADDRESS FAMILY 259 NUMBERS in [RFC1700] that encodes the address family for the 260 address prefix in the Prefix field. 262 PreLen 264 One octet unsigned integer containing the length in bits of 265 the address prefix that follows. A length of zero indicates 266 a prefix that matches all addresses (the default 267 destination); in this case the Prefix itself is zero octets). 269 Prefix 271 An address prefix encoded according to the Address 272 Family field, whose length, in bits, was specified in the 273 PreLen field, padded to a byte boundary. 275 3.2. Label distribution procedures 277 LSRs MUST NOT assign a NULL label value to an Aggregate FEC. 279 4. Algorithmically derived de-aggregation label 281 In order to avoid having to distribute de-aggregation labels, they 282 are algorithmically derived from the host address with the following 283 procedure: 285 The network mask is inverted and applied to mask off the 286 high-order bits of the address. The remaining bits are treated 287 as an integer to which 16 is added. This value represented as a 288 20-bit integer becomes the label value. 290 The value 16 is added in the algorithm in order to bypass the 291 reserved label range. 293 Issue: This algorithm may not be appropriate for IPv6. 295 5. Security Considerations 297 [to be written] 299 6. IANA Considerations 301 [to be written] 303 7. References 305 7.1. Normative References 307 [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, 308 January 2001. 310 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 7.2. Informative References 315 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual 316 Private Networks (VPNs)", RFC 4364, February 2006. 318 8. Authors' Addresses 320 George Swallow 321 Cisco Systems, Inc. 322 1414 Massachusetts Ave. 323 Boxborough, MA 01719 325 Email: swallow@cisco.com 327 Jim Guichard 328 Cisco Systems, Inc. 329 1414 Massachusetts Ave 330 Boxborough, MA 01719 332 Email: jguichar@cisco.com 334 Intellectual Property 336 The IETF takes no position regarding the validity or scope of any 337 Intellectual Property Rights or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; nor does it represent that it has 341 made any independent effort to identify any such rights. Information 342 on the procedures with respect to rights in RFC documents can be 343 found in BCP 78 and BCP 79. 345 Copies of IPR disclosures made to the IETF Secretariat and any 346 assurances of licenses to be made available, or the result of an 347 attempt made to obtain a general license or permission for the use of 348 such proprietary rights by implementers or users of this 349 specification can be obtained from the IETF on-line IPR repository at 350 http://www.ietf.org/ipr. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 this standard. Please address the information to the IETF at ietf- 356 ipr@ietf.org. 358 Full Copyright Notice 360 Copyright (C) The IETF Trust (2008). This document is subject to the 361 rights, licenses and restrictions contained in BCP 78, and except as 362 set forth therein, the authors retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.