idnits 2.17.1 draft-balaji-trill-over-ip-multi-level-03.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 798 has weird spacing: '...e U-Pes conne...' == Line 884 has weird spacing: '...terface would...' -- The document date (February 29, 2012) is 4439 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 1026, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 1058, 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: August 2012 DELL-Force10 6 February 29, 2012 8 Connecting Disparate Data Center/PBB/Campus TRILL sites using BGP 9 draft-balaji-trill-over-ip-multi-level-03 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 . . . . . . 20 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. 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 755 remote-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. One 759 could deploy also VPLS for access network connectivity after 760 encapsulating the TRILL header and the outer header. 762 (7) End customer packets are carried IP+GRE tunnels or IP+MPLS LSPs 763 through access network site to near-end N-PE in the near-end. N-PE 764 encapsulates this in auto-configured MPLS LSPs or IP+GRE tunnels to 765 far-end N-PEs through the IP+GRE and/or IP+MPLS core. The label is 766 stripped at the far-end N-PE and the inner frame continues to far-end 767 U-PE and onto the customer. 769 2.1.3 Encapsulations 771 2.1.3.1 IP + GRE 773 (, 775 In PBB like environments... 777 , 778 , ) 780 In non-PBB like environments such as Campus and Data Center the 781 Ethernet header with P-VLAN header is not required. 783 2.1.3.2 IP + MPLS 785 (, 787 In PBB like environments... 789 , 790 , ) 792 In non-PBB like environments such as Campus and Data Center the 793 Ethernet header with P-VLAN header is not required. 795 2.2 Other use cases 797 o Campus to Campus connectivity can also be achieved using this 798 solution. Multi-homing where multiple U-Pes connect to the same 799 customer site can also facilitate load-balancing if a site-id (can 800 use ESI for MAC-VPN-NLRI) is incorporated in the BGP-MAC-VPN NLRI. 801 Mac Moves can be detected if the site-id of the advertised MAC from 802 U-Pes is different from the older ones available. 804 2.3 Novelty 806 o TRILL MAC routes and their associated nexthops which are TRILL 807 nicknames Are re-distributed into BGP from IS-IS 809 o Thus BGP-MAC-VPNs on N-Pes in the transport network contain MAC 810 routes with nexthops as TRILL Area nicknames. 812 o The customer edge Rbridges / Provider bridges too contain MAC 813 routes with associated nexthops as TRILL nicknames. This proposal is 814 an extension of BGP-MAC-VPN I-D to include MAC routes with TRILL Area 815 nicknames as Nexthops. 817 2.4 Uniqueness and advantages 819 o Uses existing protocols such as IS-IS for Layer 2 and BGP to 820 achieve this. No changes to IS-IS except for redistribution into BGP 821 at the transport core edge and vice-versa. 823 o Uses BGP-MAC-VPNs for transporting MAC-updates of customer devices 824 between edge devices only. 826 o Employs a hierarchical MAC-route hiding from the core Rbridges of 827 the site. Employs a hierarchical VPN like solution to avoid routing 828 state of sites within the transport core. 830 o Multi-tenancy within each data center site is possible by using 831 VLAN separation within the VRF. 833 o Mac Moves can be detected if source learning / Grauitous ARP 834 combined with the BGP-MAC-VPN update triggers a change in the 835 concerned VRF tables. 837 o PBB like functionality supported where P-VLAN and Customer VLAN are 838 different spaces. 840 o Uses regular BGP supporting MAC-VPN features, between transport 841 core edge devices and the Tier-2 customer edge devices. 843 o When new TRILL sites are added then no re-election in the Level 1 844 area is needed. Only the Pseudo-interface of the N-PE has to be added 845 to the mix with the transport of the election PDUs being done across 846 the transport network core. 848 2.5 Comparison with OTV and VPN4DC and other schemes 850 o OTV requires proprietary changes to IS-IS Doesn't seem to have 851 reached the RFC status yet Its encapsulation could be more 852 standardized Lot of proprietary changes required compared to this 853 scheme with regard to IS-IS. 855 o VPN4DC is just a problem statement. 857 o [4] deals with Pseudo-wires being setup across the transport core. 858 The control plane protocols for TRILL seem to be tunneled through the 859 transport core. The scheme in the proposal we make do NOT require 860 anything more than Pseudo Level 2 area number exchanges and those for 861 the Pseudo-interfaces. BGP takes care of the rest of the routing. 862 Also [4] does not take care of nick-name collision detection since 863 the control plane TRILL is also tunneled and as a result when a new 864 site is sought to be brought up into the inter-connection amongst 865 existing TRILL sites, nick-name re-election may be required. 867 o [5] does not have a case for TRILL. It was intended for other types 868 of networks which exclude TRILL. 870 2.6 Multi-pathing 872 By using different RDs to export the BGP-MAC routes with their 873 appropriate Nickname next-hops from more than one N-PE we could 874 achieve multi-pathing over the transport IP+GRE and/or IP+MPLS core. 876 2.7 TRILL extensions for BGP 878 2.7.0 Multi-level IS-IS 880 Akin to TRILL IS-IS multi-level draft where each N-PE can be 881 considered as a ABR having one nickname in a customer site which in 882 turn is a level-1 area and a Pseudo Interface facing the core of the 883 transport network which belongs to a Level 2 Area, the Pseudo 884 Interface would do the TRILL header decapsulation for the incoming 885 packet from the Level 1 Area and throw away the TRILL header within 886 the Pseudo Level 2 Area and transport the packets across the Layer 3 887 core (IP+GRE and/or IP+MPLS) after an encapsulation in IP+GRE or 888 IP+MPLS. Thus we should have to follow a scheme with the NP-E core 889 facing Pseudo-interface in the Level 2 Pseudo-Area doing the TRILL 890 encapsulation and decapsulation for outgoing and incoming packets 891 respectively from and to the transport core. The incoming packets 892 from the Level 1 area are subject to encapsulation in IP+GRE or 893 IP+MPLS by the sending N-PE's Pseudo-Interface and the outgoing 894 packets from the transport core are subject to decapsulation from 895 their IP+GRE or IP+MPLS headers by the Pseudo-Interface on the 896 receiving N-PE. 898 2.7.1 Format of the MAC-VPN NLRI 899 +-----------------------------------+ 900 | Route Type (1 octet) | 901 +-----------------------------------+ 902 | Length (1 octet) | 903 +-----------------------------------+ 904 | Route Type specific (variable) | 905 +-----------------------------------+ 907 The Route Type field defines encoding of the rest of MAC-VPN NLRI 908 (Route Type specific MAC-VPN NLRI). 910 The Length field indicates the length in octets of the Route Type 911 specific field of MAC-VPN NLRI. 913 This document defines the following Route Types: 915 + 1 - Ethernet Tag Auto-Discovery (A-D) route 916 + 2 - MAC advertisement route 917 + 3 - Inclusive Multicast Ethernet Tag Route 918 + 4 - Ethernet Segment Route 919 + 5 - Selective Multicast Auto-Discovery (A-D) Route 920 + 6 - Leaf Auto-Discovery (A-D) Route 921 + 7 - MAC Advertisement Route with Nexthop as TRILL Nickname 923 Here type 7 is used in this proposal. 925 2.7.2. BGP MAC-VPN MAC Address Advertisement 927 BGP is extended to advertise these MAC addresses using the MAC 928 advertisement route type in the MAC-VPN-NLRI. 930 A MAC advertisement route type specific MAC-VPN NLRI consists of the 931 following: 933 +---------------------------------------+ 934 | RD (8 octets) | 935 +---------------------------------------+ 936 | MAC Address (6 octets) | 937 +---------------------------------------+ 938 |GRE key / MPLS Label rep. VRF(3 octets)| 939 +---------------------------------------+ 940 | Originating Rbridge's IP Address | 941 +---------------------------------------+ 942 | Originating Rbridge's MAC address | 943 | (8 octets) | 944 +---------------------------------------+ 946 The RD MUST be the RD of the MAC-VPN instance that is advertising the 947 NLRI. The procedures for setting the RD for a given MAC VPN are 948 described in section 8 in [3]. 950 The encoding of a MAC address is the 6-octet MAC address specified by 951 IEEE 802 documents [802.1D-ORIG] [802.1D-REV]. 953 If using the IP+GRE and/or IP+MPLS core networks the GRE key or MPLS 954 label MUST be the downstream assigned MAC-VPN GRE key or MPLS label 955 that is used by the N-PE to forward IP+GRE or IP+MPLS encapsulated 956 ethernet packets received from remote N-PEs, where the destination 957 MAC address in the ethernet packet is the MAC address advertised in 958 the above NLRI. The forwarding procedures are specified in previous 959 sections of this document. A N-PE may advertise the same MAC-VPN 960 label for all MAC addresses in a given MAC-VPN instance. Or a N-PE 961 may advertise a unique MAC-VPN label per MAC address. All of these 962 methodologies have their tradeoffs. 964 Per MAC-VPN instance label assignment requires the least number of 965 MAC-VPN labels, but requires a MAC lookup in addition to a GRE key or 966 MPLS lookup on an egress N-PE for forwarding. On the other hand a 967 unique label per MAC allows an egress N-PE to forward a packet that 968 it receives from another N-PE, to the connected CE, after looking up 969 only the GRE key or MPLS labels and not having to do a MAC lookup. 971 The Originating Rbridge's IP address MUST be set to an IP address of 972 the PE (U-PE or N-PE). This address SHOULD be common for all the 973 MAC-VPN instances on the PE (e.,g., this address may be PE's loopback 974 address). 976 2.7.2.1 Next hop field in MP_REACH_NLRI 978 The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 979 be set to the Nickname of the N-PE or in the case of the U-PE the 980 Area Nickname of the Rbridge one whose MAC address is carried in the 981 Originating Rbridge's MAC Address field. 983 The BGP advertisement that advertises the MAC advertisement route 984 MUST also carry one or more Route Target (RT) attributes. 986 It is to be noted that document [3] does not require N-PEs/U-PEs to 987 create forwarding state for remote MACs when they are learned in the 988 control plane. When this forwarding state is actually created is a 989 local implementation matter. However the proposal in this document 990 requires that forwarding state be established when these MAC routes 991 are learned in the control plane. 993 2.7.2.2 Route Reflectors for scaling 994 It is recommended that Route Reflectors SHOULD be deployed to mesh 995 the U-PEs in the sites with other U-PEs at other sites (belonging to 996 the same customer) and the transport network also have RRs to mesh 997 the N-PEs. This takes care of the scaling issues that may arise if 998 full mesh is deployed amongst U-PEs or the N-PEs. 1000 2.7.3 Multicast related ideas 1002 For the purpose of multicast it is possible that the IP core can have 1003 a PIM-bidir tree for each customer that will connect all the N-PEs 1004 related to a customer and carry the multicast traffic over the 1005 transport core thus connecting site to site multicast trees. This is 1006 of course out of the scope of this document. The authors intend to 1007 address this issue in future versions of this solution extended for 1008 multicast as well. 1010 3 Security Considerations 1012 TBD. 1014 4 IANA Considerations 1016 A few IANA considerations need to be considered at this point. A 1017 proper AFI-SAFI indicator would have to be provided to carry MAC 1018 addresses as NLRI with Next-hops as Rbridbge Nicknames. This one AFI- 1019 SAFI indicator could be used for both U-PE MP-iBGP sessions and N-PE 1020 MP-iBGP sessions. 1022 5 References 1024 5.1 Normative References 1026 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1027 Requirement Levels", BCP 14, RFC 2119, March 1997. 1029 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1030 1 1995. 1032 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 1033 April 1 1996. 1035 5.2 Informative References 1037 [1] draft-xl-trill-over-wan-00.txt, XiaoLan. Wan et.al 1038 December 11th ,2011 Work in Progress 1040 [2] draft-perlman-trill-rbridge-multilevel-03.txt, Radia 1041 Perlman et.al October 31, 2011 Work in Progress 1043 [3] draft-raggarwa-mac-vpn-01.txt, Rahul Aggarwal et.al, 1044 June 2010, Work in Progress. 1046 [4] draft-yong-trill-trill-o-mpls, Yong et.al, October 1047 2011, Work in Progress. 1049 [5] draft-raggarwa-sajassi-l2vpn-evpn Rahul Aggarwal 1050 et.al, September 2011, Work in Progress. 1052 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 1053 RFC 3514, April 1 2003. 1055 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 1056 Acronyms", RFC 5513, April 1 2009. 1058 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 1059 2009. 1061 Authors' Addresses 1063 Bhargav Bhikkaji, 1064 Dell-Force10, 1065 350 Holger Way, 1066 San Jose, CA 1067 U.S.A 1069 Email: Bhargav_Bhikkaji@dell.com 1071 Balaji Venkat Venkataswami, 1072 Dell-Force10, 1073 Olympia Technology Park, 1074 Fortius block, 7th & 8th Floor, 1075 Plot No. 1, SIDCO Industrial Estate, 1076 Guindy, Chennai - 600032. 1077 TamilNadu, India. 1078 Tel: +91 (0) 44 4220 8400 1079 Fax: +91 (0) 44 2836 2446 1081 EMail: BALAJI_VENKAT_VENKAT@dell.com 1083 Narayana Perumal Swamy, 1084 Dell-Force10, 1085 Olympia Technology Park, 1086 Fortius block, 7th & 8th Floor, 1087 Plot No. 1, SIDCO Industrial Estate, 1088 Guindy, Chennai - 600032. 1089 TamilNadu, India. 1090 Tel: +91 (0) 44 4220 8400 1091 Fax: +91 (0) 44 2836 2446 1092 Email: Narayana_Perumal@dell.com 1094 A.1 Appendix I 1096 A.1.1 Extract from Multi-level IS-IS draft made applicable to scheme 1098 In the following picture, RB2 and RB3 are area border RBridges. A 1099 source S is attached to RB1. The two areas have nicknames 15961 and 1100 15918, respectively. RB1 has a nickname, say 27, and RB4 has a 1101 nickname, say 44 (and in fact, they could even have the same 1102 nickname, since the RBridge nickname will not be visible outside the 1103 area). 1105 Pseudo 1106 Area 15961 level 2 Area 15918 1107 +-------------------+ +-----------------+ +--------------+ 1108 | | | IP Core network | | | 1109 | S--RB1---Rx--Rz----RB2--- ----RB3---Rk--RB4---D | 1110 | 27 | | . . | | 44 | 1111 | | |Pseudo-Interface | | | 1112 +-------------------+ +-----------------+ +--------------+ 1114 Here RB2 and RB3 are N-PEs. RB4 and RB1 are U-PEs. 1116 This sample topology could apply to Campus and data-center 1117 topologies. For Provider Backbone topologies S would fall outside the 1118 Area 15961 and RB1 would be the U-PE carrying the C-VLANs inside a P- 1119 VLAN for a specific customer. 1121 Let's say that S transmits a frame to destination D, which is 1122 connected to RB4, and let's say that D's location is learned by the 1123 relevant RBridges already. The relevant RBridges have learned the 1124 following: 1126 1) RB1 has learned that D is connected to nickname 15918 1127 2) RB3 has learned that D is attached to nickname 44. 1129 The following sequence of events will occur: 1131 - S transmits an Ethernet frame with source MAC = S and destination 1132 MAC = D. 1134 - RB1 encapsulates with a TRILL header with ingress RBridge = 27, 1135 and egress = 15918. 1137 - RB2 has announced in the Level 1 IS-IS instance in area 15961, 1138 that it is attached to all the area nicknames, including 15918. 1139 Therefore, IS-IS routes the frame to RB2. (Alternatively, if a 1140 distinguished range of nicknames is used for Level 2, Level 1 1141 RBridges seeing such an egress nickname will know to route to the 1142 nearest border router, which can be indicated by the IS-IS attached 1143 bit.) 1145 In the original draft on multi-level IS-IS the following happens and 1147 QUOTE... 1149 - RB2, when transitioning the frame from Level 1 to Level 2, 1150 replaces the ingress RBridge nickname with the area nickname, so 1151 replaces 27 with 15961. Within Level 2, the ingress RBridge field in 1152 the TRILL header will therefore be 15961, and the egress RBridge 1153 field will be 15918. Also RB2 learns that S is attached to nickname 1154 27 in area 15961 to accommodate return traffic. 1156 - The frame is forwarded through Level 2, to RB3, which has 1157 advertised, in Level 2, reachability to the nickname 15918. 1159 - RB3, when forwarding into area 15918, replaces the egress nickname 1160 in the TRILL header with RB4's nickname (44). So, within the 1161 destination area, the ingress nickname will be 15961 and the egress 1162 nickname will be 44. 1164 - RB4, when decapsulating, learns that S is attached to nickname 1165 15961, which is the area nickname of the ingress. 1167 Now suppose that D's location has not been learned by RB1 and/or RB3. 1168 What will happen, as it would in TRILL today, is that RB1 will 1169 forward the frame as a multi-destination frame, choosing a tree. As 1170 the multi-destination frame transitions into Level 2, RB2 replaces 1171 the ingress nickname with the area nickname. If RB1 does not know the 1172 location of D, the frame must be flooded, subject to possible 1173 pruning, in Level 2 and, subject to possible pruning, from Level 2 1174 into every Level 1 area that it reaches on the Level 2 distribution 1175 tree. 1177 UNQUOTE... 1179 In the current proposal that we outline in this document, the TRILL 1180 header is done away with completely in the IP+GRE or IP+MPLS core. A 1181 re-look into the inner headers after decapsulation gives the 1182 appropriate information to carry the frame from the N-PE towards the 1183 destination U-PE.