idnits 2.17.1 draft-aldrin-trill-campus-extension-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2012) is 4303 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 185, but not defined == Unused Reference: 'KEYWORDS' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 995, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'PBB-EVPN' is defined on line 1026, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) == Outdated reference: A later version (-02) exists of draft-tissa-trill-multilevel-00 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-03 == Outdated reference: A later version (-02) exists of draft-ietf-l2vpn-trill-evpn-00 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group Sam Aldrin 3 INTERNET-DRAFT Donald Eastlake 4 Intended Status: Proposed Standard Huawei Technologies 5 Tissa Senevirathne 6 Ayan Banerjee 7 Santiago Alvarez 8 CISCO 9 Xiaolan Wan 10 XiaoPeng Yang 11 Hangzhou H3C Tech. Co. Ltd 13 Expires: January 10, 2013 July 9, 2012 15 TRILL Campus Extension 16 draft-aldrin-trill-campus-extension-00 18 Abstract 20 This document presents a solution suite for TRILL campuses to be 21 connected over WAN networks. TRILL protocol is primarily designed to 22 work within intra-data centers. Connecting different sites over WAN 23 using overlay tunnel protocols is the primary method employed at 24 present. Though this presents a simple mechanisms to extend TRILL 25 campuses over WAN networks, it also brings in the problem of 26 scalability for TRILL nicknames exchanged between sites, latency, 27 duplication of traffic etc. This draft proposes a way to extend the 28 TRILL sites without having the WAN network aware of TRILL campus 29 network and its topology. This document details on how to extend 30 TRILL campus sites and to establish connections between various sites 31 without having to exchange entire TRILL campus information, thus 32 reducing the information flow to the required sites only. This 33 document do not add or define datacenter interconnect protocol. 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2 Contributors . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Solution overview . . . . . . . . . . . . . . . . . . . . . . 5 77 2.1 Site inter-connection . . . . . . . . . . . . . . . . . . . 6 78 2.2 Requirements overview . . . . . . . . . . . . . . . . . . . 6 79 2.2 TRILL campus extension . . . . . . . . . . . . . . . . . . 7 80 2.3 TRILL nickname exhaustion . . . . . . . . . . . . . . . . . 7 81 3. Solution analysis and comparison . . . . . . . . . . . . . . . 7 82 3.1 TRILL campus extension . . . . . . . . . . . . . . . . . . 8 83 3.2 TRILL campus extension over IP . . . . . . . . . . . . . . 9 84 3.3 TRILL campus interconnection with TRILL-EVPN . . . . . . . 10 85 3.4 TRILL campus interconnection over VPN's . . . . . . . . . . 11 86 4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 12 87 4.1 Campus and Backbone Areas . . . . . . . . . . . . . . . . . 12 88 4.2 Unicast forwarding . . . . . . . . . . . . . . . . . . . . . 12 89 4.3 Multicast Forwarding . . . . . . . . . . . . . . . . . . . . 13 90 4.4 MAC learning . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.5 TRILL nickname aggregation . . . . . . . . . . . . . . . . . 15 92 5. TRILL campus inter-connectivity . . . . . . . . . . . . . . . . 15 93 5.1 Border RBridges interconnection . . . . . . . . . . . . . . 16 94 5.2 Inter-site nickname exchange . . . . . . . . . . . . . . . . 16 95 5.3 Border RBridge capability exchange . . . . . . . . . . . . . 16 96 5.4 TRILL adjacency resolution . . . . . . . . . . . . . . . . . 17 97 5.5 Forwarding of data frames . . . . . . . . . . . . . . . . . 17 98 6. Proposed additions and extensions . . . . . . . . . . . . . . . 17 99 6.1 Border RBridge capability TLV . . . . . . . . . . . . . . . 18 100 6.2 TRILL nickname aggregation sub-TLV . . . . . . . . . . . . . 18 101 7. TRILL campus extension over IP . . . . . . . . . . . . . . . . 19 102 7.1 Underlying Network . . . . . . . . . . . . . . . . . . . . . 19 103 7.2 Overlay Control Plane . . . . . . . . . . . . . . . . . . . 19 104 7.2.1 BRbridge discovery and adjacency setup . . . . . . . . . 19 105 7.2.2 Control plane packet encapsulation . . . . . . . . . . . 19 106 7.3 Overlay Data Plane . . . . . . . . . . . . . . . . . . . . . 20 107 7.3.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . 20 108 7.4 Forwarding Process . . . . . . . . . . . . . . . . . . . . . 22 109 7.4.1. Forwarding from an Internal Link to the Overlay . . . 22 110 7.4.2. Forwarding from the Overlay Link to an Internal Link . 22 111 7.4.5. Mac Address Learning . . . . . . . . . . . . . . . . . 22 112 7.4.6. Multi-homing . . . . . . . . . . . . . . . . . . . . . 23 113 7.5 Control plane termination . . . . . . . . . . . . . . . . . 23 114 7.6 Control plane termination and Data plane de-capsulation . . 24 115 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 116 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 117 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 118 10.1 Normative References . . . . . . . . . . . . . . . . . . . 24 119 9.2 Informative References . . . . . . . . . . . . . . . . . . 25 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 122 1 Introduction 124 TRILL protocol is primarily designed as an intra-datacenter protocol 125 by leveraging the routing functionality to interconnect bridges. 126 Traditional Ethernet networks provided a single path for forwarding 127 the traffic, which is usually derived using protocols like Spanning 128 Tree. TRILL provided a way to utilize multiple links for forwarding, 129 thus utilizing the resources effectively. Even though TRILL is new 130 protocol, it seamlessly integrates with legacy bridging networks 131 without having to forklift upgrade of all the bridges to support 132 TRILL. By not having to learn the MAC addresses of end stations by 133 intermediate devices, provided a powerful way to interconnect bridges 134 within a datacenter and maximizing the resource usage and providing 135 multipath usage option. 137 TRILL enabled network creates efficiency by having reduced forwarding 138 table size. By doing TRILL nickname based forwarding created a layer 139 of abstraction and much easier to implement the protocol. This 140 enabled to address the scalability of a L2 domain, where thousands of 141 RBridges could exist to meet the needs of a datacenter. By leveraging 142 IS-IS protocol, the information exchange and leveraging the path 143 computation technology brought forth a new paradigm into bridging 144 technology. TRILL Base Protocol Specification [RFC6325] specifies a 145 tree based paradigm to forward broadcast and multicast traffic as 146 well as unknown unicast traffic. 148 Even though the TRILL is enabled within a campus network or a 149 datacenter, it is not primarily designed to work over WAN. There is a 150 need to interconnect various TRILL campuses to extend beyond a single 151 LAN domain. Some enterprise or campus networks could be having 152 multiple TRILL sites and these TRILL enabled sites could run 153 independently or could share resources in order to cater to the needs 154 of customers or users. As such, there exist few proposals based on 155 overlay technologies which interconnect these sites but those 156 solutions require MAC learning at the edge RBridges and stripping of 157 TRILL nickname on the frame. Another option is to interconnect these 158 TRILL sites transparently over Pseudowires and making a huge TRILL 159 campus site. This is useful option but the downside of this is when 160 provider would like to maintain independent sites and exchange only 161 the required data to be shared across sites, it becomes complicated 162 to maintain the networks. 164 [TRILL-EVPN] draft details the data center protocol in interconnect 165 different LAN domains, including TRILL sites, over VPN's. This 166 requires establishing VPN's over WAN using BGP protocol, thus 167 requiring WAN service provider involvement in establishing 168 interconnection between different sites. 170 This draft solves a specific problem where a TRILL campus needs to be 171 extended, be it a different geographical location or network 172 administrative domain. Though the primary goal is effective extension 173 of TRILL campuses, this draft is not a replacement for datacenter 174 interconnect protocols like PBB_EVPN. All the extensions are limited 175 to TRILL protocol, without any extensions to WAN protocols for 176 interconnect, such that, effective unicast and multicast traffic 177 could be sent over WAN links and keeping core network agnostic of the 178 TRILL network. 180 1.1 Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 1.2 Contributors 188 In addition to the authors listed above the following individuals 189 also contributed to this document: 191 Xiaopeng Yan 192 Hangzhou H3C Tech. Co., Ltd. 194 Vishwas Manral 195 Alvaro Retana 196 Dave Tucker 197 Hewlett-Packard 199 2. Solution overview 201 This section provides the high-level overview of the solution to the 202 problems in various scenarios. More detailed representation of the 203 solution is covered in the later sections of the draft. 205 TRILL site or TRILL campus uses IS-IS to setup the RBridge 206 interconnection. A RBridge knows how to reach another RBridge within 207 the campus. When two TRILL campuses are interconnected, one could 208 visualize it in two different perspectives. First one is a merger of 209 two TRILL campuses into one. This requires each RBridge to know about 210 the other and the IS-IS should be able to compute the shortest paths 211 from one to another. The downside of this model is that information 212 exchange explosion and the size of IS-IS db and number of PDU's being 213 exchanged could increase exponentially. 215 The second perspective is to have these two TRILL campuses being 216 interconnected over a WAN, but their functioning nature is 217 independent to each other. The two campuses exchange only the 218 required information between border RBridges of the campuses. This 219 will be more optimal and leads to interconnecting multiple campuses 220 without having to redesign the whole network to ensure uniqueness and 221 identity of RBridges. 223 Solution being proposed is in line with second option, which 224 maintains site independency with a simplified solution and modeled 225 around the existing and proven technologies. Some of the enhancements 226 were already proposed in other drafts like multilevel TRILL [TISSA- 227 MLEVEL] and the solution leverages by extending those definitions as 228 necessary. The solution addresses the following areas described in 229 the following sections 231 2.1 Site inter-connection 233 Each TRILL campus is considered as an independent site or an L1 IS-IS 234 domain. These TRILL campus sites are interconnected over WAN. Each 235 area will have an appointed border RBridges. These RBridges exchange 236 the information of other border RBridges of different TRILL campus 237 sites to establish connection with each other. When a TRILL campus is 238 extended by interconnecting two or more campuses, the interconnection 239 could be over L2 or L3 WAN connection. A frame from an RBridge in 240 campus, to reach other RBridge in other campus, should be aware of 241 the path it should take. When a frame is sent from the border RBridge 242 to another Border RBridge in the other campus, it traverses the WAN 243 network. This is transparent to the source RBridge in order to reach 244 the destination RBridge. The WAN connection established between the 245 campuses is not aware of the traffic it is carrying and is not 246 established based on the TRILL campuses. 248 2.2 Requirements overview 250 There are various requirements necessary to be met in order to 251 provide a seamless TRILL campus extension. Some of the important 252 requirements are as follows 254 o Extend TRILL technology over interconnect 256 o Ability to provide the same fast convergence for mobility as it 257 does in intra-TRILL campus 259 o Ability to work transparent with various WAN technologies 261 o Option for dynamic establishment of connectivity across sites 263 o Minimal changes to TRILL protocol and definitions 264 o Backward compatible to existing networks and their functions. 266 In some scenarios it may be required for TRILL to be extended over an 267 IP network, for example a case where the network administrator does 268 not have control over the wide area network configuration. The TRILL 269 over IP solution should meet the requirements outlined above and 270 additionally: 272 o Require only unciast reachability between RBridges and multicast 273 support from the WAN provider 275 o Provide Auto-discovery of Border Rbridges 277 2.2 TRILL campus extension 279 By interconnecting TRILL campus sites over WAN, one could extend the 280 L1 area, but that would cause other issues as detailed in the earlier 281 section. When two campuses merge, there will be a possibility for 282 nickname collision. The ideal situation is to keep the ability for 283 each campus nicknames overlapped with the other campus. The other 284 option is to provide a mechanism to do the nickname resolution. This 285 version of the document details the solution of the later option. In 286 the subsequent version, the former option for retaining nicknames 287 will be addressed. 289 2.3 TRILL nickname exhaustion 291 Though this draft is not meant to provide solution for TRILL nickname 292 exhaustion, it enables provider to deal with the problem effectively 293 and not having to re-design the network, every time a new campus is 294 interconnected. The proposed solution has RBridges which are not 295 required to be exposed outside of the campus and there are other 296 RBridges which are also known as border RBridges. This version the 297 document assumes global uniqueness of TRILL nicknames across various 298 campuses. When a frame has to be forwarded to an RBridge which 299 resides in another campus, the originating RBridge knows how to get 300 to the borderRBridge. This border RBridge should have the list of 301 RBridges of other campus sites and thus could select the appropriate 302 link connecting to the destination campus and encapsulate the TRILL 303 frame and forward over that. More details are covered in the unicast 304 and multicast sections of the detailed solution. 306 3. Solution analysis and comparison 308 As eluded to in the earlier sections, there are various methods on 309 interconnecting different TRILL campus sites. Before going into the 310 details of proposed solution a close examination of some of the 311 proposed solutions, provides better perspective of this solution. 313 3.1 TRILL campus extension 315 In this model TRILL campuses are connected over WAN using 316 technologies like PW. This is the most simple way of interconnecting 317 the sites. When campuses are interconnected, the TRILL campus will 318 get expanded and each RBridge could reach each other. The main 319 criteria for this will be to maintain unique nickname for RBridges. 320 -------------- ------------ -------------- 321 | | | | | | 322 |TRILL Campus | | WAN | | TRILL Campus | 323 | | | | | | 324 | BRB1===| |====BRB2 | 325 RB1 | | | | RB2 326 | | | | | | 327 | | | | | | 328 -------------- ------------ -------------- 330 As shown in the figure above, two TRILL campuses are interconnected 331 over WAN. Border RBridges establish connection over WAN using PW or 332 other WAN technologies. All the nicknames within each campus sites 333 have to be unique. The WAN in this case is transparent to the TRILL 334 campuses and the path computation doesn't involve WAN component, 335 instead it will be like one TRILL campus. When RB1 originates a TRILL 336 frame destined to RB2, it traverses over BRB1 and BRB2 and reaches 337 RB2. 339 This solution is workable when the campuses are small and do NOT need 340 to change or requires interconnecting more TRILL campuses. The other 341 downside for this model is, when two campuses are interconnected and 342 there is overlap of nicknames, the network has to be re-designed to 343 eliminate the duplicate nicknames and make each RBrige to have a 344 unique nickname. 346 3.2 TRILL campus extension over IP 348 The TRILL campus could be extended by encapsulating TRILL inside an 349 IP Tunnel. By using this method the WAN becomes completely 350 transparent and is only required to provide unicast reachability 351 between BRbridges and establish the multicast trees. 353 +---+ +---+IPA --------- IPB +---+ +---+ 354 |S10|-----|S1 |----/ IP Core \----|S2 |-----|S20| 355 +---+ ^ +---+ \ Network / +---+ ^ +---+ 356 | --------- | 357 | | 358 | +------------+ | 359 | | DA=IPB | | 360 | +------------+ | 361 | | SA=IPA | | 362 +------------+ +------------+ +------------+ 363 |Outer Eth. | |Outer Eth. | |Outer Eth. | 364 |Header | |Header | |Header | 365 +------------+ +------------+ +------------+ 366 |TRILL Header| |TRILL Header| |TRILL Header| 367 +------------+ +------------+ +------------+ 368 |Inner Eth. | |Inner Eth. | |Inner Eth. | 369 |Frame | |Frame | |Frame | 370 +------------+ +------------+ +------------+ 372 Each BRbridge maintains a mapping table between the egress nickname 373 and an IP address. When a BRbridge receives a frame destined for a 374 remote BRBridge it looks up the egress nickname in the mapping table 375 and applies an outer IP header where the destination address is equal 376 to the Remote BRBridge IP. 378 +---+ L11+---+IPA --------- IPB +---+ L21+---+ 379 |S10|----|S1 |----/ IP Core \----| S2|----|S20| 380 +---+ +---+ \ Network / +---+ +---+ 381 --------- 383 S1 S2 384 +----------------------+ +-------------------+ 385 |Nickname |Interface | |Nickname |Interface| 386 +----------------------+ +-------------------+ 387 | S10 | L11 | | S10 | IPA | 388 +----------------------+ +-------------------+ 389 | S20 | IPB | | S20 | L21 | 390 +----------------------+ +-------------------+ 391 | S1 | self | | S1 | IPA | 392 +----------------------+ +-------------------+ 393 | S2 | IPB | | S2 | self | 394 +----------------------+ +-------------------+ 396 3.3 TRILL campus interconnection with TRILL-EVPN 398 TRILL campuses could be extended over WAN using TRILL-EVPN. 400 BEB +--------------+ BEB 401 || | | || 402 \/ | | \/ 403 +----+ AC1 +----+ | | +----+ +----+ 404 | CE1|-----| | | | | |---| CE2| 405 +----+\ |MES1| | IP/MPLS | |MES3| +----+ 406 \ +----+ | Network | +----+ 407 \ | | 408 AC2\ +----+ | | 409 \| | | | 410 |MES2| | | 411 +----+ | | 412 /\ +--------------+ 413 || 414 The [TRILL-EVPN] draft proposes interconnection details on how two 415 TRILL campuses could be interconnected using the E-VPN technology. In 416 this a new BGP route is advertised for reachability of TRILL 417 RBridges. This technique leverages the PBB technology and also 418 enables to retain TRILL header. In this solution, the edge RBridges 419 should be TRILL aware as well as to be able to speak WAN protocols 420 like BGP. When a TRILL frame arrives at border RBridge, based on the 421 nickname it will be forwarded onto a right VPN link setup for the 422 destination nickname. 424 3.4 TRILL campus interconnection over VPN's 426 In this method, TRILL campus sites could be interconnected over 427 VPN's. 429 -------------- ------------ -------------- 430 | | | | | | 431 |TRILL Campus | | WAN | | TRILL Campus | 432 | | | | | | 433 | BRB1===| |====BRB2 | 434 RB1 | | | | RB2 435 | | | | | | 436 | | | | | | 437 -------------- ------------ -------------- 438 || 439 || 440 ||BRB3 441 ------------ 442 | | 443 |TRILL Campus| 444 | | 445 | | 446 | | 447 | | 448 | | 449 -----RB3---- 451 These VPN's could be established statically or dynamically. In order 452 to establish dynamically, the border RBridges needs to exchange 453 information of the nicknames and connect different sites. The 454 hierarchical model like H-VPLS could be established as well. One 455 other option which is much similar to the first model where campuses 456 exchange TRILL nicknames with other campuses over VPN's. Though this 457 model groups different sites according to the way VPN's are 458 configured, avoiding flooding of TRILL nicknames or site independency 459 cannot be achieved. 461 4. Operational Overview 463 4.1 Campus and Backbone Areas 465 Each TRILL campus will be assigned a border RBridge. This is 466 identified using the 'Attached' bit in the IS-IS PDU. The border 467 RBridge has list of the RBridges of each campus site. These list of 468 bridges are exchanged using the TRILL nickname aggregation sub-TLV. 469 Details of the sub-TLV are detailed in the below section. 471 Every TRILL campus campus need not exchange all the RBridge nicknames 472 with other campuses. Let us take the scenario of campus A to be 473 interconnected with campus B. In campus A, there are RBridges 474 RB1...RB10, which are interconnected in L1. These nicknames are not 475 tunneled or exchanged with other L1 campus sites. Similarly campus B 476 has RB11...RB20 and need not be distinct from campus A RBridge 477 nicknames. So, if a new campus is connected to the domain, there is 478 a conflict of nicknames. As described in the earlier section, when 479 nicknames have to be uniquely maintained, the draft describes a 480 solution. Solution with keeping same nickname across different TRILL 481 campuses will be addressed in the later versions of the draft. 483 When campuses are interconnected over WAN links, there are two 484 possible terminations of the WAN links, the border RBridge and an 485 edge PE device. If the RBridge is connected to PE device, the TRILL 486 frames could be sent over the link connecting to the PE device to be 487 transported across WAN. This process is transparent to the TRILL 488 network and the RBridge doesn't remove the TRILL encapsulation, 489 rather tunnel the frames over the WAN to the far end RBridge. 491 There are many ways the WAN connections could be provided from 492 RBridge. GRE tunnels, IP tunnels, MPLS LSP's etc. Details of these is 493 outside the scope of this draft as it is transparent to RBridge. 495 The border RBridges will have the complete information of its campus 496 RBridges. Not all of the RBridges nicknames need to be advertised 497 globally. So, the globally exchanged nicknames of RBridges should be 498 unique across campuses. Depending on the policy established, these 499 Border RBridges will exchange the TRILL information with other campus 500 border Bridges, between different campuses. In IS-IS domain the 501 equivalent of this is the L2 backbone area, which in this case, is 502 established over WAN. 504 4.2 Unicast forwarding 506 If the destination TRILL nickname is not known, the originating or 507 transit RBridges forwards it to border RBridge. As the border RBridge 508 has all the nicknames of each campus, it forwards the frame to the 509 right campus border RBridge, which in turn could forward within its 510 campus as per base protocol specification [RFC6325]. In the case 511 where the destination is unknown, the frame is flooded to each 512 campus. Using the MAC learning procedures, the associated RBridge 513 will be learnt for the subsequent frames to be forwarded as unicast, 514 instead of flooding. Flooding into various campuses or TRILL data 515 sites happen only if the the frame is of global ID based on VLAN 516 identification. 518 4.3 Multicast Forwarding 520 Whether the traffic scope is local or global across campuses is 521 identified by VLAN or port or fine-grain label. If the traffic is to 522 be forwarded within campus, it is done using the local tree. But if 523 the forwarding has to be done globally, it needs to use the global 524 tree. When the frame has global context, it will be flooded into 525 other TRILL sites as well. 527 Multicast networks are established within the core networks. In the 528 case of RBridges, which are part of the customer networks and do not 529 participate in the core networks and their topologies, the multicast 530 tree could be built using IP multicast or leverage MVPN services 531 offered by the core network service provider. The global trees are 532 established between border RBridges with the help of information 533 exchanges between border RBridges. As the IS-IS is limited to 534 individual campus sites, the information for the backbone tree over 535 WAN has to be exchanged between border RBridges either as a IP 536 multicast PIM message or specific TLV indented for other campus 537 border RBridges. More details on this will be added in the later 538 versions of the draft. 540 -------------- ------------ -------------- 541 | | | | | | 542 |TRILL Campus1 | | WAN | | TRILL Campus2| 543 | | | | | | 544 | BRB1===| |====BRB2 | 545 RB1 | | | | RB2 546 | | | | | | 547 | | | | | | 548 -------------- ------------ -------------- 549 || 550 || 551 ||BRB3 552 ------------ 553 | | 554 |TRILL Campus| 555 | 3 | 556 | | 557 | | 558 | | 559 | | 560 -----RB3---- 562 In the above figure when the multicast frame has to be sent from 563 campus 1 to campus 2 and 3, the frame arrives at border RBridge BRB1. 564 With the default global tree between border RBridges of different 565 campuses, the forwarding is setup to egress the frame or replicated 566 over multicast trees to all other campus sites. If the frame is 567 destined for non-default global tree, the frame is forwarded 568 according to the forwarding information established for the tree. 570 Once the frame is reached on the border router of the campuses, the 571 frame is locally multicast forwarded. The same technique as employed 572 in the multilevel draft [TISSA-MLEVEL] is used here as well. 574 If mVPN services are deployed interconnecting campus sites, the 575 multicast tree is built over these services based on the customer 576 VLANs. 578 4.4 MAC learning 580 When a frame is to be forwarded from customer MAC A to customer MAC 581 B, the frame is set as unknown unicast frame over TRILL networks. If 582 the MAC A and MAC B are connected over WAN, the frame is transmitted 583 over WAN to the other campus. When the frame is reached at the 584 RBridge connecting to MAC B, it will learn about the originator 585 RBridge for MAC A. While responding, the egress RBridge know the 586 originating RBridge, it will unicast the frame to the originator. 588 4.5 TRILL nickname aggregation 590 Nicknames are allocated or assigned to RBridges in a given campuses 591 using various methods. It could be OSS, CLI or could be a dynamic 592 control protocol which configures the nicknames. As the nicknames are 593 confined to each L1 area, the nickname management, when sites are 594 connected over WAN, it is essential to optimize the name allocation 595 in order to use the name space effectively. Name allocation is not in 596 the scope of this draft. If there is a necessity, the topic could be 597 considered in the later revisions of the draft. For this version we 598 do recommend some of the optimization techniques for nickname 599 allocation defined in the multilevel draft [TISSA-MLEVEL]. 601 Each border RBridges needs to exchange the nicknames of each campuses 602 with other border RBridges. As the border RBridges are connected over 603 various types of WAN networks, mandating enhancement to a specific 604 protocol is deemed not the right approach. As the information 605 exchange has to be done, certain characteristics for the data 606 exchange have to be met. 608 o The amount of data exchange has to be minimal and optimized. 610 o the information exchange has to be quick. 612 o Conflicts and duplicate information flow has to be avoided 614 This draft proposes a generic TLV, which is to be exchanged between 615 border RBridges. If the nickname allocation is done in terms of 616 ranges, the same could be exchanged between border RBridges, 617 seamlessly. As the TLV has to be terminated at the border RBridges, 618 it is better suited to be sent as a unicast message to the 619 neighboring border RBridge. This could be sent as an IP message with 620 TRILL header containing the target border RBridge. More details on 621 how to encapsulate and process the frame should be in the later 622 versions of the draft. 624 5. TRILL campus inter-connectivity 626 The primary reason to interconnect TRILL campuses is to maintain 627 geographically distant, segmented sites and customer specific 628 segregation possible by interconnecting and not having to redo the 629 network and campus redesign for every change and need. With customers 630 being mobile or services offered by service providers could be re- 631 located depending on the time-zones and resource availability, 632 restricting to a specific site is a thing of the past. 634 These constraints brought forth the need to have different sites 635 interconnected over the WAN, be it MPLS or VPLS or IP and to provide 636 the services on demand to meet the needs of customers and their data 637 center needs. As TRILL has proven to be an effective protocol by 638 bringing routing technologies into bridges or L2 forwarding, the 639 short coming of TRILL interconnect is to be overcome. As eluded to in 640 the earlier sections on different kinds of solutions, meeting all the 641 needs of the TRILL campus extension as laid out in the requirements 642 section, is the primary goal of this draft. 644 5.1 Border RBridges interconnection 646 Border RBridges only participate in interconnecting various TRILL 647 campuses. These border RBridges are elected or identified as 648 described in the earlier section i.e. using IS-IS protocol 649 advertisement. These border RBridges, when required to interconnect 650 with other campuses, over WAN, depending on configuration of choice, 651 an overlay tunnels like GRE could be established between the border 652 RBridges. advertise the route to other site border RBridges using the 653 BGP enhancement. The connectivity between different campuses over WAN 654 is already established. When two RBridges needs to be connected over, 655 a GRE or IP tunnel is established between those two. Detailed 656 mechanisms on this establishments will be addressed in the later 657 versions of the draft. 659 If L2 connectivity is to be used with protocols like VPLS, a similar 660 method could be employed, where the PWE3 could be established between 661 border RBridges. More details to be added in the later versions of 662 the draft. 664 5.2 Inter-site nickname exchange 666 There are three types of nicknames which are exchanged between border 667 RBridges. 669 o Nickname of border RBridges 671 o Nicknames of RBridges for each campus 673 o Nicknames of RBridges which are part of a specific customer VLAN or 674 VPN 676 The nickname aggregation TLV is used as payload to be exchanged 677 between border RBridges. This information is used to establish inter- 678 connectivity between TRILL sites per customer VLAN or default global 679 tree. There exchange of information could be done with existing 680 protocols and is not restricted to any specific protocol. 682 5.3 Border RBridge capability exchange 683 An additional capability TLV is defined to exchange info on what each 684 of the border RBridge is capable of. This is very essential for 685 forward and backward capability . Capability information not only 686 indicates the capability version but could also force the 687 interconnection to be restricted as per the policy set by the 688 customer. Some of the capability advertisements are as follows. 690 o Version. 692 o default nick name resolution 694 o connect more campuses 696 o active-active link support 698 o Ability to support multicast forwarding 700 5.4 TRILL adjacency resolution 702 When a frame is to be forwarded from one campus to another, the 703 adjacency resolution has to be done on the border RBridge. When TRILL 704 nicknames are advertised from one border RBridge to another, the 705 border RBridge keeps the database of all the nicknames. 707 Once the frame is received on the border RBridge, it will look in the 708 forwarding table to identify the next hop. The adjacency information 709 could indicate the outgoing WAN encapsulation. For VPN, there could 710 be additional encapsulation depending on the network configuration. 711 The TRILL frame is encapsulated, without removing the TRILL header 712 and is forwarded over the WAN link. 714 5.5 Forwarding of data frames 716 The TRILL frames are forwarded as per the base protocol [RFC6325] 717 within a campus site. The forwarding of the frames from TRILL campus 718 to campus over WAN connection is pre-established between border 719 RBridges. The encapsulation of the Frame with WAN header is based on 720 the adjacency resolution made in the forwarding on the border 721 RBridge. 723 6. Proposed additions and extensions 725 There are certain extensions being proposed in this draft to 726 interconnect TRILL campuses or datacenters. These include new 727 additions to routing and also new TLV's to exchange information 728 between border RBridges. There are few references to the extensions 729 proposed in other drafts which are used in this draft as well. 731 6.1 Border RBridge capability TLV 733 This TLV as defined in earlier section, defines the capability of a 734 border RBridge, to be exchanged with other border RBridges for 735 seamless inter-working across campus sites. 737 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type = | Length = 8 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Version | Flags | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Flags | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Definition of flag bits will be identified and defined later. 747 6.2 TRILL nickname aggregation sub-TLV 749 The nickname aggregation TLV defined in multilevel draft [TISSA- 750 MLEVEL] is used in advertising the nicknames into other border 751 Routers. Some new additions or changes will be proposed in later 752 versions of the draft. 754 7. TRILL campus extension over IP 756 7.1 Underlying Network 758 The underlying network in the TRILL campus extension over IP solution 759 could be Wide Area Network. As changes to this network are not in the 760 administrative control of the TRILL campus, TRILL over IP extends the 761 campus network by having unicast reach ability between BRbridges and 762 the ability to establish IP multicast trees over it. There are three 763 ways the TRILL campus could be extended over IP. 765 1. TRILL frames, both control and data frames are transparently 766 tunneled over IP. This is also known as overlay model. 768 2. TRILL and IS-IS control frames are terminated at the campus edge 769 and data frames are tunneled transparently. 771 3. TRILL and IS-IS control frames are terminated at the campus edge 772 and data frames are stripped off the TRILL header 774 7.2 Overlay Control Plane The TRILL over IP overlay control plane is 775 responsible for the auto-discovery of the BRbridges within the same 776 domain. The TRILL control plane traffic between BRbridges will be 777 carried over the virtual link. There is no termination of either 778 TRILL control plane or data plane frames at the edge of the TRILL 779 campus networks. 781 7.2.1 BRbridge discovery and adjacency setup BRbridges become part of 782 the domain when the join the multicast group on the underlying 783 network associated with the domain. The auto-discovery mechanism 784 happens when BRbridges peer with each other as if they were directly 785 connected at layer-2. This peering is possible as all the traffic 786 for the BRbridge is encapsulated with the underlying network 787 multicast group address and sent into the core. 789 7.2.2 Control plane packet encapsulation 791 Any BRbridge in a TRILL over IP domain should encapsulate the ISIS 792 routing information of its campus and then relay it to the other 793 BRbridges in the domain. The control frames are tunnel through the IP 794 connection established between BRbridges. 796 7.3 Overlay Data Plane 798 7.3.1 Encapsulation 800 The encapsulation format is TRILL frame encapsulated in UDP inside of 801 IPv4 or IPv6. 803 The format of the UDP IPv4 encapsulation is as follows: 805 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 |Version| IHL |Type of Service| Total Length | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Identification |Flags| Fragment Offset | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Time to Live | Protocol = 17 | Header Checksum | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Source-site TRILL Joint Device IP Address | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Destination-site TRILL Joint Device (or multicast) Address | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Source Port = xxxx | Dest Port = TBD | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | UDP length | UDP Checksum = 0 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |R|R|R|R|I|R|R|R| Overlay ID | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Instance ID | Reserved | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Outer Ethernet Header | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 827 | TRILL Header | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Inner Ethernet Header | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Ethernet Payload | 832 | | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 The format of the UDP IPv6 encapsulation is as follows: 836 1 2 3 837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 |Version| Traffic Class | Flow Label | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Payload Length | Next Header=17| Hop Limit | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | | 844 + + 845 | | 846 + Source-site TRILL Joint Device IPv6 Address + 847 | | 848 + + 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | | 852 + + 853 | | 854 + Destination-site TRILL Joint Device (or multicast) Address + 855 | | 856 + + 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Source Port = xxxx | Dest Port = TBD | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | UDP Length | UDP Checksum | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 |R|R|R|R|I|R|R|R| Overlay ID | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Instance ID | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Outer Ethernet Header | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 869 | TRILL Header | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Inner Ethernet Header | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Ethernet Payload | 874 | | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 7.4 Forwarding Process 879 7.4.1. Forwarding from an Internal Link to the Overlay 881 The forwarding within a campus is as defined in the base protocol of 882 TRILL. This section here describes the forwarding from an Internal 883 link to the Overlay Link, or vice versa. A Joint Device is a transit 884 Rbridge from TRILL point of view. When a TRILL packet is received 885 from the internal interface, egress Nickname is used to lookup the 886 Nickname table which will yield a next-hop IP address entry pointing 887 to a remote Joint Device. Then the packet is encapsulated with 888 UDP/IP header and sent over the overlay interface to destination 889 Joint Device at Layer-3 as a regular IP packet. 891 7.4.2. Forwarding from the Overlay Link to an Internal Link When a 892 packet is received on the overlay interface, it will be IP de- 893 capsulated to reveal the inner TRILL(including the outer MAC) header 894 for forwarding. The egress Nickname will used for forwarding, the 895 forwarding action is same as a transit RBridge. 897 7.4.5. Mac Address Learning 899 The TRILL edge devices learn remote MAC addresses(including the MAC 900 addresses in other data centers) in data plane by hardware. In most 901 cases, the Joint device is like a transit RBridge, and doesn't learn 902 end host's MAC addresses. From campus extension perspective, the 903 border device is DCI device at the same time, so TRILL over WAN can 904 relieve the pressure of MAC addresses table capability in DCI device. 906 7.4.6. Multi-homing 908 In the situation of multi-homing shown as Figure 3, all the BRbridges 909 can be active by the nature of TRILL. Figure 4 shows what the 910 resulting forwarding tables would look like in the multi-homing 911 example. 913 +---+ L1 +---+ IPA -------- IPD +---+ +---+ 914 |S10|----| S1|-------- / \ ---------|S4 |----|S21| 915 +---+ +---+ / \ +---+ +---+ 916 \/L2 | IP Core | \/ 917 /\ | Network | /\ 918 +---+ +---+ IPB \ / IPC +---+ +---+ 919 |S11|----|S2 |-------- \ / ---------|S3 |----|S20| 920 +---+ +---+ -------- +---+ +---+ 922 S1 923 +----------------------+ 924 |Nickname |Interface | 925 +----------------------+ 926 | S1 | self | 927 +----------------------+ 928 | S2 | - | 929 +----------------------+ 930 | S3 | IPC | 931 +----------------------+ 932 | S4 | IPD | 933 +----------------------+ 934 | S10 | L1 | 935 +----------------------+ 936 | S11 | L2 | 937 +----------------------+ 938 | S20 | IPC/IPD | 939 +----------------------+ 940 | S21 | IPC/IPD | 941 +----------------------+ 943 In S1 device, the traffic destined to S10 and S21 have two next hops, 944 IPC and IPD. In forwarding process, hashing of TRILL packet inner 945 information will be used to determine which next hop IP address to 946 use. Thus, the ingress traffic will be load balanced between 947 multiple Joint Devices within a site. 949 7.5 Control plane termination 950 When TRILL campuses are extended by interconnecting them, the 951 administrative domain for control plane could be independent, where 952 as the data plane could be transparently interconnected. This 953 requires the campus border RBridges to terminate the control plane. 954 The IS-IS control frames do not get encapsulated and sent over to the 955 the IP connection. Border RBridges exchange the campus information 956 over IP in order to program the forwarding table and adjacency 957 resolution. 959 Data frames when arrived at the border RBridges, destined for the 960 other campus, will be looked for adjacency and encapsulated with IP 961 and sent over the IP. In the case of multicast, the TRILL frame is 962 encapsulated and sent over IP multicast network. 964 7.6 Control plane termination and Data plane de-capsulation 966 When two campuses are interconnected but no control plane or data 967 plane is extended over the WAN, the TRILL frames are stripped off the 968 TRILL header at the border RBridge of the campus. The payload is then 969 encapsulated as a regular IP packet and sent over the IP network to 970 the other campus. This requires the border RBridges to learn the host 971 MAC address to properly encapsulate as IP packet and routed across 972 the WAN link. 974 8 Security Considerations 976 978 9 IANA Considerations 980 It is requested that the IANA allocate the following UDP Ports for 981 the TRILL IS-IS and Data channels: 983 UDP Port Protocol 985 TBD TRILL IS-IS Channel 986 TBD TRILL Data Channel 988 10 References 990 10.1 Normative References 992 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, March 1997. 995 [RFC2234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 996 Syntax Specifications: ABNF", RFC 2234, November 1997. 998 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 999 "Intermediate System to Intermediate System (IS-IS) 1000 Extensions for Advertising Router Information", RFC 4971, 1001 July 2007. 1003 [RFC6325] Perlman, R., et.al, "Routing Bridges (RBridges): Base 1004 Protocol Specification", RFC 6325, July 2011. 1006 [trillcmt]Senevirathne, T., et.al, "Coordinated Multicast Trees 1007 (CMT)for TRILL", Work in Progress, January 2012. 1009 9.2 Informative References 1011 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 1012 Ghanwani, "Transparent Interconnection of Lots of Links 1013 (TRILL) Use of IS-IS", RFC 6326, July 2011. 1015 [RFC6326] Eastlake, D, et.al, "Transparent Interconnection of Lots of 1016 Links (TRILL) Use of IS-IS", RFC 6326, July 2011. 1018 [rfc6326bis] Eastlake, D, et.al, "Transparent Interconnection of Lots 1019 of Links (TRILL) Use of IS-IS", Work in Progress, draft- 1020 eastlake-isis-rfc6326bis-04.txt, January 2012. 1022 [TISSA-MLEVEL] Senevirathne, "RBridges: Multilevel TRILL", Work in 1023 Progress, draft-tissa-trill-multilevel-00.txt, February 1024 2012. 1026 [PBB-EVPN] Sajassi, et.al, "PBB-EVPN", Work in Progress, draft-ietf- 1027 l2vpn-pbb-evpn-03, June 2012. 1029 [TRILL-EVPN] Sajassi, et.al, "TRILL-EVPN", Work in Progress, draft- 1030 ietf-l2vpn-trill-evpn-00, June 2012. 1032 Authors' Addresses 1034 Sam Aldrin 1035 Huawei Technologies 1036 2330 Central Express Way 1037 Santa Clara, CA 95951 1039 Email: aldrin.ietf@gmail.com 1041 Tissa Senevirathne 1042 CISCO Systems 1043 375 East Tasman Drive 1044 San Jose CA 95134 1046 Phone: 408-853-2291 1047 Email: tsenevir@cisco.com 1049 Ayan Banerjee 1050 CISCO Systems 1051 425 East Tasman Drive 1052 San Jose CA 95134 1054 Phone: 408-527-0539 1055 Email: ayabaner@cisco.com 1057 Donald Eastlake 1058 Huawei Technologies 1059 155 Beaver Street 1060 Milford, MA 01757 USA 1062 Phone: +1-508-333-2270 1063 Email: d3e3e3@gmail.com 1065 Santiago Alvarez 1066 CISCO systems 1068 Email: saalvare@cisco.com 1070 Xiaolan Wan 1071 HangZhou H3C Tech. Co. Limited 1072 No. 2 ChuangYe Road, HaiDian District 1073 Beijing 1074 P.R. China 1076 Phone: +86 10 82774971 1077 Email: wxlan@h3c.com 1079 Xiaopeng Yang 1080 HangZhou H3C Co. Limited 1081 No. 2 ChuangYe Road, HaiDian District 1082 Beijing 1083 P.R. China 1085 Phone: +86 10 82774963 1086 Email: yxp@h3c.com