idnits 2.17.1 draft-swallow-mpls-aggregated-fec-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 352. 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 14 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 2007) is 6129 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 253, but not defined ** Obsolete undefined reference: RFC 1700 (Obsoleted by RFC 3232) == Unused Reference: 'RFC4364' is defined on line 311, 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 2008 6 Jim Guichard 7 Cisco Systems, Inc. 9 July 2007 11 Network Scaling with Aggregated IP LSPs 13 draft-swallow-mpls-aggregated-fec-00.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 Aggregated-prefix FEC ..................................... 7 54 3.1 Aggregated-prefix 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 82 Aggregated-prefix Forwarding Equivalence Class (FEC) and an 83 algorithmically derived label per aggregated host route which stacked 84 together form end-to-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 The basic idea is to use prefix LSP to deliver MPLS packets from the 109 ingress LSR to the ABRs serving the egress LSRs. Nested within these 110 LSPs are LSPs for each of the specific hosts covered by that prefix. 111 This is accomplished by defining two new FECs, the Aggregated-prefix 112 FEC and the De-aggregation FEC. 114 The Aggregated-prefix FEC is exactly like the Prefix FEC as far as 115 routing is concerned. An Aggregated Prefix FEC differs in that at 116 the end of the LSP, it forms the context for interpreting the next 117 label which is bound to a De-aggregation FEC. In that regard, an 118 aggregated-prefix LSP never uses penultimate-hop popping. Further, 119 to ensure that an LSP exists all the way to an LSR capable of de- 120 aggregating the FEC, labels bound to these FECs are always 121 distributed in ordered mode. 123 A De-aggregation FEC represents a specific host route. It is exactly 124 the same as a Host Address FEC except that labels bound to these FECs 125 are not distributed in LDP. Instead, the label value bound to a 126 particular host is algorithmically derived from the host address and 127 the aggregated prefix using a simple algorithm described in section 4 128 below. 130 The use of these FECs is illustrated in the example below. 132 2.1. Inter-area LSP Construction 134 To illustrate the construction of inter-area LSPs consider the 135 following simple topology with one backbone area and two stub areas. 136 Using the mechanisms described within this document, we describe an 137 LSP is built from ingress PE4 to egress PE1 with traffic destined to 138 192.169.0.22/32 in VPN_1: 140 Area 0 141 +----------------+ 142 Area 1 | | Area 2 143 +----------+ +----------+ 144 | | | | 145 | | | +-----+ VPN_1 146 | | | | PE1 |------192.169.0.22 147 | | | +-----+ 148 | | | | 10.10.2.1 149 | | | | 150 +-----+ +------+ +------+ +-----+ 151 | PE4 | | ABR1 | | ABR2 | | PE2 | 152 +-----+ +------+ +------+ +-----+ 153 | | | | 10.10.2.2 154 | | | | 155 | | | +-----+ 156 | | | | PE3 | 157 | | | +-----+ 158 | | | | 10.10.2.3 159 +----------+ +----------+ 160 | | 161 +----------------+ 163 Figure 1: Example network 165 All routers are MPLS enabled and MPLS connectivity is required 166 between all PE routers to facilitate edge services. 168 In the egress area (area 2), the records available are: 170 RIB LIB 171 10.10.2.1/32 Labels bound to: 10.10.2.1/32 172 10.10.2.2/32 10.10.2.2/32 173 10.10.2.3/32 10.10.2.3/32 175 The area border router ABR2 advertises in the backbone area: 177 - the aggregated IP prefix 10.10.2/24 (which covers all 178 available 179 PE routers in area 2) in the IGP 181 - a label (say 51) bound to the Aggregated-prefix FEC 10.10.2/24 182 in LDP to its neighbors in area 0. 184 ABR2 algorithmically creates a label entry for each host route 185 covered by the summary 10.10.2/24 (see section 4). It then creates 186 NHLFEs for each of these binding them to the next-hop labels it 187 received for each of the specific routes. 189 In the backbone (area 0), the records available are: 191 RIB LIB 192 10.10.2.1/32 Labels bound to: 10.10.2/24 194 The area border router ABR1 receives the route 10.10.2/24 via the IGP 195 and labels from its neighbors in area 0 bound to the Aggregated- 196 prefix FEC 10.10.2/24 {22} via LDP from the next-hop router towards 197 the route 10.10.2/24. It redistributes both the route and a label 198 bound to the FEC into area 1. 200 The routers in area 1, including PE4, receive the route 10.10.2/24 201 via the IGP and and labels from their neighbors bound to the 202 Aggregated-prefix FEC 10.10.2/24 via LDP. 204 In the ingress area (area 1), the records available are: 206 RIB LIB 207 10.10.2.1/32 Labels bound to: 10.10.2/24 209 2.2. Label forwarding operation 211 Using the information presented in the previous section, the label 212 forwarding from ingress PE4 to egress PE1 is as follows: 214 PE4 has a VPN destination 192.169.0.22/32 reachable via remote PE1 215 whose next-hop is 10.10.2.1/32 which is bound to say 47. PE4 only 216 has a summary route 10.10.2/24 covering the more specific next-hop 217 10.10.2.1/32, but has label bindings for that aggregated FEC. Using 218 the same algorithm as the egress ABR2, PE4 determines that the de- 219 aggregation label for PE1 is 17. PE1 creates a VRF entry for 220 192.169.0.22/32 which includes a three label stack consisting of its 221 next-hop label for 10.10.2/24, say 22, stacked upon the de- 222 aggregation label (17) stacked upon the VPN label (47). 224 Thus to forward a packet 192.169.0.22/32 in VPN_1, PE4 pushes on a 225 label stack {22, 17, 47}. This is forwarded via normal label- 226 switching to ABR2 where it arrives with the label stack {51, 17, 47}. 227 ABR2 recognizes label 51 as context label and pops it. It then looks 228 up label 17 in the context associated 51. ABR2 then pushes onto the 229 label stack the LDP derived label for the local PE. Forwarding 230 continues at this point as per normal RFC4364 procedures. 232 3. Aggregated-prefix FEC 234 A FEC TLV is defined in [LDP] section 3.4.1. This TLV serves as a 235 container for FEC Elements. To enable distribution of the 236 Aggregated-prefix FEC, we define a new FEC Element. 238 3.1. Aggregated-prefix FEC Element 240 Aggregated-prefix FEC Element value encoding: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Prefix (TBD) | Address Family | PreLen | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Prefix | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Address Family 252 Two octet quantity containing a value from ADDRESS FAMILY 253 NUMBERS in [RFC1700] that encodes the address family for the 254 address prefix in the Prefix field. 256 PreLen 258 One octet unsigned integer containing the length in bits of 259 the address prefix that follows. A length of zero indicates 260 a prefix that matches all addresses (the default 261 destination); in this case the Prefix itself is zero octets). 263 Prefix 265 An address prefix encoded according to the Address 266 Family field, whose length, in bits, was specified in the 267 PreLen field, padded to a byte boundary. 269 3.2. Label distribution procedures 271 Labels bound to Aggregated-prefix FECs MUST be distributed in ordered 272 mode. LSRs MUST NOT assign a NULL label value to an Aggregated- 273 prefix FEC. 275 4. Algorithmically derived de-aggregation label 277 In order to avoid having to distribute de-aggregation labels, they 278 are algorithmically derived from the host address with the following 279 procedure: 281 The network mask is inverted and applied to mask off the 282 high-order bits of the address. The remaining bits are treated 283 as an integer to which 16 is added. This value represented as a 284 20-bit integer becomes the label value. 286 The value 16 is added in the algorithm in order to bypass the 287 reserved label range. 289 Issue: This algorithm may not be appropriate for IPv6. 291 5. Security Considerations 293 [to be written] 295 6. IANA Considerations 297 [to be written] 299 7. References 301 7.1. Normative References 303 [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, 304 January 2001. 306 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 7.2. Informative References 311 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual 312 Private Networks (VPNs)", RFC 4364, February 2006. 314 8. Authors' Addresses 316 George Swallow 317 Cisco Systems, Inc. 318 1414 Massachusetts Ave. 319 Boxborough, MA 01719 321 Email: swallow@cisco.com 323 Jim Guichard 324 Cisco Systems, Inc. 325 1414 Massachusetts Ave 326 Boxborough, MA 01719 328 Email: jguichar@cisco.com 330 Intellectual Property 332 The IETF takes no position regarding the validity or scope of any 333 Intellectual Property Rights or other rights that might be claimed to 334 pertain to the implementation or use of the technology described in 335 this document or the extent to which any license under such rights 336 might or might not be available; nor does it represent that it has 337 made any independent effort to identify any such rights. Information 338 on the procedures with respect to rights in RFC documents can be 339 found in BCP 78 and BCP 79. 341 Copies of IPR disclosures made to the IETF Secretariat and any 342 assurances of licenses to be made available, or the result of an 343 attempt made to obtain a general license or permission for the use of 344 such proprietary rights by implementers or users of this 345 specification can be obtained from the IETF on-line IPR repository at 346 http://www.ietf.org/ipr. 348 The IETF invites any interested party to bring to its attention any 349 copyrights, patents or patent applications, or other proprietary 350 rights that may cover technology that may be required to implement 351 this standard. Please address the information to the IETF at ietf- 352 ipr@ietf.org. 354 Full Copyright Notice 356 Copyright (C) The IETF Trust (2007). This document is subject to the 357 rights, licenses and restrictions contained in BCP 78, and except as 358 set forth therein, the authors retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.