idnits 2.17.1 draft-balaji-trill-over-ip-multi-level-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 304 has weird spacing: '...opology or (c...' == Line 384 has weird spacing: '...ustomer who i...' == Line 796 has weird spacing: '...e U-Pes conne...' == Line 851 has weird spacing: '...terface would...' -- The document date (March 4, 2012) is 4435 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: 'RFC2119' is mentioned on line 148, but not defined == Missing Reference: 'U-PEs' is mentioned on line 311, but not defined == Missing Reference: 'N-PE' is mentioned on line 406, but not defined == Missing Reference: 'U-PE' is mentioned on line 311, but not defined == Missing Reference: 'U-PEB' is mentioned on line 503, but not defined == Missing Reference: 'U-PEA' is mentioned on line 503, but not defined == Missing Reference: 'N1-PE' is mentioned on line 503, but not defined == Missing Reference: 'N2-PE' is mentioned on line 503, but not defined == Unused Reference: 'KEYWORDS' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1053, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1056, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1776 ** Downref: Normative reference to an Informational RFC: RFC 1925 (ref. 'TRUTHS') == Outdated reference: A later version (-01) exists of draft-xl-trill-over-wan-00 == Outdated reference: A later version (-10) exists of draft-perlman-trill-rbridge-multilevel-03 Summary: 3 errors (**), 0 flaws (~~), 22 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Bhargav Bhikkaji 3 Internet-draft Balaji Venkat Venkataswami 4 Intended Status: Proposed Standard Narayana Perumal Swamy 5 Expires: September 2012 DELL-Force10 6 March 4, 2012 8 Connecting Disparate Data Center/PBB/Campus TRILL sites using BGP 9 draft-balaji-trill-over-ip-multi-level-04 11 Abstract 13 There is a need to connect (a) TRILL based data centers or (b) TRILL 14 based networks which provide Provider Backbone like functionalities 15 or (c) Campus TRILL based networks over the WAN using one or more 16 ISPs that provide regular IP+GRE or IP+MPLS transport. A few 17 solutions have been proposed as in [1] in the recent past that have 18 not looked at the PB-like functionality. These solutions have not 19 dealt with the details as to how these services could be provided 20 such that multiple TRILL sites can be inter-connected with issues 21 like nick-name collisons for unicast (multicast is still TBD) being 22 taken care of. It has been found that with extensions to BGP the 23 problem statement which we will define below can be handled. Both 24 control plane and data plane operations can be driven into the 25 solution to make it seamlessly look at the entire set of TRILL sites 26 as a single entity which then can be viewed as one single Layer 2 27 cloud. MAC moves across TRILL sites and within TRILL sites can be 28 realized. This document / proposal envisions the use of BGP-MAC-VPN 29 vrfs both at the IP cloud PE devices and at the peripheral PEs within 30 a TRILL site providing Provider Backbone like functionality. We deal 31 in depth with the control plane and data plane particulars for 32 unicast (multicast is still TBD) with nick-name election being taken 33 care of as part of the solution. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as 43 Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/1id-abstracts.html 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 Copyright and License Notice 58 Copyright (c) 2012 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 75 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 77 1.2.1 TRILL Data Centers requiring connectivity over WAN . . . 5 78 1.2.2 Provider Backbone remote TRILL cloud requirements . . . 6 79 1.2.3 Campus TRILL network requirements . . . . . . . . . . . 7 80 2. Architecture where the solution applies . . . . . . . . . . . 7 81 2.1 Proposed Solution . . . . . . . . . . . . . . . . . . . . . 7 82 2.1.1 Control Plane . . . . . . . . . . . . . . . . . . . . . 8 83 2.1.1.1 Nickname Collision Solution . . . . . . . . . . . . 8 84 2.1.1.2 U-PE BGP-MAC-VPN VRFs . . . . . . . . . . . . . . . 9 85 2.1.1.3 Control Plane explained in detail. . . . . . . . . . 11 86 2.1.2 Corresponding Data plane for the above control plane 87 example. . . . . . . . . . . . . . . . . . . . . . . . . 12 88 2.1.2.1 Control plane for regular Campus and Data center 89 sites . . . . . . . . . . . . . . . . . . . . . . . 13 90 2.1.2.2 Other Data plane particulars. . . . . . . . . . . . 13 91 2.1.3 Encapsulations . . . . . . . . . . . . . . . . . . . . . 19 92 2.1.3.1 IP + GRE . . . . . . . . . . . . . . . . . . . . . . 19 93 2.1.3.2 IP + MPLS . . . . . . . . . . . . . . . . . . . . . 19 94 2.2 Other use cases . . . . . . . . . . . . . . . . . . . . . . 19 95 2.3 Novelty . . . . . . . . . . . . . . . . . . . . . . . . . . 19 96 2.4 Uniqueness and advantages . . . . . . . . . . . . . . . . . 20 97 2.4.1 Multi-level IS-IS . . . . . . . . . . . . . . . . . . . 20 98 2.5 Comparison with OTV and VPN4DC and other schemes . . . . . . 21 99 2.6 Multi-pathing . . . . . . . . . . . . . . . . . . . . . . . 21 100 2.7 TRILL extensions for BGP . . . . . . . . . . . . . . . . . . 21 101 2.7.1 Format of the MAC-VPN NLRI . . . . . . . . . . . . . . . 21 102 2.7.2. BGP MAC-VPN MAC Address Advertisement . . . . . . . . . 22 103 2.7.2.1 Next hop field in MP_REACH_NLRI . . . . . . . . . . 23 104 2.7.2.2 Route Reflectors for scaling . . . . . . . . . . . . 23 105 2.7.3 Multicast related ideas . . . . . . . . . . . . . . . . 24 106 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 25 107 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 108 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 5.1 Normative References . . . . . . . . . . . . . . . . . . . 25 110 5.2 Informative References . . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 112 A.1 Appendix I . . . . . . . . . . . . . . . . . . . . . . . . . 27 114 1 Introduction 116 There is a need to connect (a) TRILL based data centers or (b) TRILL 117 based networks which provide Provider Backbone like functionalities 118 or (c) Campus TRILL based networks over the WAN using one or more 119 ISPs that provide regular IP+GRE or IP+MPLS transport. A few 120 solutions have been proposed as in [1] in the recent past that have 121 not looked at the Provider Backbone-like functionality. These 122 solutions have not dealt with the details as to how these services 123 could be provided such that multiple TRILL sites can be inter- 124 connected with issues like nick-name collisions for unicast 125 (multicast is still TBD) being taken care of. It has been found that 126 with extensions to BGP the problem statement which we will define 127 below can be well handled. Both control plane and data plane 128 operations can be driven into the solution to make it seamlessly look 129 at the entire set of TRILL sites as a single entity which then can be 130 viewed as one single Layer 2 cloud. MAC moves across TRILL sites and 131 within TRILL sites can be realized. This document / proposal 132 envisions the use of BGP-MAC-VPN vrfs both at the IP cloud PE devices 133 and at the peripheral PEs within a TRILL site providing Provider 134 Backbone like functionality. We deal in depth with the control plane 135 and data plane particulars for unicast (multicast is still TBD) with 136 nick-name election being taken care of as part of the solution. 138 1.1 Acknowledgements 140 The authors would like to thank Janardhanan Pathangi, Anoop Ghanwani 141 for their inputs for this proposal. 143 1.2 Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 Legend : 151 U-PE : User-near PE device. U-PEs are edge devices in the Customer 152 site or tier-2 site. This is a Rbridge with BGP capabilities. It has 153 VRF instances for each tenant it is connected to in the case of 154 Provider-Backbone functionality use-case. 156 U-Ps : core devices in the Customer site that do not directly 157 interact with the Customer's Customer. 159 N-PE : Network Transport PE device. This is a device with RBridge 160 capabilities in the non-core facing side. On the core facing side it 161 is a Layer 3 device supporting IP+GRE and/or IP+MPLS. On the non-core 162 facing side it has support for VRFs one for each TRILL site that it 163 connects to. It runs BGP to convey the BGP-MAC-VPN VRF routes to its 164 peer N-PEs. It also supports IGP on the core facing side like OSPF or 165 IS-IS for Layer 3 and supports IP+GRE and/or IP+MPLS if need be. A 166 pseudo-interface representing the N-PE's connection to the Pseudo 167 Level 2 area is provided at each N-PE and a forwarding adjacency is 168 maintained between the near-end N-PE to its remote participating N- 169 PEs pseudo-interface in the common Pseudo Level 2 area. 171 N-P : Network Transport core device. This device is IP and/or 172 IP+MPLS core device that is part of the ISP / ISPs that provide the 173 transport network that connect the disparate TRILL networks together. 175 1.2 Problem Statement 177 1.2.1 TRILL Data Centers requiring connectivity over WAN 179 ____[U-PE]____ ____________ ____[U-PE]____ 180 ( ) ( ) ( ) 181 ( TRILL Based ) ( IP Core with ) ( TRILL Based ) 182 ( Data Center Site) ( IP+GRE Encap ) ( Data Center Site) 183 [U-PEs] (A) [N-PE] or IP+MPLS [N-PE] (B) [U-PE] 184 ( ) ( Encap Tunnels ) ( ) 185 ( ) ( between N-PEs) ( ) 186 (___[U-PE]_____) (____________) (____[U-PE]____) 188 Figure 1.0 : TRILL based Data Center sites inter-connectivity. 190 o Providing Layer 2 extension capabilities amongst different 191 disparate data centers running TRILL. 193 o Recognizing MAC Moves across data centers and within data centers 194 to enjoin disparate sites to look and feel as one big Layer 2 cloud. 196 o Provide a solution agnostic to the technology used in the service 197 provider network 199 o Provide a cost effective and simple solution to the above. 201 o Provide auto-configured tunnels instead of pre-configured ones in 202 the transport network. 204 o Provide additional facilities as part of the transport network for 205 eg., TE, QoS etc 207 o Routing and forwarding state is to be maintained at the network 208 edges and not within the site or the core of the transport network. 210 This requires minimization of the state explosion required to provide 211 this solution. 213 o So connectivity for end-customers is through U-PE onto N-PE onto 214 remote-N-PE and onto remote U-PE. 216 1.2.2 Provider Backbone remote TRILL cloud requirements 218 ____[U-PE]____ ____________ ____[U-PE]____ 219 ( ) ( ) ( ) 220 ( Provider ) ( IP Core with ) ( Provider ) 221 ( Backbone TRILL ) ( IP+GRE Encap ) ( Backbone TRILL ) 222 [U-PEs] Site (A) [N-PE] or IP+MPLS [N-PE] Site (B) [U-PE] 223 ( ) ( Encap Tunnels ) ( ) 224 ( ) ( Between N-PEs) ( ) 225 (___[U-PE]_____) (____________) (____[U-PE]____) 227 Figure 2.0 : TRILL based Provider backbone sites inter-connectivity 229 o Providing Layer 2 extension capabilities amongst different Provider 230 Backbone Layer 2 clouds that need connectivity with each other. 232 o Recognizing MAC Moves across Provider Backbone Layer 2 Clouds and 233 within a single site Layer 2 Cloud to enjoin disparate sites to look 234 and feel as one big Layer 2 Cloud. 236 o Provide a solution agnostic to the technology used in the service 237 provider network 239 o Provide a cost effective and simple solution to the above. 241 o Provide auto-configured tunnels instead of pre-configured ones in 242 the transport network. 244 o Provide additional facilities as part of the transport network for 245 eg., TE, QoS etc 247 o Routing and forwarding state is to be maintained at the network 248 edges and not within the site or the core of the transport network. 249 This requires minimization of the state explosion required to provide 250 this solution. 252 o These clouds could be part of the same provider but be far away 253 from each other. The customers of these clouds could demand 254 connectivity to their sites through these TRILL clouds. These TRILL 255 clouds could offer Provider Layer 2 VLAN transport for each of their 256 customers. Hence Provide a seamless connectivity wherever these sites 257 are placed. 259 o So connectivity for end-customers is through U-PE onto N-PE onto 260 remote-N-PE and onto remote U-PE. 262 1.2.3 Campus TRILL network requirements 264 ____[U-PE]____ ____________ ____[U-PE]____ 265 ( ) ( ) ( ) 266 ( Campus ) ( IP Core with ) ( Campus ) 267 ( TRILL Based ) ( IP+GRE Encap ) ( TRILL Based ) 268 [U-PEs] Site (A) [N-PE] or IP+MPLS [N-PE] Site (B) [U-PE] 269 ( ) ( Encap Tunnels ) ( ) 270 ( ) ( between N-PEs) ( ) 271 (___[U-PE]_____) (____________) (____[U-PE]____) 273 Figure 3.0 : TRILL based Campus inter-connectivity 275 o Providing Layer 2 extension capabilities amongst different 276 disparate distantly located Campus Layer 2 clouds that need 277 connectivity with each other. 279 o Recognizing MAC Moves across these Campus Layer 2 clouds and within 280 a single site Campus cloud to enjoin disparate sites to look and feel 281 as one Big Layer 2 Cloud. 283 o Provide a solution agnostic to the technology used in the service 284 provider network. 286 o Provide a cost effective and simple solution to the above. 288 o Provide auto-configured tunnels instead of pre-configured ones in 289 the transport network. 291 o Provide additional facilities as part of the transport network for 292 eg., TE, QoS etc. 294 o Routing and Forwarding state optimizations as in 1.2.1 and 1.2.2. 296 o So connectivity for end-customers is through U-PE onto N-PE onto 297 remote-N-PE and onto remote U-PE. 299 2. Architecture where the solution applies 301 2.1 Proposed Solution 303 The following section outlines (a) Campus TRILL topology or (b) TRILL 304 Data Center topology or (c) Provider backbone Network topology for 305 which solution is intended. 307 ____[U-PE]____ ____________ ____[U-PE]____ 308 ( ) ( ) ( ) 309 ( TRILL Based ) ( IP Core with ) ( TRILL Based ) 310 ( RBridges as U-PEs) ( IP+GRE Encap ) ( RBridges as U-PEs) 311 [U-PEs]RBridges as [N-PE] or IP+MPLS [N-PE] RBridges as [U-PE] 312 ( U-Ps ) ( Encap Tunnels ) ( U-Ps ) 313 ( ) ( between N-PEs) ( ) 314 (___[U-PE]_____) (____________) (____[U-PE]____) 316 Figure 4.0 : Proposed Architecture 318 2.1.1 Control Plane 320 o Site network U-PEs still adopt learning function for source MACs 321 bridged through their PE-CE links. For Campus TRILL networks (non- 322 Provider-Backbone networks) the PE-CE links connect the regular hosts 323 / servers. In the case of a data center the PE-CE links connect the 324 servers in a rack to the U-PEs / Top of Rack Switches. 326 o End customer MACs are placed in BGP-MAC-VPN VRFs in the U-PE to 327 customer PE-CE links. (at tier 2). 329 2.1.1.1 Nickname Collision Solution 331 o The near-end N-PE for a site has a forwarding adjacency for the 332 Pseudo Level 2 area Pseudo-Interface to obtain trill nicknames of the 333 next hop far-end N-PE's Level 2 Pseudo-Interface. This forwarding 334 adjacency is built up during the course of BGP-MAC-VPN exchanges 335 between the N-PEs. This forwarding adjacency is a kind of targeted 336 IS-IS adjacency through the IP+GRE or IP+MPLS core. This forwarding 337 adjacency exchange is accomplished through tweaking BGP to connect 338 the near-end N-PE with the far-end N-PEs. Nickname election is done 339 with N-PE Rbridge Pseudo-Interfaces participating in nickname 340 election in Level 2 Area and their non-core facing interfaces which 341 are Level 1 interfaces in the sites in the site considered to be a 342 Level 1 area. 344 o The Nicknames of each site are made distinct within the site since 345 the nickname election process PDUs for Level 1 area are NOT tunneled 346 across the transport network to make sure that each U-P or U-PE or N- 347 PE's Rbridge interface have knowledge of the nickname election 348 process only in their respective sites / domains. If a new domain is 349 connected as a site to an already existing network then the election 350 process NEED NOT be repeated in the newly added site in order to make 351 sure the nicknames are distinct as Multi-Level IS-IS takes care of 352 forwarding from one site / domain to another. It is only the Pseudo- 353 interface of the N-PE of the newly added site that will have to 354 partake in an election to generate a new Pseudo Level 2 area Nickname 355 for itself. 357 2.1.1.2 U-PE BGP-MAC-VPN VRFs 359 o The Customer MACs are placed as routes in the MAC-VPN VRFs with 360 Nexthops being the area number Nicknames of the U-PEs to which these 361 customer MAC addresses are connected to. For MAC routes within the 362 Level 1 area the Nicknames are those of the local U-PE itself while 363 the MAC routes learnt from other sites have the area number of the 364 site to which the remote U-PE belongs to. When the source learning 365 happens the BGP-MAC-VPN-NLRI are communicated to the participating U- 366 PEs in all the sites of the said customer. Refer to section A.1.1 in 367 Appendix A.1 for more details on how forwarding takes place between 368 the sites through the multi-level IS-IS mechanism orchestrated over 369 the IP core network. 371 Format of the BGP-MAC-VPN VRF on a U-PE 372 +---------------------+------------------------+ 373 | MAC address | U-PE Nickname | 374 +---------------------+------------------------+ 375 | 00:be:ab:ce:fg:9f | <16-bit U-PE Nickname> | 376 | (local) | | 377 +---------------------+------------------------+ 378 | 00:ce:cb:fe:fc:0f | <16-bit U-PE Area Num> | 379 | (Non-local) | | 380 +---------------------+------------------------+ 381 .... 382 .... 384 o A VRF is allocated for each customer who in turn may have multiple 385 VLANs in their end customer sites. So in theory a total of 4K VLANs 386 can be supported per customer. The P-VLAN or the provider VLAN in the 387 case of a Provider Backbone category can also be 4K VLANs. So in 388 effect in this scheme upto 4K customers could be supported if P-VLAN 389 encapsulation is to be used to differentiate between multiple 390 customers. 392 o ISIS for Layer 2 is run atop the Rbridges in the site / Tier-2 393 network 395 o ISIS for Layer 2 disseminates MACs reachable via the TRILL nexthop 396 nicknames of site / Tier-2 network Rbridges amongst the Rbridges in 397 the network site. 399 o N-PEs have VRFs for each tier-2 access network that gain 400 connectivity through the IP+GRE or IP+MPLS core. 402 ____[U-PE]____ ____________ ____[U-PE]____ 403 ( ) ( ) ( ) 404 ( TRILL Based ) ( IP Core with ) ( TRILL Based ) 405 ( RBridges as U-PEs) ( IP+GRE Encap ) ( RBridges as U-PEs) 406 [U-PEB]RBridges as [N-PE] or IP+MPLS [N-PE] RBridges as [U-PEA] 407 .( U-Ps / ).( Encap Tunnels ).( \ U-Ps ) . 408 . ( (X) ) . ( between N-PEs) . ( (Y) ) . 409 . (___[U-PE]_____) . (____________) . (____[U-PE]____) . 410 . . . Other remote 411 Other remote U-PEs ... (BGP-MAC-VPN)... U-PEs known 412 known through TRILL MP-iBGP session through TRILL 413 installing site MAC routes 414 with NextHop as suitable RBridge Nicknames 416 Legend : 417 (X) - Customer A Site 1 MAC-VPN-VRF 418 (Y) - Customer A Site 2 MAC-VPN-VRF 420 U-PEs are edge devices 421 U-Ps are core devices that interconnect U-PEs. 423 Figure 5.0 : BGP-MAC-VPN VRFs amongst N-PEs 425 o N-PEs re-distribute the MAC routes in their respective VRFs into 426 the IS-IS Level 1 area after export / import amongst the N-PEs is 427 done. The reverse re-distribution from IS-IS to BGP is also done at 428 each N-PE for its tier-2 customer site. 430 o N-PEs exchange BGP information through route-targets for various 431 customer sites with other N-PEs. The MAC routes for the various 432 customer sites are placed in the BGP-MAC-VPN VRF of each N-PE for 433 each customer site it connects to on the same lines as U-PE MAC-VPN- 434 VRFs. The MAC routes placed in the VRFs of the N-PEs indicate the MAC 435 addresses for the various Rbridges of the remote tier-2 customer 436 sites with the respective next-hops being the Nicknames of the Level 437 2 pseudo-interface of the far-end N-PE through which these MAC routes 438 are reachable. 440 o U-PE and U-P Rbridges MACs and TRILL nicknames are placed in BGP- 441 MAC-VPN vrf on the N-PEs. 443 o Routes to various end customer MACs within a tier-2 customer's 444 sites are exchanged through BGP MAC-VPN sessions between U-PEs. IP 445 connectivity is provided through IP addresses on same subnet for 446 participating U-PEs. 448 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 449 . ( ) ( ) ( (VRF-CCA) 450 . ( ) ( IP Core ) ( ) . 451 .( PBB-CustA-Site 1 ) ( ) ( PBB-CustA-Site 2 ) . 452 [U-PEA] A1 [N1-PE] [N2-PE] A2 [U-PEB] 453 .( / ) ( ) ( \ ) . 454 . ( (X) ) ( ) ( (Y) ) . 455 . (___[U-PE-B1]__) (____________) (____[U-PE-B2]_) . 456 . | | . 457 . H1 H2 . 458 . Customer's . 459 Customer's............... (BGP-MAC-VPN)............Customer CCA. 460 Customer CCA MP-iBGP session Site 1 461 Site 2 installing Customer's Customer site MAC routes 462 with NextHop as suitable RBridge Area Nicknames 464 Legend : 465 A1, A2 - Area Nicknames of the customer sites in TRILL 466 N1, N2 - These are the N-PEs connecting A1 and A2 running BGP 467 sessions 468 B1, B2 - U-PEs in A1 and A2 respectively running BGP sessions 469 H1, H2 - Hosts connected to B1 and B2 U-PEs. 470 Figure 6.0 : BGP-MAC-VPN VRFs between U-PE amongst various sites 472 2.1.1.3 Control Plane explained in detail. 474 1) B1 and B2 exchange that MACs of H1 and H2 are reachable via BGP. 475 Example., H2-MAC is reachable via B2-MAC through area Nickname A2. 477 2) N1 and N2 exchange that A1 and A2 are reachable through N1 478 Nickname and N2 Nickname respectively via BGP. 480 3) N1 and N2 also exchange the MACs of U-PEs B1 and B2. 482 4) The routes in the N1 and N2 are re-distributed into IS-IS to end 483 up with the following correlated routing state. 485 Now the correlated route in B1 is that H2 -> reachable via -> B2 -> 486 reachable via A2 -> reachable via N1 Nickname. 488 And the correlated route in B2 is that H1 -> reachable via -> B1 -> 489 reachable via A1 -> reachable via N2 Nickname. 491 And the correlated route in N1 is that B2 -> reachable via -> A2 -> 492 reachable via Nickname N2 494 And the correlated route in N2 is that B1 -> reachable via -> A1 -> 495 reachable via Nickname N1 497 2.1.2 Corresponding Data plane for the above control plane example. 499 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 500 . ( ) ( ) ( (VRF-CCA) 501 . ( ) ( IP Core ) ( ) . 502 .( PBB-CustA-Site 1 ) ( ) ( PBB-CustA-Site 2 ) . 503 [U-PEA] A1 [N1-PE] [N2-PE] A2 [U-PEB] 504 .( / ) ( ) ( \ ) . 505 . ( (X) ) ( ) ( (Y) ) . 506 . (___[U-PE-B1]__) (____________) (____[U-PE-B2]_) . 507 . | | . 508 . H1 H2 . 509 . Customer's . 510 Customer's............... (BGP-MAC-VPN)............Customer CCA. 511 Customer CCA MP-iBGP session Site 1 512 Site 2 installing Customer's Customer site MAC routes 513 with NextHop as suitable RBridge Area Nicknames 515 Legend : 516 A1, A2 - Area Nicknames of the customer sites in TRILL 517 N1, N2 - These are the N-PEs connecting A1 and A2 running BGP 518 sessions 519 B1, B2 - U-PEs in A1 and A2 respectively running BGP sessions 520 H1, H2 - Hosts connected to B1 and B2 U-PEs. 521 Figure 6.0 : BGP-MAC-VPN VRFs between U-PE amongst various sites 523 1) H1 sends a packet to B1 with SourceMac as H1-MAC and DestMac as 524 H2-MAC and C-VLAN as C1. This frame is named F1. 526 2) B1 encapsulates this packet in a P-VLAN (Provider VLAN) packet 527 with outer SourceMac as B1-MAC and DestMac as B2-MAC with P-VLAN PV1. 528 This frame is named F2. 530 3) B1 being and Rbridge encapsulates a TRILL header on top of F2, 531 with Ingress Rbridge as B1 and Egress Rbridge as A2. 533 4) This reaches N1 where N1 decapsulates the TRILL header and sends 534 frame F2 inside a IP+GRE header with GRE key as Cust-A's VRF id. 536 5) Packet reaches N2 where N2 looks up the GRE key to identify which 537 customer / VRF to be looked into. 539 6) In that VRF table N2 looks up B2 and encapsulates F2 with TRILL 540 header with Ingress Rbridge as A1 and Egress Rbridge being B2. 542 7) Finally the packet reaches B2 and is decapsulated and sends F1 to 543 the host. 545 2.1.2.1 Control plane for regular Campus and Data center sites 547 For non-PBB like environments one could choose the same capabilities 548 as a PBB like environment with all TORs for e.g in a data center 549 having BGP sessions through BGP Route Reflectors with other TORs. By 550 manipulating the Route Targets specific TORs could be tied in 551 together in the topology within a site or even across sites. The 552 easier way to go about the initial phase of deployment would be to 553 restrict the MP-BGP sessions between N-PEs alone within Campus 554 networks and Data centers and let IS-IS do the job of re-distributing 555 into BGP. Flexibility however can be achieved by letting the U-PEs in 556 the Campus or data center networks too to have MP-BGP sessions. 557 Different logical topologies could be achieved as the result of the 558 U-PE BGP sessions. 560 2.1.2.2 Other Data plane particulars. 562 Default Dtree which is spanning all sites is setup for P-VLAN for 563 Customer's Customer CCA supported on all Tier-2 sites. Denoted by 564 ===, //. 565 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 566 . ( ) ( ) ( (VRF-CCA) 567 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 568 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 569 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 570 .( / ) ( Encap Tunnels ) ( \ // ) . 571 . ( (X) ) ( between N-PEs) ( (Y) // ) . 572 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 573 . Customer's . 574 Customer's............... (BGP-MAC-VPN)............Customer CCA. 575 Customer CCA MP-iBGP session Site 1 576 Site 2 installing Customer's Customer site MAC routes 577 with NextHop as suitable RBridge Area Nicknames 579 Legend : 580 (X) - Customer A Site 1 MAC-VPN-VRF 581 (Y) - Customer A Site 2 MAC-VPN-VRF 582 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 583 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 584 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 586 Figure 8.0 : Dtree spanning all U-PEs for unknown floods. 588 (1) When a packet comes into a U-PE from the near-end the source MAC 589 is learned and placed in the near-end U-PE BGP-MAC-VPN VRF. This is 590 done in a sub-table depending on which VLAN they belong to in the 591 end-customer's VLANs. The destination MAC if unknown is flooded 592 through a default Spanning tree (could be a dtree) constructed for 593 that provider VLAN which is mapped to carry traffic for the end- 594 customer VLAN in the customer's network sites involved. 596 Default Dtree which is spanning all sites is setup for P-VLAN for 597 Customer's Customer CCA supported on all Tier-2 sites. 599 Denoted by ===, //. 601 Forwarding for unknown frames using the default Dtree spanning all 602 customer sites and their respective U-PEs and onto their customers. 604 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 605 . ( ) ( ) ( (VRF-CCA) 606 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 607 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 608 ( ) ( ) ( ) . 609 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 610 .( / ) ( Encap Tunnels ) ( \ // ) . 611 . ( (X) ) ( between N-PEs) ( (Y) // ) . 612 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 613 . Customer's . 614 Customer's............... (BGP-MAC-VPN)............Customer CCA. 615 Customer CCA MP-iBGP session Site 1 616 Site 2 installing Customer's Customer site MAC routes 617 with NextHop as suitable RBridge Area Nicknames 619 Legend : 620 (X) - Customer A Site 1 MAC-VPN-VRF 621 (Y) - Customer A Site 2 MAC-VPN-VRF 622 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 623 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 624 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 626 Figure 9.0 : Unknown floods through Dtree spanning for that P-VLAN 628 (2) The Spanning tree (which could be a dtree for that VLAN) carries 629 that packet through site network switches all the way to N-PEs 630 bordering that network site. U-PEs can drop the packet if there exist 631 no ports for that customer VLAN on that U-PE. The Spanning tree 632 includes auto-configured IP-GRE tunnels or MPLS LSPs across the 633 IP+GRE and/or IP+MPLS cloud which are constituent parts of that tree 634 and hence the unknown flood is carried over to the remote N-PEs 635 participating in the said Dtree. The packet then heads to that 636 remote-end (leaf) U-PEs and on to the end customer sites. For 637 purposes of connecting multiple N-PE devices for a Dtree that is 638 being used for unknown floods, a mechanism such as PIM-Bidir in the 639 core of the IP network can be used. This PIM-Bidir tree would stitch 640 together all the N-PEs of a specific customer. 642 (3) BGP-MAC-VPN VRF exchanges between N-PEs carry the routes for MACs 643 of the near-end Rbridges in the near-end site network to the remote- 644 end site network. At the remote end U-PE a correlation between near- 645 end U-PE and the customer MAC is made after BGP-MAC-VPN VRF exchanges 646 between near-end and far-end U-PEs. The MPLS inner label or the GRE 647 key indicates which VRF to consult for an incoming encapsulated 648 packet at an ingress N-PE and at the outgoing N-PE in the IP core. 650 (4) From thereon the source MAC so learnt at the far end is reachable 651 just like a Hierarchical VPN case in MPLS Carrier Supporting Carrier. 652 The only difference is that the nicknames of the far-end U-PEs/U-Ps 653 may be the same as the nicknames of the near-end U-PEs/U-Ps. In order 654 to overcome this, the MAC-routes exchanged between the U-PEs have the 655 next-hops as Area nicknames of the far-end U-PE and then the Area 656 number nickname is resolved to the near-end N-PE/N-PEs in the local 657 site that provide connectivity to the far-end U-PE in question. 659 srcMac is known at U-PEA, so advertize to other U- 660 PEs through BGP in the other customer sites for Customer A that 661 srcMAC is reachable via U-PEA. This is received at the BGP-MAC-VPN 662 VRFs in U-PEB and U-PEC. 664 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 665 . ( ) ( ) ( (VRF-CCA) 666 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 667 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 668 ( ............ ) ( ............. ) ( .............. ) . 669 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 670 .( / ) ( Encap Tunnels ) ( \ // ) . 671 . ( (X) ) ( between N-PEs) ( (Y) // ) . 672 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 673 . Customer's . 674 Customer's............... (BGP-MAC-VPN)............Customer CCA. 675 Customer CCA MP-iBGP session Site 1 676 Site 2 installing Customer's Customer site MAC routes 677 with NextHop as suitable RBridge Area Nicknames 679 Legend : 680 (X) - Customer A Site 1 MAC-VPN-VRF 681 (Y) - Customer A Site 2 MAC-VPN-VRF 682 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 683 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 684 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 686 Figure 10.0 : Distributing MAC routes through BGP-MAC-VPN 687 689 Flooding when DstMAC is unknown. The flooding reaches all U-PEs and 690 is forwarded to the customer devices (Customer's customer devices). 692 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 693 . ( ) ( ) ( (VRF-CCA) 694 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 695 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 696 ( ............ ) ( ............. ) ( .............. ) . 697 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 698 .( / ) ( Encap Tunnels ) ( \ //. ) . 699 . ( (X) ) ( between N-PEs) ( (Y) //. ) . 700 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 701 . Customer's . 702 Customer's............... (BGP-MAC-VPN)............Customer CCA. 703 Customer CCA MP-iBGP session Site 1 704 Site 2 installing Customer's Customer site MAC routes 705 with NextHop as suitable RBridge Area Nicknames 707 Legend : 708 (X) - Customer A Site 1 MAC-VPN-VRF 709 (Y) - Customer A Site 2 MAC-VPN-VRF 710 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 711 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 712 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 714 Figure 11.0 : Forwarding when DstMAC is unknown. 716 717 When DstMAC is known. Payload is carried in the following fashion in 718 the IP core. 720 (, 721 In PBB like environments / sites interconnected, the payload is P- 722 VLAN headers encapsulating actual payload. 724 725 , ) 727 In Campus and Data Center environments only the latter is carried. 728 There is no P-VLAN header required. 730 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 731 . ( ) ( ) ( (VRF-CCA) 732 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 733 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 734 ( ............ ) ( ............. ) ( .............. ) . 735 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 736 .( / ) ( Encap Tunnels ) ( \ // ) . 737 . ( (X) ) ( between N-PEs) ( (Y) // ) . 738 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 739 . Customer's . 740 Customer's............... (BGP-MAC-VPN)............Customer CCA. 741 Customer CCA MP-iBGP session Site 1 742 Site 2 installing Customer's Customer site MAC routes 743 with NextHop as suitable RBridge Area Nicknames 745 Legend : 746 (X) - Customer A Site 1 MAC-VPN-VRF 747 (Y) - Customer A Site 2 MAC-VPN-VRF 748 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 749 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 750 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 752 Figure 12.0 : Forwarding when the DstMAC is known. 754 (5) The reverse path would do the same for reachability of the near- 755 end from the far-end. 757 (6) Connectivity is thus established between end customer-sites 758 through site networks and through the IP+GRE and/or IP+MPLS core. 760 (7) End customer packets are carried IP+GRE tunnels or IP+MPLS LSPs 761 through access network site to near-end N-PE in the near-end. N-PE 762 encapsulates this in auto-configured MPLS LSPs or IP+GRE tunnels to 763 far-end N-PEs through the IP+GRE and/or IP+MPLS core. The label is 764 stripped at the far-end N-PE and the inner frame continues to far-end 765 U-PE and onto the customer. 767 2.1.3 Encapsulations 769 2.1.3.1 IP + GRE 771 (, 773 In PBB like environments... 775 , 776 , ) 778 In non-PBB like environments such as Campus and Data Center the 779 Ethernet header with P-VLAN header is not required. 781 2.1.3.2 IP + MPLS 783 (, 785 In PBB like environments... 787 , 788 , ) 790 In non-PBB like environments such as Campus and Data Center the 791 Ethernet header with P-VLAN header is not required. 793 2.2 Other use cases 795 o Campus to Campus connectivity can also be achieved using this 796 solution. Multi-homing where multiple U-Pes connect to the same 797 customer site can also facilitate load-balancing if a site-id (can 798 use ESI for MAC-VPN-NLRI) is incorporated in the BGP-MAC-VPN NLRI. 799 Mac Moves can be detected if the site-id of the advertised MAC from 800 U-Pes is different from the older ones available. 802 2.3 Novelty 804 o TRILL MAC routes and their associated nexthops which are TRILL 805 nicknames Are re-distributed into BGP from IS-IS 806 o Thus BGP-MAC-VPNs on N-Pes in the transport network contain MAC 807 routes with nexthops as TRILL Area nicknames. 809 o The customer edge Rbridges / Provider bridges too contain MAC 810 routes with associated nexthops as TRILL nicknames. This proposal is 811 an extension of BGP-MAC-VPN I-D to include MAC routes with TRILL Area 812 nicknames as Nexthops. 814 2.4 Uniqueness and advantages 816 o Uses existing protocols such as IS-IS for Layer 2 and BGP to 817 achieve this. No changes to IS-IS except for redistribution into BGP 818 at the transport core edge and vice-versa. 820 o Uses BGP-MAC-VPNs for transporting MAC-updates of customer devices 821 between edge devices only. 823 o Employs a hierarchical MAC-route hiding from the core Rbridges of 824 the site. Employs a hierarchical VPN like solution to avoid routing 825 state of sites within the transport core. 827 o Multi-tenancy within each data center site is possible by using 828 VLAN separation within the VRF. 830 o Mac Moves can be detected if source learning / Grauitous ARP 831 combined with the BGP-MAC-VPN update triggers a change in the 832 concerned VRF tables. 834 o PBB like functionality supported where P-VLAN and Customer VLAN are 835 different spaces. 837 o Uses regular BGP supporting MAC-VPN features, between transport 838 core edge devices and the Tier-2 customer edge devices. 840 o When new TRILL sites are added then no re-election in the Level 1 841 area is needed. Only the Pseudo-interface of the N-PE has to be added 842 to the mix with the transport of the election PDUs being done across 843 the transport network core. 845 2.4.1 Multi-level IS-IS 847 Akin to TRILL IS-IS multi-level draft where each N-PE can be 848 considered as a ABR having one nickname in a customer site which in 849 turn is a level-1 area and a Pseudo Interface facing the core of the 850 transport network which belongs to a Level 2 Area, the Pseudo 851 Interface would do the TRILL header decapsulation for the incoming 852 packet from the Level 1 Area and throw away the TRILL header within 853 the Pseudo Level 2 Area and transport the packets across the Layer 3 854 core (IP+GRE and/or IP+MPLS) after an encapsulation in IP+GRE or 855 IP+MPLS. Thus we should have to follow a scheme with the NP-E core 856 facing Pseudo-interface in the Level 2 Pseudo-Area doing the TRILL 857 encapsulation and decapsulation for outgoing and incoming packets 858 respectively from and to the transport core. The incoming packets 859 from the Level 1 area are subject to encapsulation in IP+GRE or 860 IP+MPLS by the sending N-PE's Pseudo-Interface and the outgoing 861 packets from the transport core are subject to decapsulation from 862 their IP+GRE or IP+MPLS headers by the Pseudo-Interface on the 863 receiving N-PE. 865 2.5 Comparison with OTV and VPN4DC and other schemes 867 o OTV requires a few proprietary changes to IS-IS. There are less 868 proprietary changes required for this scheme with regard to IS-IS 869 compared to OTV. 871 o VPN4DC is a problem statement and is not yet as comprehensive as 872 the scheme proposed in this document. 874 o [4] deals with Pseudo-wires being setup across the transport core. 875 The control plane protocols for TRILL seem to be tunneled through the 876 transport core. The scheme in the proposal we make do NOT require 877 anything more than Pseudo Level 2 area number exchanges and those for 878 the Pseudo-interfaces. BGP takes care of the rest of the routing. 879 Also [4] does not take care of nick-name collision detection since 880 the control plane TRILL is also tunneled and as a result when a new 881 site is sought to be brought up into the inter-connection amongst 882 existing TRILL sites, nick-name re-election may be required. 884 o [5] does not have a case for TRILL. It was intended for other types 885 of networks which exclude TRILL since [5] has not yet proposed TRILL 886 Nicknames as nexthops for MAC addresses. 888 2.6 Multi-pathing 890 By using different RDs to export the BGP-MAC routes with their 891 appropriate Nickname next-hops from more than one N-PE we could 892 achieve multi-pathing over the transport IP+GRE and/or IP+MPLS core. 894 2.7 TRILL extensions for BGP 896 2.7.1 Format of the MAC-VPN NLRI 897 +-----------------------------------+ 898 | Route Type (1 octet) | 899 +-----------------------------------+ 900 | Length (1 octet) | 901 +-----------------------------------+ 902 | Route Type specific (variable) | 903 +-----------------------------------+ 905 The Route Type field defines encoding of the rest of MAC-VPN NLRI 906 (Route Type specific MAC-VPN NLRI). 908 The Length field indicates the length in octets of the Route Type 909 specific field of MAC-VPN NLRI. 911 This document defines the following Route Types: 913 + 1 - Ethernet Tag Auto-Discovery (A-D) route 914 + 2 - MAC advertisement route 915 + 3 - Inclusive Multicast Ethernet Tag Route 916 + 4 - Ethernet Segment Route 917 + 5 - Selective Multicast Auto-Discovery (A-D) Route 918 + 6 - Leaf Auto-Discovery (A-D) Route 919 + 7 - MAC Advertisement Route with Nexthop as TRILL Nickname 921 Here type 7 is used in this proposal. 923 2.7.2. BGP MAC-VPN MAC Address Advertisement 925 BGP is extended to advertise these MAC addresses using the MAC 926 advertisement route type in the MAC-VPN-NLRI. 928 A MAC advertisement route type specific MAC-VPN NLRI consists of the 929 following: 931 +---------------------------------------+ 932 | RD (8 octets) | 933 +---------------------------------------+ 934 | MAC Address (6 octets) | 935 +---------------------------------------+ 936 |GRE key / MPLS Label rep. VRF(3 octets)| 937 +---------------------------------------+ 938 | Originating Rbridge's IP Address | 939 +---------------------------------------+ 940 | Originating Rbridge's MAC address | 941 | (8 octets) | 942 +---------------------------------------+ 944 The RD MUST be the RD of the MAC-VPN instance that is advertising the 945 NLRI. The procedures for setting the RD for a given MAC VPN are 946 described in section 8 in [3]. 948 The encoding of a MAC address is the 6-octet MAC address specified by 949 IEEE 802 documents [802.1D-ORIG] [802.1D-REV]. 951 If using the IP+GRE and/or IP+MPLS core networks the GRE key or MPLS 952 label MUST be the downstream assigned MAC-VPN GRE key or MPLS label 953 that is used by the N-PE to forward IP+GRE or IP+MPLS encapsulated 954 ethernet packets received from remote N-PEs, where the destination 955 MAC address in the ethernet packet is the MAC address advertised in 956 the above NLRI. The forwarding procedures are specified in previous 957 sections of this document. A N-PE may advertise the same MAC-VPN 958 label for all MAC addresses in a given MAC-VPN instance. Or a N-PE 959 may advertise a unique MAC-VPN label per MAC address. All of these 960 methodologies have their tradeoffs. 962 Per MAC-VPN instance label assignment requires the least number of 963 MAC-VPN labels, but requires a MAC lookup in addition to a GRE key or 964 MPLS lookup on an egress N-PE for forwarding. On the other hand a 965 unique label per MAC allows an egress N-PE to forward a packet that 966 it receives from another N-PE, to the connected CE, after looking up 967 only the GRE key or MPLS labels and not having to do a MAC lookup. 969 The Originating Rbridge's IP address MUST be set to an IP address of 970 the PE (U-PE or N-PE). This address SHOULD be common for all the 971 MAC-VPN instances on the PE (e.,g., this address may be PE's loopback 972 address). 974 2.7.2.1 Next hop field in MP_REACH_NLRI 976 The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 977 be set to the Nickname of the N-PE or in the case of the U-PE the 978 Area Nickname of the Rbridge one whose MAC address is carried in the 979 Originating Rbridge's MAC Address field. 981 The BGP advertisement that advertises the MAC advertisement route 982 MUST also carry one or more Route Target (RT) attributes. 984 It is to be noted that document [3] does not require N-PEs/U-PEs to 985 create forwarding state for remote MACs when they are learned in the 986 control plane. When this forwarding state is actually created is a 987 local implementation matter. However the proposal in this document 988 requires that forwarding state be established when these MAC routes 989 are learned in the control plane. 991 2.7.2.2 Route Reflectors for scaling 992 It is recommended that Route Reflectors SHOULD be deployed to mesh 993 the U-PEs in the sites with other U-PEs at other sites (belonging to 994 the same customer) and the transport network also have RRs to mesh 995 the N-PEs. This takes care of the scaling issues that may arise if 996 full mesh is deployed amongst U-PEs or the N-PEs. 998 2.7.3 Multicast related ideas 1000 For the purpose of multicast it is possible that the IP core can have 1001 a PIM-bidir tree for each customer that will connect all the N-PEs 1002 related to a customer and carry the multicast traffic over the 1003 transport core thus connecting site to site multicast trees. This is 1004 of course out of the scope of this document. The authors intend to 1005 address this issue in future versions of this solution extended for 1006 multicast as well. 1008 3 Security Considerations 1010 TBD. 1012 4 IANA Considerations 1014 A few IANA considerations need to be considered at this point. A 1015 proper AFI-SAFI indicator would have to be provided to carry MAC 1016 addresses as NLRI with Next-hops as Rbridbge Nicknames. This one AFI- 1017 SAFI indicator could be used for both U-PE MP-iBGP sessions and N-PE 1018 MP-iBGP sessions. 1020 5 References 1022 5.1 Normative References 1024 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, March 1997. 1027 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1028 1 1995. 1030 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 1031 April 1 1996. 1033 5.2 Informative References 1035 [1] draft-xl-trill-over-wan-00.txt, XiaoLan. Wan et.al 1036 December 11th ,2011 Work in Progress 1038 [2] draft-perlman-trill-rbridge-multilevel-03.txt, Radia 1039 Perlman et.al October 31, 2011 Work in Progress 1041 [3] draft-raggarwa-mac-vpn-01.txt, Rahul Aggarwal et.al, 1042 June 2010, Work in Progress. 1044 [4] draft-yong-trill-trill-o-mpls, Yong et.al, October 1045 2011, Work in Progress. 1047 [5] draft-raggarwa-sajassi-l2vpn-evpn Rahul Aggarwal 1048 et.al, September 2011, Work in Progress. 1050 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1051 RFC 3514, April 1 2003. 1053 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1054 Acronyms", RFC 5513, April 1 2009. 1056 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1057 2009. 1059 Authors' Addresses 1061 Bhargav Bhikkaji, 1062 Dell-Force10, 1063 350 Holger Way, 1064 San Jose, CA 1065 U.S.A 1067 Email: Bhargav_Bhikkaji@dell.com 1069 Balaji Venkat Venkataswami, 1070 Dell-Force10, 1071 Olympia Technology Park, 1072 Fortius block, 7th & 8th Floor, 1073 Plot No. 1, SIDCO Industrial Estate, 1074 Guindy, Chennai - 600032. 1075 TamilNadu, India. 1076 Tel: +91 (0) 44 4220 8400 1077 Fax: +91 (0) 44 2836 2446 1079 EMail: BALAJI_VENKAT_VENKAT@dell.com 1081 Narayana Perumal Swamy, 1082 Dell-Force10, 1083 Olympia Technology Park, 1084 Fortius block, 7th & 8th Floor, 1085 Plot No. 1, SIDCO Industrial Estate, 1086 Guindy, Chennai - 600032. 1087 TamilNadu, India. 1088 Tel: +91 (0) 44 4220 8400 1089 Fax: +91 (0) 44 2836 2446 1090 Email: Narayana_Perumal@dell.com 1092 A.1 Appendix I 1094 A.1.1 Extract from Multi-level IS-IS draft made applicable to scheme 1096 In the following picture, RB2 and RB3 are area border RBridges. A 1097 source S is attached to RB1. The two areas have nicknames 15961 and 1098 15918, respectively. RB1 has a nickname, say 27, and RB4 has a 1099 nickname, say 44 (and in fact, they could even have the same 1100 nickname, since the RBridge nickname will not be visible outside the 1101 area). 1103 Pseudo 1104 Area 15961 level 2 Area 15918 1105 +-------------------+ +-----------------+ +--------------+ 1106 | | | IP Core network | | | 1107 | S--RB1---Rx--Rz----RB2--- ----RB3---Rk--RB4---D | 1108 | 27 | | . . | | 44 | 1109 | | |Pseudo-Interface | | | 1110 +-------------------+ +-----------------+ +--------------+ 1112 Here RB2 and RB3 are N-PEs. RB4 and RB1 are U-PEs. 1114 This sample topology could apply to Campus and data-center 1115 topologies. For Provider Backbone topologies S would fall outside the 1116 Area 15961 and RB1 would be the U-PE carrying the C-VLANs inside a P- 1117 VLAN for a specific customer. 1119 Let's say that S transmits a frame to destination D, which is 1120 connected to RB4, and let's say that D's location is learned by the 1121 relevant RBridges already. The relevant RBridges have learned the 1122 following: 1124 1) RB1 has learned that D is connected to nickname 15918 1125 2) RB3 has learned that D is attached to nickname 44. 1127 The following sequence of events will occur: 1129 - S transmits an Ethernet frame with source MAC = S and destination 1130 MAC = D. 1132 - RB1 encapsulates with a TRILL header with ingress RBridge = 27, 1133 and egress = 15918. 1135 - RB2 has announced in the Level 1 IS-IS instance in area 15961, 1136 that it is attached to all the area nicknames, including 15918. 1137 Therefore, IS-IS routes the frame to RB2. (Alternatively, if a 1138 distinguished range of nicknames is used for Level 2, Level 1 1139 RBridges seeing such an egress nickname will know to route to the 1140 nearest border router, which can be indicated by the IS-IS attached 1141 bit.) 1143 In the original draft on multi-level IS-IS the following happens and 1145 QUOTE... 1147 - RB2, when transitioning the frame from Level 1 to Level 2, 1148 replaces the ingress RBridge nickname with the area nickname, so 1149 replaces 27 with 15961. Within Level 2, the ingress RBridge field in 1150 the TRILL header will therefore be 15961, and the egress RBridge 1151 field will be 15918. Also RB2 learns that S is attached to nickname 1152 27 in area 15961 to accommodate return traffic. 1154 - The frame is forwarded through Level 2, to RB3, which has 1155 advertised, in Level 2, reachability to the nickname 15918. 1157 - RB3, when forwarding into area 15918, replaces the egress nickname 1158 in the TRILL header with RB4's nickname (44). So, within the 1159 destination area, the ingress nickname will be 15961 and the egress 1160 nickname will be 44. 1162 - RB4, when decapsulating, learns that S is attached to nickname 1163 15961, which is the area nickname of the ingress. 1165 Now suppose that D's location has not been learned by RB1 and/or RB3. 1166 What will happen, as it would in TRILL today, is that RB1 will 1167 forward the frame as a multi-destination frame, choosing a tree. As 1168 the multi-destination frame transitions into Level 2, RB2 replaces 1169 the ingress nickname with the area nickname. If RB1 does not know the 1170 location of D, the frame must be flooded, subject to possible 1171 pruning, in Level 2 and, subject to possible pruning, from Level 2 1172 into every Level 1 area that it reaches on the Level 2 distribution 1173 tree. 1175 UNQUOTE... 1177 In the current proposal that we outline in this document, the TRILL 1178 header is done away with completely in the IP+GRE or IP+MPLS core. A 1179 re-look into the inner headers after decapsulation gives the 1180 appropriate information to carry the frame from the N-PE towards the 1181 destination U-PE.