idnits 2.17.1 draft-vkompella-l2vpn-rvpls-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. 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 1 longer page, the longest (page 10) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 (February 2008) is 5913 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) == Outdated reference: A later version (-04) exists of draft-ietf-mpls-ldp-capabilities-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Document Vach Kompella 3 Category: Standards Track Joe Regan 4 Expires: August 2008 Ron Haberman 5 Alcatel-Lucent 7 Shane Amante 8 Level 3 Communications 10 February 2008 12 Regional VPLS 13 draft-vkompella-l2vpn-rvpls-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 21, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This draft proposes an alternative signaling approach that 49 improves the scaling of HVPLS, which is compatible with the 50 basic HVPLS model. It reduces the learning requirements on the 51 PE, for certain topologies. 53 1. Introduction 55 In this draft, we present an extension to HVPLS signaling that 56 addresses the scalability issues arising when inter-regional 57 VPLS's are connected. 59 [VPLS] defines how a hierarchical VPLS (H-VPLS) can be 60 established in a single region or administrative domain. As the 61 reach of a VPLS increases, a PE in the core of a flat VPLS can 62 experience scaling issues in multiple dimensions: provisioning, 63 signaling, flooding/replication, MAC addresses. An H-VPLS can 64 alleviate the issues of provisioning, signaling and 65 flooding/replication. This comes at the expense of an increased 66 number of MAC addresses learned at an interior H-VPLS PE. 68 This draft proposes an approach that builds on [VPLS] to create 69 a scalable inter-region VPLS. In order to achieve MAC address 70 scalability, a gateway PE treats an entire region as a single 71 PE. There is no visibility of MAC addresses beyond the gateway 72 PE of another region. Instead, in an R-VPLS, the gateway PE 73 will need to learn only the source MAC addresses of all locally 74 originated customer packets which pass through the gateway PE. 75 The scalability of the solution depends on the topology and 76 distribution of MAC addresses. 78 2. The Scalability Issues 80 Consider the following network model: 82 ----- /---\ /---\ ----- 83 |PE1|--/ \ / \--|PE3| 84 ----- / \ ------ ------- ------ / \ ----- 85 |Region | |RPE | / \ |RPE | | Region| 86 | A |--| A |--( Core )--| B |--| B | 87 ----- \ / ------ ------- ------ \ / ----- 88 |PE2|--\ / | \ /--|PE4| 89 ----- \---/ ------- \---/ ----- 90 |RPE-C| 91 ------- 92 | 93 -------- 94 ----- / \ ----- 95 |PE5|---| Region C|---|PE6| 96 ----- \ / ----- 97 -------- 99 Figure 1: An R-VPLS with three regions 101 There are three regions A, B and C. In each region, a local 102 VPLS instance is requested at each of PE1 through PE6, to which 103 the customer attaches. The go through regional PEs (RPEs) 104 which, in the conventional VPLS/MS-PW solutions below, would 105 have just the properties of supporting PW cross-connects or 106 HVPLS. However, in Section 3, the RPE is a regional PE 107 supporting a modified forwarding and control plane behavior. 109 2.1. Full mesh VPLS 111 The first option for constructing this would be a full-mesh VPLS 112 between the 6 nodes. That would be inefficient in several ways. 113 Firstly, there are five sessions out of each PE. Secondly, when 114 packets are flooded, multiple copies go through the regional PEs 115 (RPEs). This is just the consequence of the topology of the 116 network. However, the PEs are the only ones involved in the 117 VPLS, and therefore, the only ones learning MAC addresses. This 118 is the minimum set of nodes that would have to learn MAC 119 addresses. The configuration overhead issue of adding another 120 node to the VPLS involves touching the configuration on all the 121 other members of the VPLS. (Auto-discovery [BGP-AD] does 122 address this problem). 124 2.2. Hierarchical VPLS 126 The second option would be to set up an H-VPLS, with PE1 and PE2 127 as spokes to RPE-A, PE3 and PE4 as spokes to RPE-B, and PE5 and 128 PE6 as spokes to RPE-C. RPE-A, RPE-B and RPE-C are configured 129 as the full-mesh VPLS. This option will reduce the number of 130 sessions out of each PE, so no node has more than four sessions. 131 The number of packets replicated at each service-aware node is a 132 maximum of three. Configuration impacts are fairly minimal when 133 adding another PE to a region because all that has to be 134 configured is a spoke from the new PE to the regional PE. 135 However, the MAC addresses are learned at the R-PEs as well as 136 at the PEs. This introduces a new scaling problem, over the 137 ones that are solved by introducing the hierarchy. Furthermore, 138 PE1 has to hairpin through RPE-A to get to PE2 in the same 139 region. 141 2.3. Multi-VPLS with multiple split horizon groups 143 A third option would be to set up a local VPLS in each region 144 between the PEs and the regional RPE, and connect the regions 145 through a core VPLS connecting the RPEs. This would require an 146 implementation that can maintain multiple split horizon groups 147 in a single VPLS. This solution avoids the problem of hair- 148 pinning through the RPE. It still keeps the replication and 149 session counts low, but it does not address the MAC scalability 150 problem. 152 2.4. Multi-segment VPLS 154 A fourth option would be to use multi-segment PWs between PEs. 155 These MS-PWs would run through the RPEs acting as S-PEs. The 156 system would behave like a full-mesh VPLS, but the session 157 counts would stay low on the PEs, and the MAC addresses would 158 only be learned at the PEs. However, the replication issue and 159 the consequent traffic on the RPEs remain. In addition, the 160 number of labels used in this service increases. 162 3. Regional VPLS 164 The R-VPLS solution tries to combine aspects of all the above in 165 one solution. The PEs know their local RPE (perhaps through 166 extensions to the Capability FEC TLV [LDP-Cap]). The rules are 167 as follows: 169 Each PE sends a single PW label to the nodes in the region. 170 Each PE sends a PW label to its RPE for each remote RPE. 171 Each RPE sends a single PW label to each other RPE in the core. 172 Each RPE sends a PW label to each PE in its region for each RPE 173 that it talks to. 175 Let's take an example to explain the signaling that could take 176 place (this is an incomplete list of the labels exchanged, but 177 enough to explain the flow of traffic for both unknown 178 destination and known destination MACs): 180 1. PE1 sends out label 1011 to RPE-A for region B. 181 2. PE1 sends out label 1012 to RPE-A for region C. 182 3. PE1 sends out label 101 to PE2. 183 4. PE2 sends out label 1021 to RPE-A for region B. 184 5. PE2 sends out label 1022 to RPE-A for region C. 185 6. PE2 sends out label 102 to PE1. 186 7. RPE-A sends out label 1101 to PE1 for region B. 187 8. RPE-A sends out label 1102 to PE1 for region C. 188 9. RPE-A sends out label 1001 to RPE-B. 189 10. RPE-A sends out label 1002 to RPE-C. 190 11. RPE-B sends out label 2001 to RPE-A. 191 12. RPE-B sends out label 2002 to RPE-C. 192 13. RPE-C sends out label 3001 to RPE-A. 193 14. RPE-C sends out label 3002 to RPE-B. 195 15. PE3 sends out label 2031 to RPE-B for region A. 196 16. PE3 sends out label 2032 to RPE-B for region C. 197 17. PE3 sends out label 201 to PE4. 198 18. PE4 sends out label 2041 to RPE-B for region A. 199 19. PE4 sends out label 2042 to RPE-B for region C. 200 20. PE4 sends out label 102 to PE1. 201 21. RPE-B sends out label 2301 to PE3 for region A. 202 22. RPE-B sends out label 2302 to PE3 for region C. 204 Assume that a CE with MAC address M1 is connected to PE1 and 205 wishes to send data to a CE with MAC address M2 that is 206 connected to PE3. The data flows as follows: 208 1. PE1 looks up M2 in its VSI, and doesn't find a match. 209 2. PE1 floods the packet with label 101 to PE2. 210 3. PE1 floods the packet to the other regions through RPE-A 211 by sending two copies of the packet, with labels 1101 and 212 1102. 213 4. RPE-A learns M1 is at PE1. 214 5. RPE-A has a PW cross-connect to send packets labeled with 215 1101 to RPE-B with label 2001. 216 6. RPE-A has a PW cross-connect to send packets labeled with 217 1102 to RPE-C with label 3001. 218 7. RPE-B looks in its VSI for M2. Since it doesn't find it, 219 it replicates the packet to PE3 with label 2031 since the 220 packet came from region A. 221 8. RPE-B also replicates the packet to PE4 with label 2041. 222 9. PE3 learns that M1 is in region A. 223 10. PE3 sends the packet to M2. 224 11. Eventually, M2 responds, sending a packet back to M1 225 through P3. 226 12. PE3 knows that M1 is in region A, so it sends RPE-B the 227 packet labeled with 2301. 228 13. RPE-B learns M2 is at PE3. 229 14. RPE-B has a PW cross-connect to send packets labeled with 230 2301 to RPE-A with label 1001. 231 15. RPE-A looks up M1 in its VSI, and knows that the packet 232 belongs to PE1, and labels it with 1011 to inform PE1 that 233 this packet originated in region B. 234 16. PE1 learns that M2 is in region B. 235 17. Learning is now complete, and unicast flows can now take 236 place. 237 18. PE1 uses its VSI to figure that M2 is in region B, and 238 sends packets to RPE-A using label 1101. 239 19. RPE-A cross-connects 1101 to RPE-B with label 2001. 240 20. RPE-B looks up M2 in its VSI and sends the packet to PE2. 242 3.1. How to interpret an R-VPLS 244 There are two aspects to the operation of an R-VPLS. One aspect 245 is the forwarding: the PE effectively learns the destination 246 region in its learning process. In that sense, the forwarding 247 process of learning and the construction of the forwarding 248 database are identical with a conventional VPLS. 250 At the RPE, when receiving a packet from the local region, the 251 forwarding is modeled like a multi-segment PW to the remote RPE. 252 The remote RPE uses its VSI to forward to its local PEs. 254 The second aspect is where the learning is done. The learning 255 has to be done in the PEs. The RPEs also perform learning, but 256 only when packets arrive from their local region, so that they 257 only learn local MAC addresses, i.e., source MAC addresses 258 originating within their region. 260 3.2. Protocol Format 262 The signaling between PE and RPE is a FEC with the conventional 263 VPLS identification augmented with a region ID, which we call an 264 Augmented PW FEC. The signaling between PEs in a region and 265 between RPEs remains the conventional VPLS FEC. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | A-PW FEC TLV |C| PW Type | PW info Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Group ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | PW ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Region ID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Optional parameters | 279 | " | 280 | " | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Region ID. 284 The router ID or loopback address of the remote RPE. For 285 signaling the F-label, the A-PW FEC is used, but the region ID 286 is set to the local RPE's router ID. 288 3.3. Optimized Regional Flooding 290 It is possible to eliminate replication to multiple regions if 291 we use a special region flooding label from the local PE to the 292 local RPE. The local RPE signals a label per remote region, 293 which is used for unicast forwarding. However, it signals a 294 special F-label for use in optimized flooding, using the A-PW 295 FEC, with its own router ID as the region ID. 297 3.4. Packet processing details 299 The following describes the processing of a packet in the 300 forwarding plane at each service-aware node (PE and RPE). 302 3.4.1. Packet from customer to PE 304 When a PE receives a packet from the customer, it learns the 305 source MAC address. Then depending on whether it knows the 306 region of the destination MAC or not, it takes the following 307 actions. 309 3.4.1.1. Destination MAC unknown 311 When a PE receives a packet from the customer and doesn't know 312 the destination region, it replicates the packet with the region 313 PW label for each region to the local RPE. 315 Alternatively, if the local PE has an F-label from its local 316 RPE, it will send only one copy of the packet to the local RPE 317 with the F-label. 319 Finally, the local PE will replicate packets to each PE in the 320 region, using the PW label received from them. 322 3.4.1.2. Destination MAC known 324 When a PE receives a packet from the customer and has an entry 325 in its VSI, it forwards the packet to the PW endpoint, with the 326 appropriate PW label. This could be either to the local RPE, 327 using the region label for the destination region that the MAC 328 resides in, or to a local PE within the region, using its PW 329 label. 331 3.4.2. Packet from PE to local RPE 332 When the local RPE receives a packet from the local PE, it 333 learns the location of the source MAC against that PE. Then 334 depending on the label received, it takes one of two actions. 336 If the received label was a remote region label, then the 337 forwarding plane already has a PW cross-connect with the remote 338 RPE and outgoing label. In case the PE is not using an F-label, 339 and it needs to flood the packet, the RPE sees the flood as a 340 set of unicasts, and no particular action has to be taken other 341 than MS-PW style forwarding. 343 If the PE is flooding the packet using the F-label, then the RPE 344 needs to replicate the incoming F-label to the appropriate label 345 towards each remote RPE. 347 3.4.3. Packet from RPE to RPE 349 When a packet is received from another RPE, no MAC learning 350 needs to be performed. Based on whether the RPE knows where the 351 destination MAC or not, it takes the following action. 353 3.4.4. Destination MAC unknown 355 When a packet is received from a remote RPE, if the destination 356 MAC is unknown, the packet is flooded to each PE with the 357 appropriate region label that identifies which region the packet 358 originated. 360 3.4.5. Destination MAC known 362 When a packet is received from a remote RPE, if the destination 363 MAC is known, the packet is sent to the destination PE with the 364 appropriate region label that identifies which region the packet 365 originated. 367 3.4.6. Packet from RPE to PE 369 When a packet is received at a PE from its local RPE, the PE 370 associates the source MAC with the region it originated from 371 (which it can tell from the region label used). The packet is 372 then forwarded according to whether the destination MAC address 373 is known or not. 375 3.4.6.1. Destination MAC unknown 376 When a packet is received from the local RPE, if the destination 377 MAC is unknown, the packet is flooded on all attachment circuits 378 belonging to the VPLS. 380 3.4.6.2. Destination MAC known 382 When a packet is received from the local RPE, if the destination 383 MAC is known, the packet is sent to the appropriate attachment 384 circuit. 386 3.5. Improvements for later consideration 388 There are a number of questions that have already risen 389 regarding. These will be dealt with either in this draft or in 390 follow-on drafts: 392 - scalability comparisons between the solutions in Section 2 393 - dual homing/redundancy of RPEs 394 - cascading regions 395 - discovery of regions and RPEs 397 4. References 399 Normative References 401 [VPLS] "Virtual Private LAN Service (VPLS) Using Label 402 Distribution Protocol (LDP) Signaling," M. Lasserre et al, RFC 403 4762, January 2007. 405 [BGP-AD] "Virtual Private LAN Service (VPLS) Using BGP for Auto- 406 Discovery and Signaling," K. Kompella et al, RFC 4761, January 407 2007. 409 Informative References 411 [LDP-Cap] "LDP Capabilities," R. Thomas et al, draft-ietf-mpls- 412 ldp-capabilities-01.txt, work in progress, February 2008. 414 5. Security Considerations 416 No new security issues arise out of the extensions proposed here 417 than exist in the base VPLS standards. 419 6. IANA Considerations 420 No IANA allocations have been specified yet (but a new FEC type 421 will be forthcoming, as well as changes to the LDP Capability 422 FEC TLV). 424 7. Authors' Addresses 426 Vach Kompella 427 Alcatel-Lucent 428 vach.kompella@alcatel-lucent.com 430 Joe Regan 431 Alcatel-Lucent 432 joe.regan@alcatel-lucent.com 434 Ron Haberman 435 Alcatel-Lucent 436 ron.haberman@alcatel-lucent.com 438 Shane Amante 439 Level 3 Communications 440 shane@castlepoint.net 442 8. Full Copyright Statement 444 Copyright (C) The IETF Trust (2008). 446 This document is subject to the rights, licenses and 447 restrictions contained in BCP 78, and except as set forth 448 therein, the authors retain all their rights. 450 This document and the information contained herein are provided 451 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 452 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 453 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 454 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 455 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 456 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 457 OR FITNESS FOR A PARTICULAR PURPOSE. 459 9. Intellectual Property 461 The IETF takes no position regarding the validity or scope of 462 any Intellectual Property Rights or other rights that might be 463 claimed to pertain to the implementation or use of the 464 technology described in this document or the extent to which any 465 license under such rights might or might not be available; nor 466 does it represent that it has made any independent effort to 467 identify any such rights. Information on the procedures with 468 respect to rights in RFC documents can be found in BCP 78 and 469 BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the 474 use of such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR 476 repository at http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention 479 any copyrights, patents or patent applications, or other 480 proprietary rights that may cover technology that may be 481 required to implement this standard. Please address the 482 information to the IETF at ietf-ipr@ietf.org. 484 10. Acknowledgments 486 Funding for the RFC Editor function is provided by the IETF 487 Administrative Support Activity (IASA).