idnits 2.17.1 draft-balaji-trill-over-ip-multi-level-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 : ---------------------------------------------------------------------------- ** 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 800 has weird spacing: '...e U-Pes conne...' == Line 837 has weird spacing: '...e U-Pes conne...' == Line 893 has weird spacing: '...terface would...' -- The document date (February 25, 2012) is 4415 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 1031, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1060, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1063, 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 (~~), 23 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: August 2012 DELL-Force10 6 February 25, 2012 8 Connecting Disparate Data Center/PBB/Campus TRILL sites using BGP 9 draft-balaji-trill-over-ip-multi-level-01 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.5 Comparison with OTV and VPN4DC and other schemes . . . . . . 21 98 2.6 Multi-pathing . . . . . . . . . . . . . . . . . . . . . . . 21 99 2.7 TRILL extensions for BGP . . . . . . . . . . . . . . . . . . 21 100 2.7.0 Multi-level IS-IS . . . . . . . . . . . . . . . . . . . 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. 641 (3) BGP-MAC-VPN VRF exchanges between N-PEs carry the routes for MACs 642 of the near-end Rbridges in the near-end site network to the remote- 643 end site network. At the remote end U-PE a correlation between near- 644 end U-PE and the customer MAC is made after BGP-MAC-VPN VRF exchanges 645 between near-end and far-end U-PEs. The MPLS inner label or the GRE 646 key indicates which VRF to consult for an incoming encapsulated 647 packet across the core and the far-end N-PE's Level 1 Area Nickname 648 of the far-end N-PE is inserted as the Egress Rbridge Nickname in the 649 TRILL header of the packet traversing the core from the near-end N- 650 PE. 652 (4) From thereon the source MAC so learnt at the far end is reachable 653 just like a Hierarchical VPN case in MPLS Carrier Supporting Carrier. 654 The only difference is that the nicknames of the far-end U-PEs/U-Ps 655 may be the same as the nicknames of the near-end U-PEs/U-Ps. In order 656 to overcome this, the MAC-routes exchanged between the U-PEs have the 657 next-hops as Area nicknames of the far-end U-PE and then the Area 658 number nickname is resolved to the near-end N-PE/N-PEs in the local 659 site that provide connectivity to the far-end U-PE in question. 661 srcMac is known at U-PEA, so advertize to other U- 662 PEs through BGP in the other customer sites for Customer A that 663 srcMAC is reachable via U-PEA. This is received at the BGP-MAC-VPN 664 VRFs in U-PEB and U-PEC. 666 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 667 . ( ) ( ) ( (VRF-CCA) 668 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 669 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 670 ( ............ ) ( ............. ) ( .............. ) . 671 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 672 .( / ) ( Encap Tunnels ) ( \ // ) . 673 . ( (X) ) ( between N-PEs) ( (Y) // ) . 674 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 675 . Customer's . 676 Customer's............... (BGP-MAC-VPN)............Customer CCA. 677 Customer CCA MP-iBGP session Site 1 678 Site 2 installing Customer's Customer site MAC routes 679 with NextHop as suitable RBridge Area Nicknames 681 Legend : 682 (X) - Customer A Site 1 MAC-VPN-VRF 683 (Y) - Customer A Site 2 MAC-VPN-VRF 684 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 685 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 686 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 688 Figure 10.0 : Distributing MAC routes through BGP-MAC-VPN 689 691 Flooding when DstMAC is unknown. The flooding reaches all U-PEs and 692 is forwarded to the customer devices (Customer's customer devices). 694 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 695 . ( ) ( ) ( (VRF-CCA) 696 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 697 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 698 ( ............ ) ( ............. ) ( .............. ) . 699 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 700 .( / ) ( Encap Tunnels ) ( \ //. ) . 701 . ( (X) ) ( between N-PEs) ( (Y) //. ) . 702 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 703 . Customer's . 704 Customer's............... (BGP-MAC-VPN)............Customer CCA. 705 Customer CCA MP-iBGP session Site 1 706 Site 2 installing Customer's Customer site MAC routes 707 with NextHop as suitable RBridge Area Nicknames 709 Legend : 710 (X) - Customer A Site 1 MAC-VPN-VRF 711 (Y) - Customer A Site 2 MAC-VPN-VRF 712 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 713 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 714 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 716 Figure 11.0 : Forwarding when DstMAC is unknown. 718 719 When DstMAC is known. Payload is carried in the following fashion in 720 the IP core. 722 (, 723 In PBB like environments / sites interconnected, the payload is P- 724 VLAN headers encapsulating actual payload. 726 727 , ) 729 In Campus and Data Center environments only the latter is carried. 730 There is no P-VLAN header required. 732 (VRF-CCA)[U-PE]____ ____________ ____[U-PE]____ 733 . ( ) ( ) ( (VRF-CCA) 734 . ( TRILL Based ) ( IP Core with ) ( TRILL Based ) . 735 .( Customer A Site 1) ( IP+GRE Encap ) ( Customer A Site 2) . 736 ( ............ ) ( ............. ) ( .............. ) . 737 [U-PEA]============[N-PE]=============[N-PE]==============[U-PEB] 738 .( / ) ( Encap Tunnels ) ( \ //. ) . 739 . ( (X) ) ( between N-PEs) ( (Y) //. ) . 740 . (___[U-PE]_____) (____________) (____[U-PEC]....(VRF-CCA) 741 . Customer's . 742 Customer's............... (BGP-MAC-VPN)............Customer CCA. 743 Customer CCA MP-iBGP session Site 1 744 Site 2 installing Customer's Customer site MAC routes 745 with NextHop as suitable RBridge Area Nicknames 747 Legend : 748 (X) - Customer A Site 1 MAC-VPN-VRF 749 (Y) - Customer A Site 2 MAC-VPN-VRF 750 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 1 751 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 2 752 (VRF-CCA) - MAC-VPN-VRF for Customer's Customer A (CCA) Site 3 754 Figure 12.0 : Forwarding when the DstMAC is known. 756 (5) The reverse path would do the same for reachability of the 757 remote-end from the far-end. 759 (6) Connectivity is thus established between end customer-sites 760 through site networks and through the IP+GRE and/or IP+MPLS core. One 761 could deploy also VPLS for access network connectivity after 762 encapsulating the TRILL header and the outer header. 764 (7) End customer packets are carried IP+GRE tunnels or IP+MPLS LSPs 765 through access network site to near-end N-PE in the near-end. N-PE 766 encapsulates this in auto-configured MPLS LSPs or IP+GRE tunnels to 767 far-end N-PEs through the IP+GRE and/or IP+MPLS core. The label is 768 stripped at the far-end N-PE and the inner frame continues to far-end 769 U-PE and onto the customer. 771 2.1.3 Encapsulations 773 2.1.3.1 IP + GRE 775 (, 777 In PBB like environments... 779 , 780 , ) 782 In non-PBB like environments such as Campus and Data Center the 783 Ethernet header with P-VLAN header is not required. 785 2.1.3.2 IP + MPLS 787 (, 789 In PBB like environments... 791 , 792 , ) 794 In non-PBB like environments such as Campus and Data Center the 795 Ethernet header with P-VLAN header is not required. 797 2.2 Other use cases 799 o Campus to Campus connectivity can also be achieved using this 800 solution. Multi-homing where multiple U-Pes connect to the same 801 customer site can also facilitate load-balancing if a site-id (can 802 use ESI for MAC-VPN-NLRI) is incorporated in the BGP-MAC-VPN NLRI. 803 Mac Moves can be detected if the site-id of the advertised MAC from 804 U-Pes is different from the older ones available. 806 2.3 Novelty 808 o TRILL MAC routes and their associated nexthops which are TRILL 809 nicknames Are re-distributed into BGP from IS-IS 811 o Thus BGP-MAC-VPNs on N-Pes in the transport network contain MAC 812 routes with nexthops as TRILL Area nicknames. 814 o The customer edge Rbridges / Provider bridges too contain MAC 815 routes with associated nexthops as TRILL nicknames. This proposal is 816 an extension of BGP-MAC-VPN I-D to include MAC routes with TRILL Area 817 nicknames as Nexthops. 819 2.4 Uniqueness and advantages 821 o Uses existing protocols such as IS-IS for Layer 2 and BGP to 822 achieve this. No changes to IS-IS except for redistribution into BGP 823 at the transport core edge and vice-versa. 825 o Uses BGP-MAC-VPNs for transporting MAC-updates of customer devices 826 between edge devices only. 828 o Employs a hierarchical MAC-route hiding within the core Rbridges of 829 the site. Employs a hierarchical VPN like solution to avoid routing 830 state of sites within the transport core. 832 o Multi-tenancy within each data center 834 o Provider-backbone bridging like customer MAC hiding from the core 835 of each site. 837 o Multi-homing where multiple U-Pes connect to the same customer 838 site can also facilitate load-balancing if a site-id (can use ESI for 839 MAC-VPN-NLRI) is incorporated in the BGP-MAC-VPN NLRI. 841 o Mac Moves can be detected if the site-id of the advertised MAC from 842 U-Pes is different from the older ones available. 844 o PBB like functionality supported where P-VLAN and C-VLAN are 845 different spaces. 847 o Disparate TRILL networks with or without multi-tenancy. 849 o Uses regular BGP supporting MAC-VPN features. Both between 850 transport core edge devices and the Tier-2 customer edge devices. 852 o When new TRILL sites are added then no re-election in the Level 1 853 area is needed. Only the Pseudo-interface of the N-PE has to be added 854 to the mix with the transport of the election PDUs being done across 855 the transport network core. 857 2.5 Comparison with OTV and VPN4DC and other schemes 859 o OTV requires proprietary changes to IS-IS Doesn't seem to have 860 reached the RFC status yet Its encapsulation could be more 861 standardized Lot of proprietary changes required compared to this 862 scheme with regard to IS-IS. 864 o VPN4DC is just a problem statement. 866 o [4] deals with Pseudo-wires being setup across the transport core. 867 The control plane protocols for TRILL seem to be tunneled through the 868 transport core. The scheme in the proposal we make do NOT require 869 anything more than Pseudo Level 2 area number exchanges and those for 870 the Pseudo-interfaces. BGP takes care of the rest of the routing. 871 Also [4] does not take care of nick-name collision detection since 872 the control plane TRILL is also tunneled and as a result when a new 873 site is sought to be brought up into the inter-connection amongst 874 existing TRILL sites, nick-name re-election may be required. 876 o [5] does not have a case for TRILL. It was intended for other types 877 of networks which exclude TRILL. 879 2.6 Multi-pathing 881 By using different RDs to export the BGP-MAC routes with their 882 appropriate Nickname next-hops from more than one N-PE we could 883 achieve multi-pathing over the transport IP+GRE and/or IP+MPLS core. 885 2.7 TRILL extensions for BGP 887 2.7.0 Multi-level IS-IS 889 Akin to TRILL IS-IS multi-level draft where each N-PE can be 890 considered as a ABR having one nickname in a customer site which in 891 turn is a level-1 area And a Pseudo Interface facing the core of the 892 transport network which belongs to a Level 2 Area The Pseudo 893 Interface would do the header rewrite for the incoming packet from 894 the Level 1 Area with appropriate area nicknames within the Pseudo 895 Level 2 Area and transport the packets across the Layer 3 core 896 (IP+GRE and/or IP+MPLS) after an enacp in IP+GRE and/or IP+MPLS. Thus 897 we should have to follow a scheme with the NP-E non-core facing 898 interface in Level 1 and the rest of the Rbridges in Level 1 area for 899 that site and the Pseudo Interface inside the N-PE which is in Level 900 2 doing the header rewrites and then the encapsulator for IP+GRE 901 and/or IP+MPLS subsequently to get the packet from N-PE to N-PE. 903 2.7.1 Format of the MAC-VPN NLRI 904 +-----------------------------------+ 905 | Route Type (1 octet) | 906 +-----------------------------------+ 907 | Length (1 octet) | 908 +-----------------------------------+ 909 | Route Type specific (variable) | 910 +-----------------------------------+ 912 The Route Type field defines encoding of the rest of MAC-VPN NLRI 913 (Route Type specific MAC-VPN NLRI). 915 The Length field indicates the length in octets of the Route Type 916 specific field of MAC-VPN NLRI. 918 This document defines the following Route Types: 920 + 1 - Ethernet Tag Auto-Discovery (A-D) route 921 + 2 - MAC advertisement route 922 + 3 - Inclusive Multicast Ethernet Tag Route 923 + 4 - Ethernet Segment Route 924 + 5 - Selective Multicast Auto-Discovery (A-D) Route 925 + 6 - Leaf Auto-Discovery (A-D) Route 926 + 7 - MAC Advertisement Route with Nexthop as TRILL Nickname 928 Here type 7 is used in this proposal. 930 2.7.2. BGP MAC-VPN MAC Address Advertisement 932 BGP is extended to advertise these MAC addresses using the MAC 933 advertisement route type in the MAC-VPN-NLRI. 935 A MAC advertisement route type specific MAC-VPN NLRI consists of the 936 following: 938 +---------------------------------------+ 939 | RD (8 octets) | 940 +---------------------------------------+ 941 | MAC Address (6 octets) | 942 +---------------------------------------+ 943 |GRE key / MPLS Label rep. VRF(3 octets)| 944 +---------------------------------------+ 945 | Originating Rbridge's IP Address | 946 +---------------------------------------+ 947 | Originating Rbridge's MAC address | 948 | (8 octets) | 949 +---------------------------------------+ 951 The RD MUST be the RD of the MAC-VPN instance that is advertising the 952 NLRI. The procedures for setting the RD for a given MAC VPN are 953 described in section 8 in [3]. 955 The encoding of a MAC address is the 6-octet MAC address specified by 956 IEEE 802 documents [802.1D-ORIG] [802.1D-REV]. 958 If using the IP+GRE and/or IP+MPLS core networks the GRE key or MPLS 959 label MUST be the downstream assigned MAC-VPN GRE key or MPLS label 960 that is used by the N-PE to forward IP+GRE or IP+MPLS encapsulated 961 ethernet packets received from remote N-PEs, where the destination 962 MAC address in the ethernet packet is the MAC address advertised in 963 the above NLRI. The forwarding procedures are specified in previous 964 sections of this document. A N-PE may advertise the same MAC-VPN 965 label for all MAC addresses in a given MAC-VPN instance. Or a N-PE 966 may advertise a unique MAC-VPN label per MAC address. All of these 967 methodologies have their tradeoffs. 969 Per MAC-VPN instance label assignment requires the least number of 970 MAC-VPN labels, but requires a MAC lookup in addition to a GRE key or 971 MPLS lookup on an egress N-PE for forwarding. On the other hand a 972 unique label per MAC allows an egress N-PE to forward a packet that 973 it receives from another N-PE, to the connected CE, after looking up 974 only the GRE key or MPLS labels and not having to do a MAC lookup. 976 The Originating Rbridge's IP address MUST be set to an IP address of 977 the PE (U-PE or N-PE). This address SHOULD be common for all the 978 MAC-VPN instances on the PE (e.,g., this address may be PE's loopback 979 address). 981 2.7.2.1 Next hop field in MP_REACH_NLRI 983 The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 984 be set to the Nickname of the N-PE or in the case of the U-PE the 985 Area Nickname of the Rbridge one whose MAC address is carried in the 986 Originating Rbridge's MAC Address field. 988 The BGP advertisement that advertises the MAC advertisement route 989 MUST also carry one or more Route Target (RT) attributes. 991 It is to be noted that document [3] does not require N-PEs/U-PEs to 992 create forwarding state for remote MACs when they are learned in the 993 control plane. When this forwarding state is actually created is a 994 local implementation matter. However the proposal in this document 995 requires that forwarding state be established when these MAC routes 996 are learned in the control plane. 998 2.7.2.2 Route Reflectors for scaling 999 It is recommended that Route Reflectors SHOULD be deployed to mesh 1000 the U-PEs in the sites with other U-PEs at other sites (belonging to 1001 the same customer) and the transport network also have RRs to mesh 1002 the N-PEs. This takes care of the scaling issues that may arise if 1003 full mesh is deployed amongst U-PEs or the N-PEs. 1005 2.7.3 Multicast related ideas 1007 For the purpose of multicast it is possible that the IP core can have 1008 a PIM-bidir tree for each customer that will connect all the N-PEs 1009 related to a customer and carry the multicast traffic over the 1010 transport core thus connecting site to site multicast trees. This is 1011 of course out of the scope of this document. The authors intend to 1012 address this issue in future versions of this solution extended for 1013 multicast as well. 1015 3 Security Considerations 1017 TBD. 1019 4 IANA Considerations 1021 A few IANA considerations need to be considered at this point. A 1022 proper AFI-SAFI indicator would have to be provided to carry MAC 1023 addresses as NLRI with Next-hops as Rbridbge Nicknames. This one AFI- 1024 SAFI indicator could be used for both U-PE MP-iBGP sessions and N-PE 1025 MP-iBGP sessions. 1027 5 References 1029 5.1 Normative References 1031 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, March 1997. 1034 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1035 1 1995. 1037 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 1038 April 1 1996. 1040 5.2 Informative References 1042 [1] draft-xl-trill-over-wan-00.txt, XiaoLan. Wan et.al 1043 December 11th ,2011 Work in Progress 1045 [2] draft-perlman-trill-rbridge-multilevel-03.txt, Radia 1046 Perlman et.al October 31, 2011 Work in Progress 1048 [3] draft-raggarwa-mac-vpn-01.txt, Rahul Aggarwal et.al, 1049 June 2010, Work in Progress. 1051 [4] draft-yong-trill-trill-o-mpls, Yong et.al, October 1052 2011, Work in Progress. 1054 [5] draft-raggarwa-sajassi-l2vpn-evpn Rahul Aggarwal 1055 et.al, September 2011, Work in Progress. 1057 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1058 RFC 3514, April 1 2003. 1060 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1061 Acronyms", RFC 5513, April 1 2009. 1063 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1064 2009. 1066 Authors' Addresses 1068 Bhargav Bhikkaji, 1069 Dell-Force10, 1070 350 Holger Way, 1071 San Jose, CA 1072 U.S.A 1074 Email: Bhargav_Bhikkaji@dell.com 1076 Balaji Venkat Venkataswami, 1077 Dell-Force10, 1078 Olympia Technology Park, 1079 Fortius block, 7th & 8th Floor, 1080 Plot No. 1, SIDCO Industrial Estate, 1081 Guindy, Chennai - 600032. 1082 TamilNadu, India. 1083 Tel: +91 (0) 44 4220 8400 1084 Fax: +91 (0) 44 2836 2446 1086 EMail: BALAJI_VENKAT_VENKAT@dell.com 1088 Narayana Perumal Swamy, 1089 Dell-Force10, 1090 Olympia Technology Park, 1091 Fortius block, 7th & 8th Floor, 1092 Plot No. 1, SIDCO Industrial Estate, 1093 Guindy, Chennai - 600032. 1094 TamilNadu, India. 1095 Tel: +91 (0) 44 4220 8400 1096 Fax: +91 (0) 44 2836 2446 1097 Email: Narayana_Perumal@dell.com 1099 A.1 Appendix I 1101 A.1.1 Extract from Multi-level IS-IS draft made applicable to scheme 1103 In the following picture, RB2 and RB3 are area border RBridges. A 1104 source S is attached to RB1. The two areas have nicknames 15961 and 1105 15918, respectively. RB1 has a nickname, say 27, and RB4 has a 1106 nickname, say 44 (and in fact, they could even have the same 1107 nickname, since the RBridge nickname will not be visible outside the 1108 area). 1110 Pseudo 1111 Area 15961 level 2 Area 15918 1112 +-------------------+ +-----------------+ +--------------+ 1113 | | | IP Core network | | | 1114 | S--RB1---Rx--Rz----RB2--- ----RB3---Rk--RB4---D | 1115 | 27 | | . . | | 44 | 1116 | | |Pseudo-Interface | | | 1117 +-------------------+ +-----------------+ +--------------+ 1119 Here RB2 and RB3 are N-PEs. RB4 and RB1 are U-PEs. 1121 This sample topology could apply to Campus and data-center 1122 topologies. For Provider Backbone topologies S would fall outside the 1123 Area 15961 and RB1 would be the U-PE carrying the C-VLANs inside a P- 1124 VLAN for a specific customer. 1126 Let's say that S transmits a frame to destination D, which is 1127 connected to RB4, and let's say that D's location is learned by the 1128 relevant RBridges already. The relevant RBridges have learned the 1129 following: 1131 1) RB1 has learned that D is connected to nickname 15918 1132 2) RB3 has learned that D is attached to nickname 44. 1134 The following sequence of events will occur: 1136 - S transmits an Ethernet frame with source MAC = S and destination 1137 MAC = D. 1139 - RB1 encapsulates with a TRILL header with ingress RBridge = 27, 1140 and egress = 15918. 1142 - RB2 has announced in the Level 1 IS-IS instance in area 15961, 1143 that it is attached to all the area nicknames, including 15918. 1144 Therefore, IS-IS routes the frame to RB2. (Alternatively, if a 1145 distinguished range of nicknames is used for Level 2, Level 1 1146 RBridges seeing such an egress nickname will know to route to the 1147 nearest border router, which can be indicated by the IS-IS attached 1148 bit.) 1150 In the original draft on multi-level IS-IS the following happens and 1152 QUOTE... 1154 - RB2, when transitioning the frame from Level 1 to Level 2, 1155 replaces the ingress RBridge nickname with the area nickname, so 1156 replaces 27 with 15961. Within Level 2, the ingress RBridge field in 1157 the TRILL header will therefore be 15961, and the egress RBridge 1158 field will be 15918. Also RB2 learns that S is attached to nickname 1159 27 in area 15961 to accommodate return traffic. 1161 - The frame is forwarded through Level 2, to RB3, which has 1162 advertised, in Level 2, reachability to the nickname 15918. 1164 - RB3, when forwarding into area 15918, replaces the egress nickname 1165 in the TRILL header with RB4's nickname (44). So, within the 1166 destination area, the ingress nickname will be 15961 and the egress 1167 nickname will be 44. 1169 - RB4, when decapsulating, learns that S is attached to nickname 1170 15961, which is the area nickname of the ingress. 1172 Now suppose that D's location has not been learned by RB1 and/or RB3. 1173 What will happen, as it would in TRILL today, is that RB1 will 1174 forward the frame as a multi-destination frame, choosing a tree. As 1175 the multi-destination frame transitions into Level 2, RB2 replaces 1176 the ingress nickname with the area nickname. If RB1 does not know the 1177 location of D, the frame must be flooded, subject to possible 1178 pruning, in Level 2 and, subject to possible pruning, from Level 2 1179 into every Level 1 area that it reaches on the Level 2 distribution 1180 tree. 1182 UNQUOTE... 1184 In the current proposal that we outline in this document, the TRILL 1185 header is done away with completely in the IP+GRE or IP+MPLS core. A 1186 re-look into the inner headers after decapsulation gives the 1187 appropriate information to carry the frame from the N-PE towards the 1188 destination U-PE.