idnits 2.17.1 draft-ietf-trill-irb-14.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2016) is 2847 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group W. Hao 2 INTERNET-DRAFT Y. Li 3 Intended Status: Standard Track Huawei 4 A. Qu 5 MediaTec 6 M. Durrani 7 Cisco 8 P. Sivamurugan 9 IP Infusion 10 Expires: January 4, 2017 July 4, 2016 12 TRILL Distributed Layer 3 Gateway 13 draft-ietf-trill-irb-14.txt 15 Abstract 17 The base TRILL (Transparent Interconnection of Lots of Links) 18 protocol provides optimal pair-wise data frame forwarding for layer 19 2 intra-subnet traffic but not for layer 3 inter-subnet traffic. A 20 centralized gateway solution is typically used for layer 3 inter- 21 subnet traffic forwarding but has the following issues: 23 1. Sub-optimum forwarding paths for inter-subnet traffic. 25 2. A centralized gateway may need to support a very large 26 number of gateway interfaces in a data center, one per tenant per 27 data label used by that tenant, to provide interconnect 28 functionality for all the layer 2 virtual networks in a TRILL campus. 30 3. A traffic bottleneck at the gateway. 32 This document specifies an optional TRILL distributed gateway 33 solution that resolves these centralized gateway issues. 35 Status of this Memo 37 This Internet-Draft is submitted 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 Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction ................................................ 3 73 1.1. Document Organization................................... 3 74 2. Conventions used in this document............................ 4 75 3. Simplified Example and Problem Statement..................... 5 76 3.1. Simplified Example...................................... 6 77 3.2. Problem Statement Summary............................... 8 78 4. Layer 3 Traffic Forwarding Model............................. 9 79 5. Distributed Gateway Solution Details......................... 9 80 5.1. Local Routing Information .............................. 10 81 5.2. Local Routing Information Synchronization .............. 11 82 5.3. Active-active Access ................................... 14 83 5.4. Data Traffic Forwarding Process ........................ 14 84 6. Distributed Layer 3 Gateway Process Example ................. 15 85 6.1. Control plane process .................................. 16 86 6.2. Data Plane Process ..................................... 17 87 7. TRILL Protocol Extensions ................................... 18 88 7.1. The Tenant Label and Gateway MAC APPsub-TLV ............ 19 89 7.2. "SE" Flag in NickFlags APPsub-TLV ...................... 20 90 7.3. The IPv4 Prefix APPsub-TLV ............................. 20 91 7.4. The IPv6 Prefix APPsub-TLV ............................. 21 93 8. Security Considerations ..................................... 22 94 9. Management Considerations ................................... 22 95 10. IANA Considerations ........................................ 23 96 11. Normative References ....................................... 23 97 12. Informative References ..................................... 24 98 Acknowledgments ............................................... 25 99 Authors' Addresses ............................................ 25 101 1. Introduction 103 The TRILL (Transparent Interconnection of Lots of Links) protocol 104 [RFC6325] provides a solution for least cost transparent routing in 105 multi-hop networks with arbitrary topologies and link technologies, 106 using [IS-IS] [RFC7176] link-state routing and a hop count. TRILL 107 switches are sometimes called RBridges (Routing Bridges). 109 The base TRILL protocol provides optimal unicast forwarding for 110 Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet 111 traffic, where subnet means different IP address prefix and 112 typically a different Data Label (VLAN or FGL (Fine Grained Label)). 113 In this document, a TRILL-based distributed Layer 3 gateway solution 114 is specified that provides optimal unicast forwarding for Layer 3 115 inter-subnet traffic. With distributed gateway support, an edge 116 RBridge provides both routing based on Layer 2 identity (address and 117 virtual network (VN, i.e., Data Label)) among end stations (ESs) 118 that belong to same subnet and also provides routing based on Layer 119 3 identity among ESs that belong to different subnets of the same 120 routing domain. An edge RBridge supporting this feature needs to 121 provide routing instances and Layer 3 gateway interfaces for locally 122 connected ESs. Such routing instances provide IP address isolation 123 between tenants. In the TRILL distributed Layer 3 gateway solution, 124 inter-subnet traffic can be fully spread over edge RBridges, so 125 there is no single bottleneck. 127 1.1. Document Organization 129 This document is organized as follows: Section 3 gives a simplified 130 example and also a more detailed problem statement. Section 4 gives 131 the Layer 3 traffic forwarding model. Section 5 provides a 132 distributed gateway solution overview. Section 6 gives a detailed 133 distributed gateway solution example. And Section 7 describes the 134 TRILL protocol extensions needed to support this distributed gateway 135 solution. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 The terms and acronyms in [RFC6325] are used with the following 144 additions: 146 AGG: Aggregation switch. 148 ARP: Address Resolution Protocol [RFC826]. 150 Campus: The name for a network using the TRILL protocol in the 151 same sense that a ''bridged LAN'' is the name for a network using 152 bridging. In TRILL, the word ''campus'' has no academic implication. 154 COR: Core switch. 156 Data Label: VLAN or FGL [RFC7172]. 158 DC: Data Center. 160 Edge RBridge: An RBridges that connects to one or more End 161 Stations without any intervening RBridges. 163 FGL: Fine Grained Label [RFC7172]. 165 ES: End Station. A VM (Virtual Machine) or physical server, 166 whose address is either the destination or source of a data frame. 168 Gateway interface: A Layer 3 virtual interface that terminates 169 layer 2 forwarding and forwards IP traffic to the destination using 170 IP forwarding rules. Incoming traffic from a physical port on a 171 gateway will be distributed to its virtual gateway interface based 172 on Data Label (VLAN or FGL). 174 Inner.MacDA: The inner MAC destination address in a TRILL Data 175 packet [RFC6325]. 177 Inner.MacSA: The inner MAC source address in a TRILL Data 178 packet [RFC6325]. 180 Inner.VLAN: The inner VLAN tag in a TRILL Data packet payload 181 [RFC6325]. 183 L2: Layer 2. 185 L3: IP Layer 3. 187 ND: IPv6's Neighbor Discovery [RFC4861]. 189 ToR: Top of Rack. 191 VN: Virtual Network. In a TRILL campus, a unique 12-bit VLAN 192 ID or a 24-bit Fine Grained Label [RFC7172] identifies each virtual 193 network. 195 VRF: Virtual Routing and Forwarding. In IP-based computer 196 networks, Virtual Routing and Forwarding (VRF) technology supports 197 multiple instances of routing tables existing within the same router 198 at the same time. 200 3. Simplified Example and Problem Statement 202 There is normally a Data Label (VLAN or FGL) associated with each IP 203 subnet. For traffic within a subnet, that is IP traffic to another 204 end station in the same Data Label attached to the TRILL campus, the 205 end station just ARPs for the MAC address of the destination end 206 station's IP. It then uses this MAC address for traffic to that 207 destination. TRILL routes the ingressed TRILL data packets to the 208 destination's edge RBridge based on the egress nickname for that 209 destination MAC address and Data Label. This is the regular TRILL 210 base protocol [RFC6325] process. 212 If two end stations of the same tenant are on different subnets and 213 need to communicate with each other, their packets are typically 214 forwarded to an IP Layer 3 gateway that performs L3 routing and, if 215 necessary, changes the Data Label. Either a centralized layer 3 216 gateway solution or the distributed layer 3 gateway solution 217 specified in this document can be used for the inter-subnet traffic 218 forwarding. 220 Section 3.1 gives a simplified example in a TRILL campus with and 221 without a distributed layer 3 gateway using VLAN Data Labels. 222 Section 3.2 gives the detailed description of the problem without a 223 distributed layer 3 gateway. The remainder of this document, 224 particularly Section 5, describes the distributed gateway solution 225 in detail. 227 3.1. Simplified Example 228 ------- -------- 229 | COR1| | COR2 | 230 ------- -------- 231 | | 232 ------- ------- 233 |AGG1 | |AGG2 | 234 ------- ------- 235 | | 236 ----------------------------------------------------- 237 | -------------|------------------|----------------| 238 | | | | | | | | 239 ------- ------- ------- ------- 240 | RB1 | | RB2 | | RB3 | | RB4 | 241 |TOR1 | |TOR2 | |TOR3 | |TOR4 | 242 ------- ------- ------- ------- 243 | | | | | | | | 244 ----- ----- ----- ----- ----- ----- ----- ----- 245 |ES1| |ES2| |ES3| |ES4| |ES5| |ES6| |ES7| |ES8| 246 ----- ----- ----- ----- ----- ----- ----- ----- 247 Figure 1. A Typical TRILL DC Network 249 Figure 1 depicts a TRILL Data Center Network where Top of Rack (ToR) 250 switches are edge RBridges and the aggregation (AGG) and core (COR) 251 switches are non-edge RBridges. ES1 to ES8 belong to one tenant 252 network and the tenant has four subnets with each subnet 253 corresponding to one VLAN (which indicates one individual layer 2 254 virtual network). Each ES's IP address, VLAN and subnet are listed 255 below: 257 +----+----------------+-----------------+----------+ 258 | ES | IP Address | Subnet | VLAN | 259 +----+----------------+-----------------+----------+ 260 | ES1| 192.0.2.2 | 192.0.2.0/24 | 10 | 261 +----+----------------+-----------------+----------+ 262 | ES2| 198.51.100.2 | 198.51.100.0/24 | 11 | 263 +----+----------------+-----------------+----------+ 264 | ES3| 192.0.2.3 | 192.0.2.0/24 | 10 | 265 +----+----------------+-----------------+----------+ 266 | ES4| 198.51.100.3 | 198.51.100.0/24 | 11 | 267 +----+----------------+-----------------+----------+ 268 | ES5| 203.0.113.2 | 203.0.113.0/25 | 12 | 269 +----+----------------+-----------------+----------+ 270 | ES6| 203.0.113.130 | 203.0.113.128/25| 13 | 271 +----+----------------+-----------------+----------+ 272 | ES7| 203.0.113.3 | 203.0.113.0/25 | 12 | 273 +----+----------------+-----------------+----------+ 274 | ES8| 203.0.113.131 | 203.0.113.128/25| 13 | 275 +----+----------------+-----------------+----------+ 276 Assume a centralized gateway solution is used with both COR1 and 277 COR2 acting as centralized gateways for redundancy in figure 1. COR1 278 and COR2 each have four gateway interfaces for the four subnets in 279 the tenant. In centralized layer 3 gateway solution, all traffic 280 within the tenant between different VLANs must go through the 281 centralized layer 3 gateway device of COR1 or COR2, even if the 282 traffic is between two end stations connected to the same edge 283 RBridge, because only the layer 3 gateway can change the VLAN 284 labeling of the traffic. 286 This is generally sub-optimal because the two end stations may be 287 connected to the same ToR where L3 switching could have been 288 performed locally. For example, in above Figure 1, the unicast IP 289 traffic between ES1 and ES2 has to go through a centralized gateway 290 of COR1 or COR2. It can't be locally routed between them on TOR1. 291 However, if an edge RBridge has the distributed gateway capabilities 292 specified in this document, then it can still perform optimum L2 293 forwarding for intra-subnet traffic and, in addition, optimum L3 294 forwarding for inter-subnet traffic, thus delivering optimum 295 forwarding for unicast packets in all important cases. 297 With a distributed layer 3 gateway, each edge RBridge acts as a 298 default layer 3 gateway for local connecting ESs and has IP router 299 capabilities to direct IP communications to other edge RBridges. 300 Each edge RBridge only needs gateway interfaces for local connecting 301 ESs, i.e., RB1 and RB2 need gateway interfaces only for VLAN 10 and 302 VLAN 11 while RB3 and RB4 need gateway interfaces only for VLAN 12 303 and VLAN 13. No device needs to maintain gateway interfaces for all 304 VLANs in entire network. This will enhance the scalability in terms 305 of number of tenants and subnets per tenant. 307 When each end station ARPs for their layer 3 gateway, that is, their 308 IP router, the edge RBridge to which it is connected will respond 309 with that RBridge's 'gateway MAC'. When the end station later sends 310 IP traffic to the layer 3 gateway, which it does if the destination 311 IP is outside of its subnet, the edge RBridge intercepts the IP 312 packet because the destination MAC is its gateway MAC. That RBridge 313 routes the IP packet using the routing instance associated with that 314 tenant, handling it in one of three ways: 316 (1) ES1 communicates with ES2. The destination IP is 317 connected to the same edge RBridge, the RBridge of TOR1 can simply 318 transmit the IP packet out the right edge port in the destination 319 VLAN. 321 (2) If the destination IP is located in an outside network, 322 the edge RBridge encapsulates it as a TRILL Data packet and sends it 323 to the actual TRILL campus edge RBridge connecting to an external IP 324 router. 326 (3) ES1 communicates with ES4. The destination end station 327 is connected to a different edge RBridge, the ingress RBridge TOR1 328 uses TRILL encapsulation to route the IP packet to the correct 329 egress RBridge TOR2, using the egress RBridge's gateway MAC and an 330 Inner.VLAN identifying the tenant. Finally, the egress RBridge 331 terminates the TRILL encapsulation and routes the IP packet to the 332 destination end station based on the routing instance for that 333 tenant. 335 3.2. Problem Statement Summary 337 With Fine Grained Labeling [RFC7172], in theory, up to 16 million 338 Layer 2 VN can be supported in a TRILL campus. To support inter- 339 subnet traffic, a very large number of Layer 3 gateway interfaces 340 could be needed on a centralized gateway, if each VN corresponds to 341 a subnet and there are many tenant with many subnets per tenant. It 342 is a big burden for the centralized gateway to support so many 343 interfaces. In addition all inter-subnet traffic will go through a 344 centralized gateway that may become the traffic bottleneck. 346 The centralized gateway has the following issues: 348 1. Sub-optimum forwarding paths for inter-subnet traffic 349 due to the requirements to perform IP routing and possibly change 350 Data Labels at a centralized gateway. 352 2. The centralized gateway may need to support a very large 353 number of gateway interfaces, in a data center one per tenant per 354 data label used by that tenant, to provide interconnect 355 functionality for all the layer 2 virtual networks in the TRILL 356 campus. 358 3. There may be a traffic bottleneck at the centralized 359 gateway. 361 A distributed gateway on edge RBridges addresses these issues. 362 Through the distributed layer 3 gateway solution, the inter-subnet 363 traffic is fully dispersed and is transmitted along optimal pair- 364 wise forwarding paths, improving network efficiency. 366 4. Layer 3 Traffic Forwarding Model 368 +---------------------------------------------+ 369 | | 370 | +-----------+ +-----------+ | 371 | | Tenant n |---------| VRF n | | 372 | +------------+ | +------------+ | | 373 | | +-----+ | | | | | | 374 | | | VN1 | | | | | | | 375 | | +-----+ | | | VRF 1 | | | 376 | | .. +-------+ | | | 377 | | +-----+ | | | | | | 378 | | | VNm | | | | | | | 379 | | +-----+ | | | | | | 380 | | Tenant 1 |-+ | | | | 381 | +------------+ | | | | 382 | +------------+ +------------+ | 383 | | 384 | Edge RBridge | 385 +---------------------------------------------+ 387 Figure 2. Edge RBridge Model as Distributed Gateway 389 In a data center network, each tenant has one or more Layer 2 390 virtual networks and, in normal cases, each tenant corresponds to 391 one routing domain. Normally each Layer 2 virtual network uses a 392 different Data Label and corresponds to one or more IP subnets. 394 Each Layer 2 virtual network in a TRILL campus is identified by a 395 unique 12-bit VLAN ID or 24-bit Fine Grained Label [RFC7172]. 396 Different routing domains may have overlapping address space but 397 need distinct and separate routes. The end stations that belong to 398 the same subnet communicate through L2 forwarding, end stations of 399 the same tenant that belong to different subnets communicate through 400 L3 routing. 402 Figure 2 depicts the model where there are n VRFs corresponding to n 403 tenants with each tenant having up to m segments/subnets (virtual 404 network). 406 5. Distributed Gateway Solution Details 408 With the TRILL distributed gateway solution, an edge RBridge 409 continues to perform routing based on the Layer 2 MAC address for 410 the ESs that are on the same subnet but performs IP routing for the 411 ESs that are on the different subnets of the same tenant. 413 As the IP address space in different routing domains can overlap, 414 VRF instances need to be created on each edge RBridge to isolate the 415 IP forwarding process for different routing domains present on the 416 edge RBridge. A tenant ID unique across the TRILL campus identifies 417 each routing domain. The network operator MUST configure the tenant 418 IDs on each edge RBridge for each routing domain consistently so 419 that the same ID always refers to the same tenant. Otherwise data 420 might be delivered to the wrong tenant. If a routing domain spreads 421 over multiple edge RBridges, routing information for the routing 422 domain is synchronized among these edge RBridges through the link 423 state database to ensure reachability to all ESs in that routing 424 domain. The routing information is, in effect, labeled with the 425 Tenant ID to differentiate the routing domains. 427 From the data plane perspective, all edge RBridges are connected to 428 each other via one or more TRILL hops, however they are always just 429 a single IP hop away. When an ingress RBridge receives inter-subnet 430 IP traffic from a local ES whose destination MAC is the edge 431 RBridge's gateway MAC, that RBridge will perform Ethernet header 432 termination. The tenant involved is determined by the VLAN of the 433 traffic and the port on which it arrives. The edge RBridge looks up 434 in its IP routing table for that tenant how to route the traffic to 435 the IP next hop. If the destination ES is connected to a remote edge 436 RBridge, the remote RBridge will be the IP next hop for traffic 437 forwarding. For such inter-subnet traffic, the ingress RBridge will 438 rewrite the original Ethernet header with the ingress RBridge's 439 gateway MAC address as the Inner.MacSA and the egress RBridge's 440 gateway MAC address as the Inner.MacDA and then perform TRILL 441 encapsulation to the remote RBridge's nickname setting the inner 442 Data Label to indicate the tenant involved. TRILL then routes it to 443 the remote edge RBridge through the TRILL campus. 445 When that remote edge RBridge receives the traffic, it will 446 decapsulate the TRILL data packet and see that the inner destination 447 MAC is its gateway MAC. It then terminates the inner Ethernet 448 encapsulation and looks up the destination IP in the RBridge's IP 449 forwarding table for the tenant indicated by the inner Data Label to 450 route it to the destination ES. 452 Through this method, TRILL with distributed gateways provides 453 optimum pair-wise data routing for inter-subnet traffic. 455 5.1. Local Routing Information 457 An ES can be locally connected to an edge RBridges through a layer 2 458 network (such as a point-to-point Ethernet link or a bridged LAN) or 459 externally connected through a layer 3 IP network. 461 If the ES is connected to an edge RBridge through a Layer 2 network, 462 then the edge RBridge acts as a Layer 3 Gateway for the ES. A 463 gateway interface is established on the edge RBridge for the 464 connecting ES. Because the ESs in a subnet may be spread over 465 multiple edge RBridges, in each of these edge RBridges which 466 establishes its gateway interface for the subnet the edge RBridges 467 SHOULD share the same gateway MAC and gateway IP address 468 configuration. Sharing the configuration and insuring configuration 469 consistency can be done by local configuration and netconf/Yang 470 models. 472 With distributed gateway, the edge RBridge to which an end station 473 is connected appears to be the local IP router on its link. As in 474 any IP network, before the end station starts to send inter-subnet 475 traffic, it acquires its gateway's MAC through the ARP/ND process. 476 Local connecting edge RBridges that support this distributed gateway 477 feature always respond with the gateway MAC address when receiving 478 ARP/ND requests for the gateway IP. Through the ARP/ND process, the 479 edge RBridge can learn the IP and MAC correspondence of a local ES 480 connected to the edge RBridge by Layer 2 and then generate local IP 481 routing entries for that ES in the corresponding routing domain. 483 An IP router connected to an edge RBridge looks to TRILL like an ES. 484 If a router/ES is located in an external IP network, normally it 485 provides access to one or more IP prefixes. The router/ES SHOULD run 486 an IP routing protocol with the connecting TRILL edge RBridge. The 487 edge RBridge will learn the IP prefixes behind the router/ES through 488 that IP routing protocol, then the RBridge will generate local IP 489 routing entries in the corresponding routing domain. If such a 490 routing protocol is not run with the edge RBridge, then only the IP 491 prefixes behind the router/ES that are explicitly configured on the 492 edge RBridge will be accessible. 494 5.2. Local Routing Information Synchronization 496 When a routing instance is created on an edge RBridge, the tenant ID, 497 tenant Data Label (VLAN or FGL), tenant gateway MAC that correspond 498 to that instance are configured and MUST be globally advertised (see 499 Section 7.1). The Tenant ID uniquely identifies that tenant 500 throughout the campus. The tenant Data Label identifies that tenant 501 at the edge RBridge. The tenant gateway MAC MAY identify that tenant 502 or all tenants or some subset of tenants at the edge RBridge. 504 When an ingress RBridge performs inter-subnet traffic TRILL 505 encapsulation, the ingress RBridge uses the Data Label advertised by 506 the egress RBridge as the inner VLAN or FGL and uses the tenant 507 gateway MAC advertised by the egress RBridge as the Inner.MacDA. The 508 egress RBridge relies on this tenant Data Label to find the local 509 VRF instance for the IP forwarding process when receiving inter- 510 subnet traffic from the TRILL campus. (The role of tenant Data Label 511 is akin to an MPLS VPN Label in an MPLS IP/MPLS VPN network.) Tenant 512 Data Labels are independently allocated on each edge RBridge for 513 each routing domain. An edge RBridge can use an access Data Label 514 from a routing domain to act as the inter-subnet Data Label, or the 515 edge RBridge can use a Data Label different from any access Data 516 Labels to be a tenant Data Label. It is implementation dependent and 517 there is no restriction on this assignment of Data Labels. 519 The tenant gateway MAC differentiates inter-subnet Layer 3 traffic 520 from intra-subnet Layer 2 traffic on the egress RBridge. Each tenant 521 on a RBridge can use a different gateway MAC or same tenant gateway 522 MAC for inter-subnet traffic purposes. This is also implementation 523 dependent and there is no restriction on it. 525 When a local IP prefix is learned in a routing instance on an edge 526 RBridge, the edge RBridge should advertise the IP prefix information 527 for the routing instance so that other edge RBridges will generate 528 IP routing entries. If the ESs in a VN are spread over multiple 529 RBridges, these RBridges MUST advertise each local connecting end 530 station's IP address in the VN to other RBridges. If the ESs in a VN 531 are only connected to one edge RBridge, that RBridge only needs to 532 advertise the subnet corresponding to the VN to other RBridges using 533 host routes. A tenant ID unique across the TRILL campus is also 534 carried in the advertisement to differentiate IP prefixes between 535 different tenants, because the IP address space of different tenants 536 can overlap (see Sections 7.3 and 7.4). 538 If a tenant is deleted on an edge RBridge RB1, RB1 updates the local 539 tenant Data Label, tenant gateway MAC, and related IP prefixes 540 information it is advertising to include only the rest of the 541 tenants. It may take some time for the updating to reach all other 542 RBridges, so during this period of time there may be transient route 543 inconsistency among the edge RBridges. If there is traffic in flight 544 during this time, it will be dropped at the egress RBridge due to 545 local tenant deletion. When a stable state is reached, the traffic 546 to the deleted tenant will be dropped by the ingress RBridge. 547 Therefore the transient routes consistency won't cause issues other 548 than wasting some network bandwidth. 550 If there is a new tenant which is created and a previously used tenant 551 Data Label is assigned to the new tenant immediately, it may cause a 552 security policy violation for the traffic in flight, because when 553 the egress RBridge receives traffic from the old tenant, it will 554 forward it in the new tenant's routing instance and deliver it to 555 the wrong destination. So a tenant Data Label MUST NOT be re- 556 allocated until a reasonable amount of time, for example twice the 557 IS-IS Holding Time generally in use in the TRILL campus, has passed 558 to allow any traffic in flight to be discarded. 560 When the ARP entry in an edge RBridge for an ES times out, it will 561 trigger an edge RBridge LSP advertisement to other edge RBridges 562 with the corresponding IP routing entry deleted. If the ES is an IP 563 router, the edge RBridge also notifies other edge RBridges that they 564 must delete the routing entries corresponding to the IP prefixes 565 accessible through that IP router. During the IP prefix deleting 566 process, if there is traffic in flight, the traffic will be 567 discarded at the egress RBridge because there is no local IP routing 568 entry to the destination. 570 If an edge RBridge changes its tenant gateway MAC, it will trigger 571 an edge RBridge LSP advertisement to other edge RBridges giving the 572 new gateway MAC to be used as Inner.MacDA for future traffic 573 destined to the edge RBridge. During the gateway MAC changing 574 process, if there is traffic in flight using the old gateway MAC as 575 Inner.MacDA, the traffic will be discarded or be forwarded as layer 576 2 intra-subnet traffic on the edge RBridge. If the inter-subnet 577 tenant Data Label is a unique Data Label that is different from any 578 access Data Labels, when the edge RBridge receives the traffic whose 579 Inner.MacDA is different from local tenant gateway MAC, the traffic 580 will be discarded. If the edge RBridge uses one of the access Data 581 Labels as an inter-subnet tenant Data Label, the traffic will be 582 forwarded as layer 2 intra-subnet traffic unless a special traffic 583 filtering policy is enforced on the edge RBridge. 585 If there are multiple nicknames owned by an edge RBridge, the edge 586 RBridge also can specify one nickname as the egress nickname for 587 inter-subnet traffic forwarding. A NickFlags APPsub-TLV with the SE- 588 flag set can be used for this purpose. If the edge RBridge doesn't 589 specify a nickname for this purpose, the ingress RBridge can use any 590 one of the nicknames owned by the egress as the egress nickname for 591 inter-subnet traffic forwarding. 593 TRILL E-L1FS FS-LSP [RFC7780] APPsub-TLVs are used for IP routing 594 information synchronization in each routing domain among edge 595 RBridges. Based on the synchronized information from other edge 596 RBridges, each edge RBridge generates routing entries in each 597 routing domain for remote IP addresses and subnets. 599 Through this solution, the intra-subnet forwarding function and 600 inter-subnet IP routing functions are integrated and network 601 management and deployment is simplified. 603 5.3. Active-active Access 605 TRILL active-active service provides end stations with flow level 606 load balance and resilience against link failures at the edge of 607 TRILL campuses as described in [RFC7379]. 609 If an ES is connected to two TRILL RBridges, say RB1 and RB2, in 610 active-active mode, RB1 and RB2 MUST both be configured to act as a 611 distributed layer 3 gateway for the ES in order to use a distributed 612 gateway. RB1 and RB2 each learn the ES's IP address through the 613 ARP/ND process and then they announce the IP address to the TRILL 614 campus independently. The remote ingress RBridge will generate an IP 615 routing entry corresponding with the IP address with two IP next 616 hops of RB1 and RB2. When the ingress RBridge receives inter-subnet 617 traffic from a local access network, the ingress RBridge selects RB1 618 or RB2 as the IP next hop based on least cost or, if costs are equal, 619 the local load balancing algorithm. Then the traffic will be 620 transmitted to the selected next hop destination RB1 or RB2 through 621 the TRILL campus. 623 5.4. Data Traffic Forwarding Process 625 After a Layer 2 connected ES1 in VLAN-x acquires its gateway's MAC, 626 it can start inter-subnet data traffic transmission to ES2 in VLAN-y. 628 When the edge RBridge attached to ES1 receives inter-subnet traffic 629 from ES1, that RBridge performs Layer 2 header termination, then, 630 using the local VRF corresponding to VLAN-x, it performs the IP 631 routing process in that VRF. 633 If destination ES2 is attached to the same edge RBridge, the traffic 634 will be locally forwarded to ES2 by that RBridge. Compared to the 635 centralized gateway solution, the forwarding path is optimal and a 636 traffic detour through the centralized gateway is avoided. 638 If ES2 is attached to a remote edge RBridge, the remote edge RBridge 639 is IP next hop and the inter-subnet traffic is forwarded to the IP 640 next hop through TRILL encapsulation. If there are multiple equal 641 cost shortest paths between ingress RBridge and egress RBridge, all 642 these paths can be used for inter-subnet traffic forwarding, so load 643 spreading can be achieved for inter-subnet traffic. 645 When the remote RBridge receives the inter-subnet TRILL encapsulated 646 traffic, the RBridge decapsulates the TRILL encapsulation and check 647 the Inner.MacDA. If that MAC address is the local gateway MAC 648 corresponding to the inner Label (VLAN or FGL), the inner Label will 649 be used to find the corresponding local VRF, then the IP routing 650 process in that VRF will be performed, and the traffic will be 651 locally forwarded to the destination ES2. 653 In summary, this solution avoids traffic detours through a central 654 gateway, both inter-subnet and intra-subnet traffic can be forwarded 655 along pair-wise shortest paths, and network bandwidth is conserved. 657 6. Distributed Layer 3 Gateway Process Example 659 This section gives a detailed description of a distributed layer 3 660 gateway solution example for IPv4 and IPv6. 662 --------- --------- 663 | RB3 | | RB4 | 664 --------- --------- 665 # * # * 666 # ************************** 667 ########################### * 668 # * 669 # * 670 # * 671 --------- --------- 672 | RB1 | | RB2 | 673 --------- --------- 674 | | 675 ----- ----- 676 |ES1| |ES2| 677 ----- ----- 678 Figure 3. Distributed gateway scenario 680 In figure 3, RB1 and RB2 support the distribution gateway function, 681 ES1 connects to RB1, ES2 connects to RB2. ES1 and ES2 belong to 682 Tenant1, but are in different subnets. 684 For IPv4, the IP address, VLAN, and subnet information of ES1 and 685 ES2 are as follows: 687 +----+---------+------------------+------------------+----------+ 688 | ES | Tenant | IP Address | Subnet | VLAN | 689 +----+---------+------------------+------------------+----------+ 690 | ES1| Tenant1 | 192.0.2.2 | 192.0.2.0/24 | 10 | 691 +----+---------+------------------+------------------+----------+ 692 | ES2| Tenant1 | 198.51.100.2 | 198.51.100.0/24 | 20 | 693 +----+---------+------------------+------------------+----------+ 694 Figure 4a. IPv4 ES information 696 For IPv6, the IP address, VLAN, and subnet information of ES1 and 697 ES2 are as follows: 699 +----+---------+------------------+------------------+----------+ 700 | ES | Tenant | IP Address | Subnet | VLAN | 701 +----+---------+------------------+------------------+----------+ 702 | ES1| Tenant1 | 2001:db8:0:1::2 |2001:db8:0:1::0/64| 10 | 703 +----+---------+------------------+------------------+----------+ 704 | ES2| Tenant1 | 2001:db8:0:2::2 |2001:db8:0:2::0/64| 20 | 705 +----+---------+------------------+------------------+----------+ 707 Figure 4b. IPv6 ES information 709 The nickname, VRF, tenant Label, tenant gateway MAC for Tenant1 on 710 RB1 and RB2 are as follows: 711 +----+---------+----------+-------+--------------+--------------+ 712 | RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC | 713 +----+---------+----------+-------+--------------+--------------+ 714 | RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 | 715 +----+---------+----------+-------+--------------+--------------+ 716 | RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 | 717 +----+---------+----------+-------+--------------+--------------+ 718 Figure 5. RBridge information 720 6.1. Control plane process 722 RB1 advertises the following local routing information to the 723 campus: TRILL 725 Tenant ID: 1 727 Tenant gateway MAC: MAC1 729 Tenant Label for Tenant1: VLAN 100. 731 IPv4 prefix for Tenant1: 192.0.2.0/24 733 IPv6 prefix for Tenant1: 2001:db8:0:1::0/64 735 RB2 announces the following local routing information to TRILL 736 campus: 738 Tenant ID: 1 740 Tenant gateway MAC: MAC2 741 Tenant Label for Tenant1: VLAN 100. 743 IPv4 prefix for Tenant1: 198.51.100.0/24 745 IPv6 prefix for Tenant1: 2001:db8:0:2::0/64 747 Relying on the routing information from RB2, remote routing entries 748 on RB1 are generated as follows: 750 +------------------+-------------+--------------+----------------+ 751 | Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname| 752 +------------------+-------------+--------------+----------------+ 753 |198.51.100.0/24 | MAC2 | 100 | nick2 | 754 +------------------+-------------+--------------+----------------+ 755 |2001:db8:0:2::0/64| MAC2 | 100 | nick2 | 756 +------------------+-------------+--------------+----------------+ 757 Figure 6. Tenant 1 remote routing table on RB1 759 Similarly, relying on the routing information from RB1, remote 760 routing entries on RB2 are generated as follows: 762 +------------------+-------------+--------------+----------------+ 763 | Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname| 764 +------------------+-------------+--------------+----------------+ 765 | 192.0.2.0/24 | MAC1 | 100 | nick1 | 766 +------------------+-------------+--------------+----------------+ 767 |2001:db8:0:1::0/64| MAC1 | 100 | nick1 | 768 +------------------+-------------+--------------+----------------+ 769 Figure 7. Tenant 1 remote routing table on RB2 771 6.2. Data Plane Process 773 Assuming ES1 sends unicast inter-subnet traffic to ES2, the traffic 774 forwarding process is as follows: 776 1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's 778 gateway's MAC as the destination MAC and VLAN as VLAN 10. 780 2. Ingress RBridge (RB1) forwarding process: 782 RB1 checks the destination MAC, if the destination MAC equals the 783 local gateway MAC, the gateway function will terminate the Layer 2 784 header and perform L3 routing. 786 RB1 looks up IP routing table information by destination IP and 787 Tenant ID to get IP next hop information, which includes the egress 788 RBridge's gateway MAC (MAC2), tenant Label (VLAN 100) and egress 789 nickname (nick2). Using this information, RB1 will perform inner 790 Ethernet header encapsulation and TRILL encapsulation. RB1 will use 791 MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as the 792 Inner.MacSA, VLAN 100 as the Inner.VLAN, nick2 as the egress 793 nickname and nick1 as the ingress nickname. 795 RB1 looks up TRILL forwarding information by egress nickname and 796 sends the traffic to the TRILL next hop as per [RFC6325]. The 797 traffic will be sent to RB3 or RB4 as a result of load balancing. 799 Assuming the traffic is forwarded to RB3, the following occurs: 801 3. Transit RBridge (RB3) forwarding process: 803 RB3 looks up TRILL forwarding information by egress nickname and 804 forwards the traffic to RB2 as per [RFC6325]. 806 4. Egress RBridge forwarding process: 808 As the egress nickname is RB2's own nickname, RB2 performs TRILL 809 decapsulation. Then it checks the Inner.MacDA and, because that MAC 810 is equal to the local gateway MAC, performs inner Ethernet header 811 termination. Using the inner VLAN, RB2 finds the local 812 corresponding VRF and looks up the packets destination IP address 813 in the VRF's IP routing table. The traffic is then be locally 814 forwarded to ES2 with VLAN 20. 816 7. TRILL Protocol Extensions 818 If an edge RBridge RB1 participates in the distributed gateway 819 function, it announces its tenant gateway MAC and tenant Data Label 820 to the TRILL campus through the tenant Label and gateway MAC APPsub- 821 TLV, it should announce its local IPv4 and IPv6 prefixes through the 822 IPv4 Prefix APPsub-TLV and the IPv6 Prefix APPsub-TLV respectively. 823 If RB1 has multiple nicknames, it can announce one nickname for 824 distributed gateway use using Nickname Flags APPsub-TLV with "SE" 825 Flag set to one. 827 The remote ingress RBridges belonging to the same routing domain use 828 this information to generate IP routing entries in that routing 829 domain. These RBridges use the nickname, tenant gateway MAC, and 830 tenant Label of RB1 to perform inter-subnet traffic TRILL 831 encapsulation when they receive inter-subnet traffic from a local ES. 832 The nickname is used as the egress nickname, the tenant gateway MAC 833 is used as the Inner.MacDA, and the tenant Data Label is used as the 834 Inner.Label. The following APPsub-TLVs MUST be included in a TRILL 835 GENINFO TLV in E-L1FS FS-LSPs [RFC7780]. 837 7.1. The Tenant Label and Gateway MAC APPsub-TLV 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Type | (2 bytes) 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Length | (2 bytes) 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Tenant ID (4 bytes) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Resv1 | Label1 | (2 bytes) 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Resv2 | Label2 | (2 bytes) 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+ 850 | Tenant Gateway Mac (6 bytes) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+-+ 853 o Type: Set to TENANT- GWMAC-LABEL sub-TLV type (TBD1). Two bytes, 854 because this APPsub-TLV appears in an extended TLV [RFC7356]. 856 o Length: If Label1 field is used to represent a VLAN, the value of 857 the length field is 12. If Label1 and Label2 field are used to 858 represent an FGL, the value of the length field is 14. 860 o Tenant ID: This identifies a tenant ID unique across the TRILL 861 campus. 863 o Resv1: 4 bits that MUST be sent as zero and ignored on receipt. 865 o Label1: If the value of the length field is 12, it identifies a 866 tenant Label corresponding to a VLAN ID. If the value of the length 867 field is 14, it identifies the higher 12 bits of a tenant Label 868 corresponding to a FGL. 870 o Resv2: 4 bits that MUST be sent as zero and ignored on receipt. 871 Only present if the length field is 14. 873 o Label2: This field has the lower 12 bits of tenant Label 874 corresponding to a FGL. Only present if the length field is 14. 876 o Tenant Gateway MAC: This identifies the local gateway MAC 877 corresponding to the tenant ID. The remote ingress RBridges uses 878 the Gateway MAC as Inner.MacDA. The advertising TRILL RBridge uses 879 the gateway MAC to differentiate layer 2 intra-subnet traffic and 880 layer 3 inter-subnet traffic in the egress direction. 882 7.2. "SE" Flag in NickFlags APPsub-TLV 884 The NickFlags APPsub-TLV is specified in [RFC7780] where the IN flag 885 is described. The SE Flag is assigned as follows: 886 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 887 | Nickname | 888 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 889 |IN|SE| RESV | 890 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 891 NICKFLAG RECORD 893 o SE. If the SE flag is one, it indicates that the advertising 894 RBridge suggests the nickname SHOULD be used as the Inter-Subnet 895 Egress nickname for inter-subnet traffic forwarding. If flag is 896 zero, that nickname SHOULD NOT be used for that purpose. The SE 897 flag is ignored if the NickFlags APPsub-TLV is advertised by an 898 RBridge that does not own the Nickname. 900 7.3. The IPv4 Prefix APPsub-TLV 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Type | (2 bytes) 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Total Length | (2 bytes) 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 906 | Tenant ID | (4 bytes) 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 908 |PrefixLength(1)| (1 byte) 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 910 | Prefix (1) | (variable) 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 912 | ..... | (1 byte) 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 914 | ..... | (variable) 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 916 |PrefixLength(N)| (1 byte) 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 918 | Prefix (N) | (variable) 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 921 o Type: Set to IPV4-PREFIX sub-TLV type (TBD2). Two bytes, because 922 this APPsub-TLV appears in an extended TLV [RFC7356]. 924 o Total Length: This 2-byte unsigned integer indicates the total 925 length of the Tenant ID, the Prefix Length, and the Prefix fields 926 in octets. A value of 0 indicates that no IPv4 prefix is being 927 advertised. 929 o Tenant ID: This identifies a tenant ID unique across the TRILL 930 campus. 932 o Prefix Length: The Prefix Length field indicates the length in bits 933 of the IPv4 address prefix. A length of zero indicates a prefix 934 that matches all IPv4 addresses (with prefix, itself, of zero 935 octets). 937 o Prefix: The Prefix field contains an IPv4 address prefix, followed 938 by enough trailing bits to make the end of the field fall on an 939 octet boundary. Note that the value of the trailing bits is 940 irrelevant. For example, if the Prefix Length is 12, indicating 12 941 bits, then the Prefix is 2 octets and the low order 4 bits of the 942 Prefix are irrelevant. 944 7.4. The IPv6 Prefix APPsub-TLV 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | (2 bytes) 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Total Length | (2 bytes) 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 950 | Tenant ID | (4 bytes) 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 952 |PrefixLength(1)| (1 byte) 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 954 | Prefix (1) | (variable) 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 956 | ..... | (1 byte) 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 958 | ..... | (variable) 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 960 |PrefixLength(N)| (1 byte) 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 962 | Prefix (N) | (variable) 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+ 965 o Type: Set to IPV6-PREFIX sub-TLV type (TBD3). Two bytes, because 966 this APPsub-TLV appears in an extended TLV [RFC7356]. 968 o Total Length: This 2-byte unsigned integer indicates the total 969 length of the Tenant ID, the Prefix Length, and the Prefix fields 970 in octets. A value of 0 indicates that no IPv6 prefix is being 971 advertised. 973 o Tenant ID: This identifies a tenant ID unique across the TRILL 974 campus. 976 o Prefix Length: The Prefix Length field indicates the length in bits 977 of the IPv6 address prefix. A length of zero indicates a prefix 978 that matches all IPv6 addresses (with prefix, itself, of zero 979 octets). 981 o Prefix: The Prefix field contains an IPv6 address prefix, followed 982 by enough trailing bits to make the end of the field fall on an 983 octet boundary. Note that the value of the trailing bits is 984 irrelevant. For example, if the Prefix Length is 100, indicating 985 100 bits, then the Prefix is 13 octets and the low order 4 bits of 986 the Prefix are irrelevant. 988 8. Security Considerations 990 Correct configuration of the edge RBridges participating is 991 important to assure that data is not delivered to the wrong tenant, 992 which would violate security constrains. IS-IS security [RFC5310] 993 can be used to secure the information advertised by the edge 994 RBridges in LSPs and FS-LSPs. 996 See Section 5.2 for constraints on re-use of a tenant ID and on 997 tenant gateway MAC change to avoid the mishandling of data in flight. 998 It can be made more difficult for an adversary to guess a tenant ID 999 that is in use by selecting tenant IDs in a pseudo-random fashion 1000 [RFC4086]. 1002 Particularly sensitive data should be encrypted end-to-end, that is, 1003 from the source end station to the destination end station. Since 1004 the TRILL campus is, for the most part, transparent to end station 1005 traffic, such end stations are free to use whatever end-to-end 1006 security protocol they would like. 1008 For general TRILL Security Considerations, see [RFC6325]. 1010 9. Management Considerations 1012 The configuration at each RBridge to support the distributed Layer 3 1013 gateway feature is visible to all other RBridges in the campus in 1014 the link state database. OAM facilities for TRILL are primarily 1015 specified in [RFC7455] and [RFC7456]. 1017 10. IANA Considerations 1019 IANA is requested to assign three APPsub-TLV type numbers from the 1020 range less than 255 and update the "TRILL APPsub-TLV Types under IS- 1021 IS TLV 251 Application Identifier 1" registry as follows: 1023 Type Name References 1025 ---- ---------------- ------------ 1027 TBD1 TENANT-GWMAC-LABEL [this document] 1029 TBD2 IPV4-PREFIX [this document] 1031 TBD3 IPV6-PREFIX [this document] 1033 IANA is requested to assign a flag bit in the NickFlags APPsub-TLV 1034 as described in Section 7.2 and update the ''Nick Flags'' registry, 1035 created by [RFC7780], as follows: 1037 Bit Mnemonic Description Reference 1039 ----- -------- ------------------- ----------- 1041 1 SE Inter-Subnet Egress [this document] 1043 11. Normative References 1045 [IS-IS] - ISO/IEC, "Intermediate system to Intermediate system 1046 routeing information exchange protocol for use in conjunction with 1047 the Protocol for providing the Connectionless-mode Network Service 1048 (ISO 8473)", ISO/IEC 10589:2002. 1050 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, April 1997. 1053 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and 1054 A.Ghanwani, "Routing Bridges (RBridges): Base Protocol 1055 Specification", RFC 6325, July 2011. 1057 [RFC7172] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 1058 "TRILL (Transparent Interconnection of Lots of Links): Fine-Grained 1059 Labeling", RFC7172, May 2014. 1061 [RFC7176] - Eastlake, D., T. Senevirathne, A. Ghanwani, D. Dutt and 1062 A. Banerjee" Transparent Interconnection of Lots of Links (TRILL) Use 1063 of IS-IS", RFC7176, May 2014. 1065 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 1066 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 1067 . 1069 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1070 Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of 1071 Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, 1072 DOI 10.17487/RFC7780, February 2016, . 1075 12. Informative References 1077 [RFC826] - Plummer, D., "Ethernet Address Resolution Protocol: Or 1078 Converting Network Protocol Addresses to 48.bit Ethernet Address for 1079 Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982, 1080 . 1082 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 1083 "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 1084 10.17487/RFC4086, June 2005, . 1086 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1087 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 1088 2007, . 1090 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1091 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, 1092 February 2009. 1094 [RFC7379] - Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, 1095 "Problem Statement and Goals for Active-Active Connection at the 1096 Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, 1097 October 2014, . 1099 [RFC7455] - Senevirathne, T., Finn, N., Salam, S., Kumar, D., 1100 Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection 1101 of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 1102 10.17487/RFC7455, March 2015, . 1105 [RFC7456] - Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and 1106 D. Eastlake 3rd, "Loss and Delay Measurement in Transparent 1107 Interconnection of Lots of Links (TRILL)", RFC 7456, DOI 1108 10.17487/RFC7456, March 2015, . 1111 Acknowledgments 1113 The authors wish to acknowledge the important contributions of 1114 Donald Eastlake, Gayle Noble, Muhammed Umair, Susan Hares, Guangrui 1115 Wu, Zhenbin Li, Zhibo Hu, Liang Xia, Scott Bradner, Stephen Farrell, 1116 Shawn Emery, Ben Campbell, Russ White, Kathleen Moriarty, Suresh 1117 Krishnan, Mirja Kuhlewind, and Francis Dupont. 1119 Authors' Addresses 1121 Weiguo Hao 1122 Huawei Technologies 1123 101 Software Avenue, 1124 Nanjing 210012, China 1126 Phone: +86-25-56623144 1127 Email: haoweiguo@huawei.com 1129 Yizhou Li 1130 Huawei Technologies 1131 101 Software Avenue, 1132 Nanjing 210012, China 1134 Phone: +86-25-56625375 1135 Email: liyizhou@huawei.com 1137 Andrew Qu 1138 MediaTec 1139 Email: laodulaodu@gmail.com 1141 Muhammad Durrani 1142 Cisco 1143 Email: mdurrani@cisco.com 1145 Ponkarthick Sivamurugan 1146 Address: IP Infusion, 1147 RMZ Centennial 1148 Mahadevapura Post 1149 Bangalore - 560048 1150 Email: Ponkarthick.sivamurugan@ipinfusion.com