idnits 2.17.1 draft-yong-trill-trill-o-mpls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2012) is 4423 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-ldp-vpls-broadcast-exten-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Lucy Yong 2 INTERNET-DRAFT Donald Eastlake 3 Intended status: Informational Sam Aldrin 4 Huawei R&D USA 5 Jon Hudson 6 Brocade 7 Expires: September 9, 2012 March 10, 2012 9 Transparent Interconnection of Lots of Links (TRILL) over 10 MPLS Pseudo Wires 11 13 Abstract 15 This informational document describes ways to interconnect TRILL 16 RBridges by using MPLS Pseudo Wire (PW) services with existing TRILL 17 and MPLS standards so as to form a unified TRILL campus. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the TRILL working group mailing list . 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Table of Contents 45 1. Introduction............................................3 46 1.1 Conventions used in this document......................3 48 2. Use Cases...............................................4 49 2.1 Point-To-Point Interconnection.........................4 50 2.1.1 Direct Point-to-Point................................5 51 2.1.2 Provider Point-to-Point Service......................5 52 2.2 Multi-Access Link Interconnection......................6 54 3. RBridge Behavior for MPLS Pseudo Wire...................9 56 4. IANA Considerations....................................10 57 5. Security Considerations................................10 58 6. Acknowledgements.......................................10 59 7. Normative References...................................11 60 8. Informative References.................................12 62 1. Introduction 64 The IETF TRILL (Transparent Interconnection of Lots of Links) 65 standard [RFC6325] [RFC6326] provides optimal pair-wise data frame 66 forwarding without configuration in multi-hop networks with arbitrary 67 topology and link technology, and supports multipathing of both 68 unicast and multicast traffic. TRILL enables a new method to 69 construct a campus or data center network. Devices that implement 70 TRILL are called RBridges (Routing Bridges) or TRILL Switches. 72 This document describes the use of MPLS Pseudo Wire or VPLS links by 73 TRILL. 75 1.1 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 Acronyms used in this document include the following: 83 AC - Attachment Circuit 85 IS-IS - Intermediate System to Intermediate System 87 MPLS - Multi-Protocol Label Switching 89 PE - Provider Edge 91 PPP - Point-to-Point Protocol 93 PW - Pseudo Wire 95 QoS - Quality of Service 97 RB - RBridge 99 RBridge - Routing Bridge 101 TRILL - Transparent Interconnection of Lots of Links 103 TRILL Switch - An alternative term for an RBridge 105 VPLS - Virtual Private LAN Service 107 VSI - Virtual Service Instance 109 2. Use Cases 111 TRILL campuses at different locations may interconnect by networks 112 that are implemented with different technologies to form a unified 113 RBridge campus. This section describes use cases assuming that 114 IP/MPLS technology is available. From the MPLS network view, a pair 115 of RBridges can be directly connected with a pseudo wire or an 116 RBridge can act as a Customer Edge device that connects to a Provider 117 Edge device via an attachment circuit. RBridge ports [RFC6325], by 118 default, support both point-to-point links and multi-access links. 120 Section 2.1 describes point-to-point links, i.e. TRILL over an 121 Ethernet or PPP point-to-point link that is over an MPLS network. 122 Section 2.2 describes TRILL over a bridged LAN or equivalent that is 123 implemented by MPLS/VPLS. 125 2.1 Point-To-Point Interconnection 127 Either an Ethernet or PPP link over an MPLS network interconnets two 128 RBridge ports. This can be either a direct pseudo wire between the 129 RBridges or by attachment circuits from each RBridge port to Provider 130 Edge devices that provide a transparent tunnel between the provider 131 edge attachment points. 133 MPLS already supports many pseudo wire transport encapsulations 134 [RFC4446]. Two types of TRILL links between RBridges have been 135 standardized are Ethernet [RFC6325] and PPP [RFC6361]. Pseudo wire 136 encapsulations for these two interfaces are specified in [RFC4448] 137 and [RFC4618], respectively. 139 The method described in 2.1.1 below is typically suitable when the 140 TRILL and MPLS facilities have common management while the method 141 described in 2.1.2 is typically suittable when the TRILL and MPLS 142 facilities are separately managed. In the case of different 143 management, the core MPLS operator can sell a VPWS service to an 144 RBridge operator. 146 In both cases, the MPLS label switched routers involved need no 147 awareness of TRILL. 149 A pseudo wire may cross multiple MPLS domains [RFC5659]. In these 150 cases, RBridges may be considered to connect to T-PEs and it works in 151 the same way as a single domain. The MPLS network can provide 152 transport resiliency for a pseudo wire. The dual homing (two 153 attachment circuits) can be used for attachment circuit protection. 154 In this case, two TRILL links are established; RBridges can perform 155 load balancing over two links. 157 2.1.1 Direct Point-to-Point 159 Two RBridge ports can be connected directly by an MPLS pseudo wire. 160 This implies that the RBridges, which are TRILL routers, are also 161 acting as label switched routers. The pseudo wire can be either 162 Ethernet over MPLS or PPP over MPLS but PPP over MPLS is recommended 163 because it saves 16 bytes per frame. The pseudo wire between two 164 RBridge ports can be auto-configured [RFC4447] or manually 165 configured; the two RBridges then appear directly interconnected with 166 a transparent link. 168 (Technically speaking, it is possible to create a specially 169 designated TRILL encapsulated pseudo wire for point-to-point TRILL 170 over MPLS. However, the authors think that this is not worth the 171 effort in this case because of available technologies, particularly 172 the highly-efficient PPP link technology.) 174 From a customer/provider point of view, this can also be though of as 175 shown in the following diagram: 177 *---------* *---------* 178 | TRILL |<---- TRILL Link------->| TRILL | 179 | Site A | (Customer Layer) | Site B | 180 | | | | 181 | +-------+ +---+ +-------+ | 182 | | RB/PE |-----| P |------| PE/RB | | 183 | +-------+ +---+ +-------+ | 184 | |<---------PW ---------->| | 185 | | (Provider Layer) | | 186 *---------* *---------* 187 { MPLS Network } 189 { One RBridge Campus } 191 The interworking between the RBridge network and the MPLS network is 192 within the combined TRILL/MPLS device. This has a similar 193 architecture to MPLS/VPLS [RFC4762]. 195 2.1.2 Provider Point-to-Point Service 197 Two RBridge ports may also be connected by attachment circuits (ACs) 198 to Provider Edge (PE) devices that are part of a typically separately 199 managed provider network. The provider network then provides a 200 transparent path between these attachment circuits, connecting the 201 RBridge ports. The following diagram illustrates this arrangement: 203 <-------------TRILL Link------------> 204 *--------* <----------PW----------> *--------* 205 | TRILL | | TRILL | 206 | Site A | | Site B | 207 | +--+ AC +----+ +---+ +----+ AC +--+ | 208 | |RB|------| PE |---| P |---| PE |------|RB| | 209 | +--+ +----+ +---+ +----+ +--+ | 210 | | { Provider Network } | | 211 *--------* *--------* 212 { One RBridge Campus } 214 If the attachment circuits are Ethernet, the two PEs would be 215 configured to form a pseudo wire with Ethernet encapsulation 216 [RFC4448]. This pseudo wire can be auto-configured [RFC4447] or 217 manually configured; the two RBridges then appear directly 218 interconnected with an Ethernet link. The provider edge devices 219 SHOULD use the Raw mode and non-service-delimiting, which provides a 220 transparent Ethernet transport. 222 If the attachment circuits are PPP link type, the two PEs must be 223 configured to form a PW with PPP encapsulation [RFC4618]. After the 224 pseudo wire is established between two PEs, the two RBridges then 225 appear directly connected with a PPP link. The PPP link configuration 226 will be more efficient than the Ethernet point-to-point 227 configuration; it saves about 16 bytes per frame by replacing the 228 TRILL Outer.MacDA, Outer.MacSA, Outer.VLAN, and outer Ethertype with 229 a PPP code point [RFC6361]. 231 In both case, the pseudo wire provides transparent transport between 232 attachment circuits. The TRILL link and the connectivity over that 233 link is automatically discovered and established through TRILL IS-IS 234 control messages. 236 2.2 Multi-Access Link Interconnection 238 Multiple RBridges may interconnect via an [802.1Q] Bridged LAN that 239 acts as a hub. The bridged LAN simply forwards on the outer Ethernet 240 header of the TRILL over Ethernet frames. This configuration creates 241 what appears to each connected RBridge as a multi-access link. In 242 other words, each RBridge connecting to a bridged LAN normally has 243 connectivity to every other RBridge connecting to the same bridged 244 LAN. 246 MPLS/VPLS can provide the same capability when multiple parts of an 247 RBridge campus are interconnected over an IP/MPLS network and make 248 each RBridge attaching to the VPLS appear as having a multi-access 249 TRILL link. The diagram below shows one RBridge campus is split 250 between three different sites and the use of MPLS/VPLS for RBridge 251 interconnection. Ethernet attachment circuits and pseudo wires are 252 assumed. 254 *-------* ........................... *-------* 255 | | . MPLS/VPLS . | | 256 | TRILL |AC +----+ PW +----+ AC| TRILL | 257 | Site 1+---|VSI ********************** VSI|---+ Site 2| 258 | | | PE ***** ***** PE | | | 259 | | +----+ **** **** +----+ | | 260 | | . +*--*+ . *-------* 261 *-------* ..........|VSI |........... 262 | PE | 263 +----+ 264 |AC 265 | 266 *---------* 267 | TRILL | 268 | Site 3 | 269 | | 270 *---------* 272 One VPLS instance is configured on three Provider Edge (PE) devices 273 and the pseudo wires are configured for the VPLS instance. Each 274 RBridge Site connects to the VSI on a PE via an attachment circuit. 275 The VSI on a PE forwards TRILL frames based on the outer Ethernet 276 header of the frames [RFC6325]. Either BGP [RFC4761] or LDP [RFC4762] 277 protocol can be used to automatically construct the VPLS instance on 278 the PEs. 280 The choice of three VSIs and three singly connected sites was for 281 illustrative purposes. There could be two or more than three. 282 Furthermore, each TRILL site could have multiple connections to the 283 VPLS network and/or direct connection via other technologies or VPLS 284 networks to one or more of the other sites. TRILL sorts all this out 285 and router properly. 287 A PE may connect to several different RBridge campuses that belong to 288 different customers. Separated VPLS instances are configured for 289 individual customers and customer traffic is isolated by VPLS 290 instance. The PE treats an RBridge as a generic Ethernet customer 291 devices and has no awareness of TRILL. The outer Ethernet MAC of 292 TRILL frames may be either a next-hop RBridge MAC address (for 293 unicast frames) or one of TRILL defined multicast addresses (ALL-IS- 294 IS-RBridges and All-RBridges) [RFC6325]. The VSI at each PE learns 295 the source MAC addresses on each VSI interface and forward the frame 296 based on the destination MAC. For the multicast frames, the VSI 297 replicates the frames to all pseudo wires it associates. If a VPLS is 298 configured with some optimization capability [VPLS-BCAST], the 299 multicast frames can be delivered over a point-to-multipoint pseudo 300 wire while unicast frames are carried over a point-to-point pseudo 301 wire. 303 The scenario above can also be extended to multiple RBridge 304 interconnections when a device serves both the RBridge and PE 305 functions, similarly to the case in Section 2.1.2 and 2.1.1 above. 307 Note: If the customer devices associated with one VPLS instances 308 happen to include some RBridges and some end stations or IEEE 802.1Q 309 bridges providing paths to end stations, TRILL will, by default, be 310 able to handle this by providing both through service and end station 311 service. However, the end station addresses will be visible to the 312 VPLS instance. If, in such a case, all the RBridge ports connected to 313 the VPLS are configured as trunk ports (see Section 4.9.2 of 314 [RFC6325]), then they will not provide any end station service. 316 3. RBridge Behavior for MPLS Pseudo Wire 318 This section describes RBridge behaviors for TRILL Ethernet or TRILL 319 PPP links over MPLS pseudo wire (PW) as described in Sections 2.1. 321 1. For two RBridge ports connecting via a PPP pseudo wire, the ports 322 MUST be configured as IS-IS point-to-point because there are no 323 subnetwork point of attachment (SNPA/MAC) addresses of the end 324 points at the PPP protocol layer. Thus TRILL will use IS-IS P2P 325 Hellos that, as described in "Point-to-Point IS to IS Hello PDU" 326 (section 9.7 of [IS-IS]), do not use Neighbor TLVs or require 327 SNPAs. However, as described section 4.2.4.1 of [RFC6325], three- 328 way IS-IS handshake using extended circuit IDs is required. 330 2. Any MPLS forwarder within an MPLS label switched path does not 331 change the TRILL Header Hop Count. RBridges are not aware of the 332 packet forwarders in with the MPLS network. 334 3. If it is desired for MPLS label switched routers to perform QoS in 335 the same way as RBridges do, an Ethernet path MUST be used and 336 RBridges MUST be configured to send an Outer.VLAN tag on the 337 RBridge port leading to the pseudo wire. The PE can then copy the 338 priority value from the Outer.VLAN tag to the COS field of the 339 pseudo wire label prior to the forwarding [RFC5462]. 341 4. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of 342 [RFC6325]) are not needed on a pseudo wire link. Implementations 343 MUST NOT send MTU-probe and SHOULD NOT reply to these messages. 344 The MTU pseudo wire interface parameter SHOULD be used instead. 345 PE MUST configure the MTU size as the originating RBridges Size 346 specified in Section 4.3.1 of [RFC6325]. 348 4. IANA Considerations 350 No IANA action is required by this document. RFC Editor: Please 351 remove this section before publication. 353 5. Security Considerations 355 The IS-IS authentication mechanism [RFC5304] [RFC5310], at the TRILL 356 IS-IS layer, can be used to prevent fabrication of link-state control 357 messages over TRILL links including those discussed in this document. 359 For general TRILL protocol security considerations, see [RFC6325]. 361 Use cases in which the path between RBridges transits a provider 362 network under separate administration may represent a substantial 363 increase in the threat of observation, deletion, modification, or 364 insertion of data or control information. Under such circumstances 365 consideration should be give to the use of security at the TRILL link 366 level, such as [802.1AE] if the path between the RBridge ports is 367 Ethernet or security as suggested in [RFC6361] if that path is PPP. 369 6. Acknowledgements 371 The authors sincerely acknowledge the contributions of Ben Mack-Crane 372 and Sue Hares. 374 7. Normative References 376 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to 380 EdgeEmulation (PWE3)", BCP 116, RFC 4446, April 2006. 382 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 383 G. Heron, "Pseudowire Setup and Maintenance Using the Label 384 Distribution Protocol (LDP)", RFC 4447, April 2006. 386 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 387 "Encapsulation Methods for Transport of Ethernet over MPLS 388 Networks", RFC 4448, April 2006. 390 [RFC4618] Martini, L., "Encapsulation Methods for Transport of 391 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", 392 BCP 116, RFC 4618, September 2006. 394 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 395 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC4761, 396 January 2007. 398 [RFC4762] Lasserre, M. and Kompella, V, "Virtual Private LAN 399 Service(VPLS) Using Label Distribution Protocol (LDP) 400 Signaling",RFC4762, January 2007 402 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 403 Requirement Levels," BCP 14 and RFC 2119, March 1997 405 [RFC5304] Li, T. and Atkinson, R, "IS-IS Cryptographic 406 Authentication," RFC 5304, October 2008 408 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 409 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 410 5310, February 2009 412 [RFC5462] Andersson, L. and Asati, R., "Multiprotocol Label Switching 413 (MPLS) Label Stack entry: "Exp" Field Rename to "Traffic Class" 414 Field", RFC5462, February 2009 416 [RFC5659] Bocci, M and Bryant, S, "An Architecture for Multi-Segment 417 Pseudowire Emulation Edge-to-Edge", RFC 5659, October2009. 419 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 420 Ghanwani, "Routing Bridges (RBridges): Base Protocol 421 Specification", RFC6325, July 2011. 423 [RFC6326] Eastlake 3rd, D., Banerjee, A., Dutt, D., Perlman, R., 424 andGhanwani, A. "Transparent Interconnection of Lots of 425 Links(TRILL) Use of IS-IS", RFC6326, July 2011. 427 [RFC6361] Carlson, J., and D. Eastlake, "PPP Transparent 428 Interconnection of Lots of Links (TRILL) Protocol Control 429 Protocol", RFC6361, August 2011. 431 8. Informative References 433 [802.1AE] "IEEE Standard for Local and metropolitan area networks / 434 Media Access Control (MAC) Security", 802.1AE-2006, 18 August 435 2006. 437 [802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan area 438 networks - Virtual Bridged Local Area Networks", IEEE Std 439 802.1Q-2011, May 2011. 441 [IS-IS] International Organization for Standardization, "Intermediate 442 system to Intermediate system intra-domain routing information 443 exchange protocol for use in conjunction with the protocol for 444 providing the connectionless-mode Network Service (ISO 8473)", 445 ISO/IEC10589:2002, Second Edition, Nov 2002 447 [VPLS-BCAST] Delord, S, and Key, R., "Extension to LDP-VPLS for 448 Ethernet Broadcast and Multicast", draft-ietf-l2vpn-ldp-vpls- 449 broadcast-exten-02, work in progress, 2011. 451 Authors' Addresses 453 Lucy Yong 454 Huawei R&D USA 455 5340 Legacy Drive 456 Plano, TX 75025 458 Phone: +1-469-227-5837 459 Email: lucy.yong@huawei.com 461 Donald E. Eastlake, 3rd 462 Huawei R&D USA 463 155 Beaver Street 464 Milford, MA 01757 USA 466 Phone: +1-508-333-2270 467 Email: d3e3e3@gmail.com 469 Sam Aldrin 470 Huawei R&D USA 471 2330 Central Expressway 472 Santa Clara, CA 95050 474 Phone: +1-408-330-4517 475 Email: sam.aldrin@huawei.com 477 Jon Hudson 478 Brocade 479 130 Holger Way 480 San Jose, CA 95134 482 Phone: +1-408-333-4062 483 jon.hudson@brocade.com 485 Copyright and IPR Provisions 487 Copyright (c) 2012 IETF Trust and the persons identified as the 488 document authors. All rights reserved. 490 This document is subject to BCP 78 and the IETF Trust's Legal 491 Provisions Relating to IETF Documents 492 (http://trustee.ietf.org/license-info) in effect on the date of 493 publication of this document. Please review these documents 494 carefully, as they describe your rights and restrictions with respect 495 to this document. Code Components extracted from this document must 496 include Simplified BSD License text as described in Section 4.e of 497 the Trust Legal Provisions and are provided without warranty as 498 described in the Simplified BSD License. The definitive version of 499 an IETF Document is that published by, or under the auspices of, the 500 IETF. Versions of IETF Documents that are published by third parties, 501 including those that are translated into other languages, should not 502 be considered to be definitive versions of IETF Documents. The 503 definitive version of these Legal Provisions is that published by, or 504 under the auspices of, the IETF. Versions of these Legal Provisions 505 that are published by third parties, including those that are 506 translated into other languages, should not be considered to be 507 definitive versions of these Legal Provisions. For the avoidance of 508 doubt, each Contributor to the IETF Standards Process licenses each 509 Contribution that he or she makes as part of the IETF Standards 510 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 511 language to the contrary, or terms, conditions or rights that differ 512 from or are inconsistent with the rights and licenses granted under 513 RFC 5378, shall have any effect and shall be null and void, whether 514 published or posted by such Contributor, or included with or in such 515 Contribution.