idnits 2.17.1 draft-hao-trill-irb-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 244 instances of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 532: '...wing APPsub-TLVs MUST be included in a...' RFC 2119 keyword, line 579: '...esv: 3 bits that MUST be sent as zero ...' RFC 2119 keyword, line 585: '...sv2: 4 bits that MUST be sent as zero ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 143 has weird spacing: '...gateway aka g...' -- The document date (October 15, 2014) is 3479 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC6325' on line 680 -- Looks like a reference, but probably isn't: 'IS-IS' on line 107 -- Looks like a reference, but probably isn't: 'RFC7176' on line 108 -- Looks like a reference, but probably isn't: 'RFC7172' on line 257 -- Looks like a reference, but probably isn't: 'RFC4861' on line 153 -- Looks like a reference, but probably isn't: 'RFC7356' on line 654 -- Looks like a reference, but probably isn't: 'RFC5310' on line 674 -- Looks like a reference, but probably isn't: 'RFC7357' on line 685 == Unused Reference: '1' is defined on line 718, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 700, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 704, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 712, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Weiguo Hao 2 Yizhou Li 3 Donald Eastlake 4 Liang Xia 5 Internet Draft Huawei 6 Andrew Qu 7 MediaTec 8 Muhammad Durrani 9 Brocade 10 Ponkarthick S. 11 IP Infusion 12 Intended status: Standards Track October 15, 2014 13 Expires: March 2015 15 TRILL Distributed Layer 3 Gateway 16 draft-hao-trill-irb-05.txt 18 Abstract 20 Currently TRILL protocol provides optimal pair-wise data frame forwarding for 21 layer 2 intra-subnet traffic but not for layer 3 inter-subnet traffic. A 22 centralized gateway solution is typically used for layer 3 inter-subnet traffic 23 forwarding but has following issues: 25 1. Sub-optimum forwarding path for inter-subnet traffic. 27 2. Huge number of gateway interfaces, 16 million in extreme case, need to be 28 supported on the centralized gateway. 30 3. Traffic bottleneck at the gateway. 32 An optional TRILL distributed gateway solution that resolves these centralized 33 gateway issues is specified in this document. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 38 and BCP 79. 40 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 41 and BCP 79. This document may not be modified, and derivative works of it may not 42 be created, and it may not be published except as an Internet-Draft. 44 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 45 and BCP 79. This document may not be modified, and derivative works of it may not 46 be created, except to publish it as an RFC and to translate it into languages 47 other than English. 49 Internet-Drafts are working documents of the Internet Engineering Task Force 50 (IETF), its areas, and its working groups. Note that other groups may also 51 distribute working documents as Internet-Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months and may be 54 updated, replaced, or obsoleted by other documents at any time. It is 55 inappropriate to use Internet-Drafts as reference material or to cite them other 56 than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 This Internet-Draft will expire on March 15, 2015. 66 Copyright Notice 68 Copyright (c) 2014 IETF Trust and the persons identified as the document authors. 69 All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 72 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents carefully, as they 74 describe your rights and restrictions with respect to this document. Code 75 Components extracted from this document must include Simplified BSD License text 76 as described in Section 4.e of the Trust Legal Provisions and are provided without 77 warranty as described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction ................................................ 3 82 2. Conventions Used in This Document............................ 3 83 3. Problem Statement ........................................... 4 84 4. Layer 3 Traffic Forwarding Model............................. 6 85 5. Distributed Gateway Solution Overview........................ 6 86 5.1. Local routing information............................... 7 87 5.2. Local routing information synchronization............... 8 88 5.3. Data traffic forwarding process......................... 8 89 6. Distributed Layer 3 Gateway Process Example.................. 9 90 6.1. Control plane process.................................. 10 91 6.2. Data plane process..................................... 11 92 7. TRILL Protocol Extensions................................... 12 93 7.1. The tenant gateway MAC APPsub-TLV...................... 12 94 7.2. The tenant Label APPsub-TLV............................ 13 95 7.3. The IPv4 Prefix APPsub-TLV............................. 14 96 7.4. The IPv6 Prefix APPsub-TLV............................. 15 97 8. Security Considerations..................................... 15 98 9. IANA Considerations ........................................ 16 99 10. Normative References....................................... 16 100 11. Informative References..................................... 16 101 12. Acknowledgments ........................................... 17 103 1. Introduction 105 The IETF has standardized the TRILL (Transparent Interconnection of Lots of Links) 106 protocol [RFC6325] that provides a solution for least cost transparent routing in 107 multi-hop networks with arbitrary topologies and link technologies, using [IS-IS] 108 [RFC7176] link-state routing and a hop count. TRILL switches are sometimes called 109 RBridges (Routing Bridges). 111 Currently, TRILL provides optimal unicast forwarding for Layer 2 intra-subnet 112 traffic but not for Layer 3 inter-subnet traffic. In this document, an optional 113 TRILL-based distributed Layer 3 gateway solution is specified to provide optimal 114 unicast forwarding for Layer 3 inter-subnet traffic. With distributed gateway 115 support an edge RBridge provides both routing based on Layer 2 identity (address 116 and virtual network (VN)) among end stations (ESs) that belong to same subnet and 117 routing based on Layer 3 identity among ESs that belong to different subnets of 118 the same routing domain. An edge RBridge needs to provide routing instances and 119 Layer 3 gateway interfaces for local connected ESs. The routing instances are for 120 IP address isolation between tenants. In the TRILL distributed Layer 3 gateway 121 solution, inter-subnet traffic can be fully dispersed among edge RBridges, so 122 there is no single bottleneck. 124 This document is organized as follows: Section 3 describes why a distributed 125 gateway solution is beneficial. Section 4 gives the Layer 3 traffic forwarding 126 model. Section 5 provides a distributed gateway solution overview. Section 6 gives 127 a distributed gateway example. And Section 7 describes the TRILL protocol 128 extensions needed to support this distributed gateway solution. 130 2. Conventions Used in This Document 132 The terms and acronyms in [RFC6325] are used with the following additions: 134 Data Label: VLAN or FGL [RFC7172]. 136 DCN: Data Center Network. 138 ES: End Station. VM (Virtual Machine) or physical server, whose address is 139 either the destination or source of a data frame. 141 GW: Gateway. 143 Gateway interface: Layer 3 virtual interface on gateway aka gateway 144 interface) terminates layer 2 forwarding and forwards IP traffic to the 145 destination as per IP forwarding rules. Incoming traffic from a physical port on a 146 gateway will be distributed to its virtual gateway interface based on Data Label 147 (VLAN or FGL). 149 L2: Layer 2. 151 L3: IP Layer 3. 153 ND: IPv6's Neighbor Discovery [RFC4861]. 155 RD: Routing Domain. 157 ToR: Top of Rack. 159 VN: Virtual Network. In a TRILL campus, each virtual network is identified 160 by a unique 12-bit VLAN ID or 24-bit Fine Grained Label [RFC7172]. 162 VRF: Virtual Routing and Forwarding. In IP-based computer networks, Virtual 163 Routing and Forwarding (VRF) is a technology that allows multiple instances of a 164 routing table to co-exist within the same router at the same time. 166 3. Problem Statement 168 ------- ------- 169 | GW1 | | GW2 | 170 ------- ------- 171 | | 172 ------- ------- 173 |AGG1 | |AGG2 | 174 ------- ------- 175 | | 176 ----------------------------------------------------- 177 | -------------|------------------|----------------| 178 | | | | | | | | 179 ------- ------- ------- ------- 180 |TOR1 | |TOR2 | |TOR3 | |TOR4 | 181 ------- ------- ------- ------- 182 | | | | | | | | 183 ---- ---- ---- ---- ---- ---- ---- ---- 184 |E | |E | |E | |E | |E | |E | |E | |E | 185 |S1| |S2| |S3| |S4| |S5| |S6| |S7| |S8| 186 ---- ---- ---- ---- ---- ---- ---- ---- 187 Figure 1 A typical DC network 189 Figure 1 depicts a Data Center Network (DCN) using TRILL where edge RBridges are 190 Top of Rack (ToR) switches. Centralized gateway GW1 and GW2 in figure 1 provide 191 the layer 3 packet forwarding for both north-south traffic and east-west inter- 192 subnet traffic between ESs. 194 End stations in one IP subnet expect to send IP traffic for a different subnet to 195 an IP router. In addition, there is normally a Data Label (VLAN or FGL) associated 196 with each IP subnet but there is no facility in TRILL to change the Data Label for 197 traffic between subnets. If two end stations of the same tenant are on two 198 different subnets and need to communicate with each other, their packets are 199 typically forwarded all the way to a centralized IP Layer 3 gateway to perform L3 200 forwarding and, if necessary, change the Data Label. This is generally sub-optimal 201 because the two end stations may be connected to the same ToR where L3 switching 202 could have been performed locally. For example, in above Figure 1, assuming ES1 203 (10.1.1.2 ) and ES2 (20.1.1.2) belong to different subnets of same tenant, the 204 unicast IP traffic between them has to go through a centralized gateway. It can't 205 be locally forwarded on TOR1. If an edge RBridge has distributed gateway 206 capabilities, then it can perform optimum L2 forwarding for intra-subnet traffic 207 and optimum L3 forwarding for inter-subnet traffic, delivering optimum forwarding 208 for unicast packets in all important cases. 210 When Fine Grained Label [RFC7172] is introduced, up to 16 million Layer 2 VN can 211 be supported in a TRILL campus. To support inter-subnet traffic, up to 16 million 212 Layer 3 gateway interfaces should be created on a centralized gateway if each VN 213 corresponds to a subnet. It is a huge burden for the centralized gateway to 214 support so many interfaces. In addition all inter-subnet traffic will go through 215 the centralized gateway that may become the traffic bottleneck. 217 In summary, the centralized gateway has the following issues: 219 1. Sub-optimum forwarding paths for inter-subnet traffic due to the 220 requirements to perform IP routing and possibly change Data Labels. 222 2. Huge number of gateway interfaces, 16 million in the extreme case, need to 223 be supported on the centralized gateway. 225 3. Traffic bottleneck at the gateway. 227 A distributed gateway on edge RBridges addresses these issues. 229 4. Layer 3 Traffic Forwarding Model 231 +---------------------------------------------+ 232 | | 233 | +-----------+ +-----------+ | 234 | | Tenant n |---------| VRF n | | 235 | +------------+ | +------------+ | | 236 | | +-----+ | | | | | | 237 | | | VN1 | | | | | | | 238 | | +-----+ | | | VRF 1 | | | 239 | | .. +-------+ | | | 240 | | +-----+ | | | | | | 241 | | | VNm | | | | | | | 242 | | +-----+ | | | | | | 243 | | Tenant 1 |-+ | | | | 244 | +------------+ | | | | 245 | +------------+ +------------+ | 246 | | 247 | Edge RBridge | 248 +---------------------------------------------+ 249 Figure 2 Edge RBridge Model as distributed GW 251 In a data center network (DCN), each tenant may include one or more Layer 2 252 virtual networks and, in normal cases, each tenant corresponds to one routing 253 domain (RD). Normally each Layer 2 virtual network uses a different Data Label and 254 corresponds to one or more subnets. 256 Each Layer 2 virtual network in a TRILL campus is identified by a unique 12-bit 257 VLAN ID or 24-bit Fine Grained Label [RFC7172]. Different routing domains may have 258 overlapping address space but need distinct and separate routes. The end stations 259 that belong to the same subnet communicate through L2 forwarding, end systems of 260 the same tenant that belong to different subnets communicate through L3 forwarding. 262 The above figure 2 depicts the model where there are N VRFs corresponding to N 263 tenants with each tenant having up to M segments/subnets (virtual network). 265 5. Distributed Gateway Solution Overview 267 In the TRILL distributed gateway scenario, an edge RBridge must perform Layer 2 268 routing for the ESs that are on the same subnet and IP routing for the ESs that 269 are on the different subnets of the same tenant. 271 As the IP address space in different routing domains can overlap, VRF instances 272 need to be created on each edge RBridge to isolate the IP forwarding process among 273 different routing domains present on the edge RBridge. A globally unique tenant ID 274 identifies each routing domain. The network operator should ensure the consistency 275 of the tenant ID on each edge RBridge for each routing domain. If a routing domain 276 spreads over multiple edge RBridges, routing information for the routing domain 277 should be synchronized among these edge RBridges to ensure the reachability to all 278 ESs in that routing domain. The Tenant ID should be carried with the routing 279 information to differentiate the routing domains. 281 From the data plane perspective, all edge RBridges are connected to each other via 282 one or multiple TRILL hops, however they are always a single IP hop away. When an 283 ingress RBridge receives inter-subnet traffic from a local ES whose destination 284 MAC is the edge RBridge's gateway MAC, that RBridge will perform Ethernet header 285 termination and look up in its IP forwarding table to forward the traffic to the 286 IP next hop. If the destination ES is connected to a remote edge RBridge, the 287 remote RBridge will be the IP next hop for traffic forwarding. The ingress RBridge 288 will perform TRILL encapsulation for such inter-subnet traffic and route it to the 289 remote RBridge through the TRILL campus. 291 When that remote RBridge receives the traffic, it will decapsulate the packet and 292 then lookup in the RBridge's IP forwarding table to route it to the destination ES. 293 Through this method, TRILL with distributed gateways provides pair-wise data 294 routing for inter-subnet traffic. 296 5.1. Local routing information 298 An ES can be locally connected to an edge RBridges through a layer 2 network or 299 externally connected through a layer 3 IP network. 301 If the ES is connected to an edge RBridge through a Layer 2 network, then the edge 302 RBridge must act as a Layer 3 GW for the ES. The gateway interface should be 303 established on the edge RBridge for the connecting ES. Because the ESs in the same 304 subnet may be spread over multiple edge RBridges, each of these edge RBridges 305 should establish its gateway interface for the subnet and these gateway interfaces 306 on different edge RBridges share the same gateway MAC and gateway IP address. 308 Before an ES starts to send inter-subnet traffic, it should acquire its gateway's 309 MAC through the ARP/ND process. Local connecting edge RBridges that are supporting 310 this distributed gateway feature always respond with the gateway MAC address when 311 receiving ARP/ND requests for the gateway IP. Through the ARP/ND process, the edge 312 RBridge can learn the IP and MAC correspondence of local ES connected to the edge 313 RBridge by Layer 2 and then generate local IP routing entries for the ES in the 314 corresponding routing domain. 316 If an ES is located in an external IP network, the ES also can be connected to the 317 TRILL campus through a TRILL edge RBridge. The TRILL edge RBridge runs a unified 318 routing protocol with the external IP network for each routing domain. The edge 319 RBridge learns the IP prefix corresponding to the ES through the IP routing 320 protocol, then the RBridge generates local IP routing entries in the corresponding 321 routing domain. 323 5.2. Local routing information synchronization 325 Each edge RBridge should announce its own tenant gateway MAC to the TRILL campus. 326 The tenant gateway MAC is to differentiate inter-subnet Layer 3 traffic or intra- 327 subnet Layer 2 traffic on an egress RBridge; the ingress RBridge will use the 328 tenant gateway MAC announced by the egress RBridge as the Inner.MacDA for inter- 329 subnet traffic TRILL encapsulation. All tenants on a RBridge can share the same 330 tenant gateway MAC for inter-subnet traffic purposes. 332 When a routing instance is created on an edge RBridge, the tenant ID, tenant Label 333 (VLAN or FGL), and their correspondence should be set and globally advertised. The 334 ingress RBridge uses the Label advertised by the egress RBridge as the inner VLAN 335 or FGL when it performs inter-subnet traffic TRILL encapsulation. The egress 336 RBridge relies on tenant Label to find the local VRF instance for the IP 337 forwarding process when receiving inter-subnet traffic from the TRILL campus. (The 338 role of tenant Label is akin to an MPLS VPN Label in an MPLS IP/MPLS VPN network.) 339 Tenant Labels are independently allocated on each edge RBridge for each routing 340 domain, an edge RBridge can pick up an access Label in a routing domain to act as 341 inter-subnet Label, or the edge RBridge can use a different Label from any access 342 Labels to act as tenant Label. It's implementation dependant and there is no 343 restriction on this. 345 When a local IP prefix is learned in a routing instance on an edge RBridge, the 346 edge RBridge should advertise the IP prefix information for the routing instance 347 to other edge RBridges to generate IP routing entries. A globally unique tenant ID 348 also should be carried to differentiate IP prefixes between different tenants, 349 because the IP address space of different tenants can overlap. 351 TRILL FS-LSP [rfc7180bis] extensions can be used for IP routing information 352 synchronization in each routing domain among edge RBridges. Based on the 353 synchronized information from other edge RBridges, each edge RBridge generates 354 remote IP routing entries in each routing domain. 356 Through this solution, intra-subnet forwarding function and inter-subnet IP 357 routing functions are integrated and network management and deployment will be 358 simplified. 360 5.3. Data traffic forwarding process 362 After a Layer 2 connected ES1 in VLAN-x acquires its gateway's MAC, it can start 363 inter-subnet data traffic process to ES2 in VLAN-y. When the local connecting edge 364 RBridge receives inter-subnet traffic from ES1, the RBridge performs Layer 2 365 header termination, then, using the local VRF corresponding to VLAN-x, it performs 366 the IP forwarding process in that VRF. 368 If destination ES2 is also attached to the ingress RBridge, the traffic will be 369 locally forwarded to ES2 on the ingress RBridge. Compared to the centralized 370 gateway solution, the forwarding path is optimal and a traffic detour is avoided. 372 If ES2 is attached to a remote edge RBridge, the remote edge RBridge is IP next 373 hop and the inter-subnet traffic is forwarded to the IP next hop through TRILL 374 encapsulation. If there are multiple equal cost shortest path between ingress 375 RBridge and egress RBridge, all these path can be used for inter-subnet traffic 376 forwarding, so pair-wise load spreading can be achieved for inter-subnet traffic. 378 When the remote RBridge receives the inter-subnet TRILL encapsulated traffic, the 379 RBridge decapsulates the TRILL encapsulation and checks the Inner.MacDA, if that 380 MAC address is the local gateway MAC corresponding to the inner Label (VLAN or 381 FGL), the inner Label will be used to find the corresponding local VRF, then the 382 IP forwarding process in that VRF will be performed, and the traffic will be 383 locally forwarded to the destination ES2. 385 In summary, through this solution, traffic detours to a central gateway are 386 avoided, both inter-subnet and intra-subnet traffic can be forwarded along pair- 387 wise shortest paths, and network bandwidth is conserved. 389 6. Distributed Layer 3 Gateway Process Example 391 --------- --------- 392 | RB3 | | RB4 | 393 --------- --------- 394 # * * 395 # ************************** 396 ########################### * 397 # * # * 398 # * # * 399 # * # * 400 --------- --------- 401 | RB1 | | RB2 | 402 --------- --------- 403 | | 404 ---- ---- 405 |E | |E | 406 |S1| |S2| 407 ---- ---- 408 Figure 3 Distributed gateway scenario 410 In figure 3 above, RB1 and RB2 support the distribution gateway function, ES1 411 connects to RB1, ES2 connects to RB2. ES1 and ES2 belong to Tenant1, but are in 412 different subnets. 414 The IP address, VLAN, and subnet information of ES1 and ES2 are as follows: 416 +----+---------+----------------+---------------+----------+ 417 | ES | Tenant | IP Address | Subnet | VLAN | 418 +----+---------+----------------+---------------+----------+ 419 | ES1| Tenant1 | 10.1.1.2 | 10.1.1.1/32 | 10 | 420 +----+---------+----------------+---------------+----------+ 421 | ES2| Tenant1 | 20.1.1.2 | 20.1.1.1/32 | 20 | 422 +----+---------+----------------+---------------+----------+ 423 Figure 4 ES information 425 The nickname, VRF, tenant VLAN, tenant gateway MAC for Tenant1 on RB1 and RB2 are 426 as follows: 428 +----+---------+----------+-------+--------------+--------------+ 429 | RB | Nickname| Tenant | VRF | Tenant VLAN | Gateway MAC | 430 +----+---------+----------+-------+--------------+--------------+ 431 | RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 | 432 +----+---------+----------+-------+--------------+--------------+ 433 | RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 | 434 +----+---------+----------+-------+--------------+--------------+ 435 Figure 5 RBridge information 437 6.1. Control plane process 439 RB1 announces the following local routing information to the TRILL campus: 441 Tenant ID: 1 443 Tenant gateway MAC: MAC1. 445 Tenant VLAN for Tenant1: VLAN 100. 447 IP prefix in Tenant1: 10.1.1.2/32. 449 RB2 announces the following local routing information to TRILL campus: 451 Tenant ID: 1 453 Tenant gateway MAC: MAC2. 455 Tenant VLAN for Tenant1: VLAN 100. 457 IP prefix in Tenant1: 20.1.1.2/32. 459 Relying on the routing information from RB2, remote routing entries on RB1 are 460 generated as follows: 462 +--------------+-------------+--------------+----------------+ 463 | Prefix/Mask | Inner.MacDA | inner VLAN | egress nickname| 464 +--------------+-------------+--------------+----------------+ 465 | 20.1.1.2/32 | MAC2 | 100 | nick2 | 466 +--------------+-------------+--------------+----------------+ 467 Figure 6 Tenant 1 remote routing table on RB1 469 Similarly, relying on the routing information from RB1, remote routing entries on 470 RB2 are generated as follows: 472 +-----------+-------------+-----------+---------------+ 473 |Prefix/Mask| Inner.MacDA |inner VLAN |egress nickname| 474 +-----------+-------------+-----------+---------------+ 475 |10.1.1.2/32| MAC1 | 100 | nick1 | 476 +-----------+-------------+-----------+---------------+ 477 Figure 7 Tenant 1 remote routing table on RB1 479 6.2. Data plane process 481 Assuming ES1 sends unicast inter-subnet traffic to ES2, the traffic forwarding 482 process is as follows: 484 1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's gateway's MAC as the 485 destination MAC. 487 2. Ingress RBridge (RB1) forwarding process: 489 RB1 checks the destination MAC, if the destination MAC equals the local gateway 490 MAC, the gateway function will terminate the Layer 2 header and perform L3 491 forwarding process. 493 RB1 looks up IP routing table information by destination IP and Tenant ID to get 494 IP next hop information, which includes the egress RBridge's gateway MAC (MAC2), 495 tenant VLAN (VLAN 100) and egress nickname (nick2). Using this information, RB1 496 will perform inner Ethernet header encapsulation and TRILL encapsulation. RB1 will 497 use MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as the Inner.MacSA, VLAN 498 100 as the Inner.VLAN, nick2 as the egress nickname and nick1 as the ingress 499 nickname. 501 RB1 looks up TRILL forwarding table by egress nickname and sends the traffic to 502 the TRILL next hop as per [RFC6325]. The traffic will be sent to RB3 or RB4 as 503 result of load balancing. 505 Assuming the traffic is forwarded to RB3, the following occurs: 507 3. Transit RBridge (RB3) forwarding process: 509 RB3 looks up TRILL forwarding information by egress nickname and forwards the 510 traffic to RB2 as per [RFC6325]. 512 4. Egress RBridge forwarding process: 514 As the egress nickname is RB2's own nickname, RB2 performs TRILL decapsulation. 515 Then it checks the Inner.MacDA and, because that MAC is equal to the local gateway 516 MAC, performs inner Ethernet header termination. Relying on inner VLAN, RB2 finds 517 the local corresponding VRF and looks up the packets destination IP address in the 518 VRF's IP routing table. The traffic is then be locally forwarded to ES2. 520 7. TRILL Protocol Extensions 522 If an edge RBridge RB1 participates in the distributed gateway function, it should 523 announce its tenant gateway MAC, tenant Label and IPv4/IPv6 prefix to the TRILL 524 campus through the tenant gateway MAC APPsub-TLV, tenant Label APPsub-TLV and 525 IPv4/IPv6 prefix APPsub-TLV. Other edge RBridges belonging to the same routing 526 domain use this information to generate IP routing entries in that routing domain. 527 The ingress RBridge uses the tenant gateway MAC and tenant Label of the egress 528 RBridge to perform inter-subnet traffic TRILL encapsulation when it receives 529 inter-subnet traffic from a local ES. The tenant gateway MAC is used as the 530 Inner.MacDA and the tenant Label is used as the Inner.Label. 532 The following APPsub-TLVs MUST be included in a TRILL GENINFO TLV in FS-LSPs 533 [rfc7180bis]. 535 7.1. The tenant gateway MAC APPsub-TLV 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | (2 bytes) 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Length | (2 bytes) 541 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 542 | Tenant gateway MAC | (6 bytes) 543 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ 545 o Type: Set to TENANT-GWMAC sub-TLV (TBD1). Two bytes, because this APPsub- 546 TLV appears in an extended TLV [RFC7356]. 548 o Length: 6. 550 o Tenant gateway MAC: The local tenant gateway MAC for inter-subnet traffic 551 forwarding. 553 7.2. The tenant Label APPsub-TLV 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type | (2 bytes) 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Length | (2 bytes) 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Tenant ID (4 bytes) | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |L|Resv| Label1 | (2 bytes) 563 +-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Resv2| Label2 | (2 bytes) 565 +-+-+-+-+-+-+-+-+-+-+-+-+ 567 o Type: Set to TENANT-LABEL sub-TLV (TBD2). Two bytes, because this APPsub- 568 TLV appears in an extended TLV [RFC7356]. 570 o Length: If Label1 field is used to represent a VLAN, the value of the 571 length field is 12. If Label1 and Label2 field are used to represent an FGL, the 572 value of the length field is 14. 574 o Tenant ID: This identifies a global tenant ID. 576 o L: 1 bit. When Label1 and Label2 field are used to identify an FGL, this 577 bit is set to 1. When Label1 field is used to identify a VLAN, it is set to 0. 579 o Resv: 3 bits that MUST be sent as zero and ignored on receipt. 581 o Label1: If the value of length field is 12, the field is to identify tenant 582 VLAN ID. If the value of length field is 14, the field is to identify higher 12 583 bits of tenant FGL. 585 o Resv2: 4 bits that MUST be sent as zero and ignored on receipt. Only 586 present if the length field is 14. 588 o Label2: This field has the lower 12 bits of tenant FGL. Only present if the 589 length field is 14. 591 7.3. The IPv4 Prefix APPsub-TLV 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | (2 bytes) 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Total Length | (2 bytes) 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 598 | Tenant ID |(4 bytes) 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 600 | Prefix Length(1)|(1 byte) 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 602 | Prefix (1) |(variable) 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 604 | ..... |(1 byte) 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 606 | ..... |(variable) 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 608 | Prefix Length(N)|(1 byte) 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 610 | Prefix (N) |(variable) 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 613 o Type: Set to IPV4-PREFIX sub-TLV (TBD3). Two bytes, because this APPsub- 614 TLV appears in an extended TLV [RFC7356]. 616 o Total Length: This 2-byte unsigned integer indicates the total length of 617 Tenant ID, Prefix Length and Prefix fields in octets. A value of 0 indicates that 618 no IPv4 prefix is being advertised. 620 o Tenant ID: This identifies a global tenant ID. 622 o Prefix Length: The Prefix Length field indicates the length in bits of 623 the IPv4 address prefix. A length of zero indicates a prefix that 625 matches all IPv4 addresses (with prefix, itself, of zero octets). 627 o Prefix: The Prefix field contains an IPv4 address prefix, followed by 628 enough trailing bits to make the end of the field fall on an octet boundary. Note 629 that the value of the trailing bits is irrelevant. 631 7.4. The IPv6 Prefix APPsub-TLV 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type | (2 bytes) 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Total Length | (2 bytes) 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 638 | Tenant ID |(4 bytes) 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 640 | Prefix Length(1)|(1 byte) 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 642 | Prefix (1) |(variable) 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 644 | ..... |(1 byte) 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 646 | ..... |(variable) 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 648 | Prefix Length(N)|(1 byte) 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 650 | Prefix (N) |(variable) 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 653 o Type: Set to IPV6-PREFIX sub-TLV (TBD4). Two bytes, because this APPsub- 654 TLV appears in an extended TLV [RFC7356]. 656 o Total Length: This 2-byte unsigned integer indicates the total length of 657 Tenant ID, Prefix Length and Prefix fields in octets. A value of 0 indicates that 658 no IPv6 prefix is being advertised. 660 o Tenant ID: This identifies a global tenant ID. 662 o Prefix Length: The Prefix Length field indicates the length in bits of 663 the IPv6 address prefix. A length of zero indicates a prefix that matches all 664 IPv6 addresses (with prefix, itself, of zero octets). 666 o Prefix: The Prefix field contains an IPv6 address prefix, followed by 667 enough trailing bits to make the end of the field fall on an octet boundary. Note 668 that the value of the trailing bits is irrelevant. 670 8. Security Considerations 672 Correct configuration of the edge RBridges participating is important to assure 673 that data is not delivered to the wrong tenant, which would violate security 674 constrains. IS-IS security [RFC5310] can be used to secure the information 675 advertised by the edge RBridges. 677 Particularly sensitive data should be encrypted end-to-end, that is, from the 678 source end station to the destination end station. 680 For general TRILL Security Considerations, see [RFC6325]. 682 9. IANA Considerations 684 IANA is requested to assign four APPsub-TLV type numbers less than 255 under the 685 TRILL GENINFO TLV [RFC7357] as follows: 687 Type Name References 688 ---- ---------------- ------------ 690 TBD1 TENANT-GWMAC [this document] 691 TBD2 TENANT-LABEL [this document] 692 TBD3 IPV4-PREFIX [this document] 693 TBD4 IPV6-PREFIX [this document] 695 10. Normative References 697 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 698 Levels", BCP 14, RFC 2119, March 1997. 700 [2] [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S.,and A. Ghanwani, 701 "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 702 2011. 704 [3] [RFC7172] Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, "TRILL 705 (Transparent Interconnection of Lots of Links): Fine-Grained Labeling", 706 RFC7172, May 2014. 708 [4] [RFC7176] - Eastlake, D., T. Senevirathne, A. Ghanwani, D. Dutt and A. 709 Banerjee" Transparent Interconnection of Lots of Links (TRILL) Use of IS- 710 IS", RFC7176, May 2014. 712 [5] [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, 713 "Transparent Interconnection of Lots of Links (TRILL): End Station Address 714 Distribution Information (ESADI) Protocol", RFC 7357, September 2014. 716 11. Informative References 718 [1] [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. 719 Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 720 2009. 722 12. Acknowledgments 724 The authors wish to acknowledge the important contributions of 726 Guangrui Wu, Zhenbin Li, Zhibo Hu. 728 Authors' Addresses 729 Weiguo Hao 730 Huawei Technologies 731 101 Software Avenue, 732 Nanjing 210012 733 China 734 Phone: +86-25-56623144 735 Email: haoweiguo@huawei.com 737 Yizhou Li 738 Huawei Technologies 739 101 Software Avenue, 740 Nanjing 210012 741 China 742 Phone: +86-25-56625375 743 Email: liyizhou@huawei.com 745 Donald E. Eastlake 746 Huawei Technologies 747 155 Beaver Street 748 Milford, MA 01757 USA 750 Phone: +1-508-333-2270 751 EMail: d3e3e3@gmail.com 753 Liang Xia(Frank) 754 Huawei Technologies 755 101 Software Avenue, 756 Nanjing 210012 757 China 758 Phone: +86-25-56624539 759 Email: frank.xialiang@huawei.com 761 Andrew Qu 762 MediaTec 763 Email: laodulaodu@gmail.com 765 Muhammad Durrani 766 Brocade 767 130 Holger Way 768 San Jose, CA 95134 769 EMail: mdurrani@brocade.com 770 Ponkarthick Sivamurugan 771 Address: IP Infusion, 772 RMZ Centennial 773 Mahadevapura Post 774 Bangalore - 560048 775 EMail: Ponkarthick.sivamurugan@ipinfusion.com