idnits 2.17.1 draft-xl-trill-over-wan-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (June 8, 2012) is 4311 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) == Unused Reference: 'I-D.hasmit-otv' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC6325' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC6327' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-hasmit-otv-03 ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Wan 3 Internet-Draft X. Yang 4 Intended status: Standards Track HangZhou H3C Co. Limited 5 Expires: December 10, 2012 V. Manral 6 A. Retana 7 Hewlett-Packard Co. 8 June 8, 2012 10 Extending TRILL over WAN 11 draft-xl-trill-over-wan-01.txt 13 Abstract 15 TRILL is a key technology for large-scale layer 2 networking within a 16 data center, TRILL over WAN_(ToW) provides a scalable and simple 17 solution that interconnect multiple TRILL networks to form a single 18 TRILL domain using the currently deployed enterprise or service 19 provider networks. This document provides an overview of this 20 solution. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 10, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Provider Control Plane . . . . . . . . . . . . . . . . . . 5 60 3.2. Overlay Control Plane . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Edge Device Discovery and Adjacency setup . . . . . . 5 62 3.2.2. Control Plane Packet Encapsulation and Relay . . . . . 5 63 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Forwarding Process . . . . . . . . . . . . . . . . . . . . 8 66 4.2.1. Forwarding from an Internal Link to the Overlay . . . 8 67 4.2.2. Forwarding from the Overlay Link to an Internal 68 Link . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2.3. Multicast Packet Flows . . . . . . . . . . . . . . . . 8 70 4.2.4. Broadcast Packet Flows . . . . . . . . . . . . . . . . 8 71 4.2.5. Mac Address Learning . . . . . . . . . . . . . . . . . 8 72 4.2.6. Multi-homing . . . . . . . . . . . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6.1. Failure Separation . . . . . . . . . . . . . . . . . . . . 10 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Overview 82 TRILL over WAN is a technology for supporting L2 VPNs over an L2/L3 83 infrastructure. It provides an "over-the-top" method of doing 84 virtualization among several sites where the routing and forwarding 85 state is maintained at the network edge, but not within the site or 86 in the core. 88 TRILL over WAN can reside in a small number of device at the edge 89 between TRILL sites and the core, we call these devices "Joint 90 Devices" which perform typical transit Rbridges functions(nickname- 91 based forwarding) and perform overlay functions on their core facing 92 interfaces. 94 TRILL traffic which requires traversing the WAN to reach its 95 destination, is prepended with an IP header. As shown in figure1, if 96 a destination RBridge(Nickname) is reachable via Joint Device S2(with 97 a core facing IP address of IPB), other Joint Devices forwarding 98 traffic to such Rbridge will add on IP header with a destination IP 99 address of IPB and forward the traffic into the core. The core will 100 forward traffic based on IP address IPB, once the traffic makes it to 101 Joint Device S2 it will be stripped of the overlay IP header and it 102 will be forwarded into the site in the same way a regular RBridge 103 would forward a packet. Broadcast or multicast traffic is 104 encapsulated with a multicast header and follows a similar process. 106 +---+ +---+IPA --------- IPB +---+ +---+ 107 |S10|-----|S1 |----/ IP Core \----|S2 |-----|S20| 108 +---+ ^ +---+ \ Network / +---+ ^ +---+ 109 | --------- | 110 | | 111 | +------------+ | 112 | | DA=IPB | | 113 | +------------+ | 114 | | SA=IPA | | 115 +------------+ +------------+ +------------+ 116 |Outer Eth. | |Outer Eth. | |Outer Eth. | 117 |Header | |Header | |Header | 118 +------------+ +------------+ +------------+ 119 |TRILL Header| |TRILL Header| |TRILL Header| 120 +------------+ +------------+ +------------+ 121 |Inner Eth. | |Inner Eth. | |Inner Eth. | 122 |Frame | |Frame | |Frame | 123 +------------+ +------------+ +------------+ 124 Figure 1: Traffic encapsulation 126 The key piece that TRILL over WAN adds is the state to map a given 127 egress Nickname to an IP address of the Joint Device behind which 128 that egress Nickname is located. TRILL over WAN forwarding is a 129 function of mapping a destination Nickname to a Joint Device IP 130 address in the overlay network. 132 To achieve this, a control plane is required to exchange the 133 reachability information among different Joint Devices. After Joint 134 Device discovery and adjacency setup, the virtual links to neighbor 135 Joint Devices will be treated as TRILL interface, and the TRILL's 136 control plane runs over these virtual links. Through these steps, 137 all the Rbridges in multiple site forms a single TRILL domain. Each 138 Rbridge (including Joint Device) calculates its TRILL forwarding 139 table independently. Figure 2 shows what the resulting forwarding 140 tables look like in a simple example. 142 +---+ L11+---+IPA --------- IPB +---+ L21+---+ 143 |S10|----|S1 |----/ IP Core \----| S2|----|S20| 144 +---+ +---+ \ Network / +---+ +---+ 145 --------- 147 S1 S2 148 +----------------------+ +-------------------+ 149 |Nickname |Interface | |Nickname |Interface| 150 +----------------------+ +-------------------+ 151 | S10 | L11 | | S10 | IPA | 152 +----------------------+ +-------------------+ 153 | S20 | IPB | | S20 | L21 | 154 +----------------------+ +-------------------+ 155 | S1 | self | | S1 | IPA | 156 +----------------------+ +-------------------+ 157 | S2 | IPB | | S2 | self | 158 +----------------------+ +-------------------+ 160 Figure 2: Forwarding Tables 162 TRILL over WAN supports multi-homing for sites where one or more of 163 the Joint Devices connected to core network. It can support active- 164 active multi-homing capability and loop elimination by nature of 165 TRILL. No need to add other extra mechanism. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 [[anchor2: NOTE TO RFC EDITOR: Please remove the following text 174 before publication.]] 175 Some ideas of this specification is being discussed on the EAI 176 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 177 information about subscribing. The list's archive is at 178 http://www1.ietf.org/mail-archive/web/ima/index.html. 180 3. Control Plane 182 3.1. Provider Control Plane 184 The provider control plane enables unicast reachability among the 185 Joint Devices and also provides the multicast group than makes Joint 186 Devices adjacent from the overlay control plane perspective. It also 187 provides the multicast trees in the core that will be used for 188 optimal forwarding of the TRILL data traffic. 190 3.2. Overlay Control Plane 192 The overlay control plane provides auto-discovery of the Joint 193 Devices that are members of an overlay VPN. 195 The TRILL control plane traffic between Joint Devices of different 196 sites will be carried over the virtual link. 198 Detailed to be added. 200 3.2.1. Edge Device Discovery and Adjacency setup 202 See draft-hasmit-otv-03 2.2.1. 204 3.2.2. Control Plane Packet Encapsulation and Relay 206 Any Jonit Device of the site is virtual link with the other Jonit 207 Devices of the other sites. Any Jonit Device should encapsulate the 208 ISIS routing information of its site, and then relay it to the other 209 Joint Devices of the other sites. 211 There is no different between the virtual links and the physical 212 links to the TRILL protocol. The TRILL protocol calculates the 213 routing information among the whole TRILL domain. 215 4. Data Plane 217 4.1. Encapsulation 219 The encapsulation format is TRILL frame encapsulated in UDP inside of 220 IPv4 or IPv6. 222 The format of the UDP IPv4 encapsulation is as follows: 224 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |Version| IHL |Type of Service| Total Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Identification |Flags| Fragment Offset | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Time to Live | Protocol = 17 | Header Checksum | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Source-site TRILL Joint Device IP Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Destination-site TRILL Joint Device (or multicast) Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Source Port = xxxx | Dest Port = TBD | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | UDP length | UDP Checksum = 0 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 |R|R|R|R|I|R|R|R| Overlay ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Instance ID | Reserved | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Outer Ethernet Header | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 247 | TRILL Header | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Inner Ethernet Header | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Ethernet Payload | 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The format of the UDP IPv6 encapsulation is as follows: 256 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |Version| Traffic Class | Flow Label | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Payload Length | Next Header=17| Hop Limit | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 + + 265 | | 266 + Source-site TRILL Joint Device IPv6 Address + 267 | | 268 + + 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 + + 273 | | 274 + Destination-site TRILL Joint Device (or multicast) Address + 275 | | 276 + + 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Source Port = xxxx | Dest Port = TBD | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | UDP Length | UDP Checksum | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |R|R|R|R|I|R|R|R| Overlay ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Instance ID | Reserved | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Outer Ethernet Header | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 289 | TRILL Header | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Inner Ethernet Header | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Ethernet Payload | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 4.2. Forwarding Process 299 4.2.1. Forwarding from an Internal Link to the Overlay 301 The forwarding within a site is normal TRILL forwarding, so here only 302 describes the forwarding from an Internal link to the Overlay Link, 303 or vice versa. 305 A Joint Device is a transit Rbridge from TRILL point of view. When a 306 TRILL packet is received from the internal interface, egress Nickname 307 is used to lookup the Nickname table which will yield a next-hop IP 308 address entry pointing to a remote Joint Device. Then the packet is 309 encapsulated with UDP/IP header and sent over the overlay interface 310 to destination Joint Device at Layer-3 as a regular IP packet. 312 4.2.2. Forwarding from the Overlay Link to an Internal Link 314 When a packet is received on the overlay interface, it will be IP 315 decapsulated to reveal the inner TRILL(including the outer MAC) 316 header for forwarding. The egress Nickname will used for forwarding, 317 the forwarding action is same as a transit RBridge. 319 4.2.3. Multicast Packet Flows 321 To be added. 323 4.2.4. Broadcast Packet Flows 325 To be added. 327 4.2.5. Mac Address Learning 329 The TRILL edge devices learn remote MAC addresses(including the MAC 330 addresses in other data centers) in data plane by hardware. In most 331 cases, the Joint device is like a transit RBridge, and doesn't learn 332 end host's MAC addresses. From DCI(Data Center Interconnect) 333 perspective, the Joint Device is DCI device at the same time, so 334 TRILL over WAN can relieve the pressure of MAC addresses table 335 capability in DCI device. 337 4.2.6. Multi-homing 339 In the situation of multi-homing shown as Figure 3, all the Joint 340 Devices can be active by the nature of TRILL. 342 Figure 4 shows what the resulting forwarding tables would look like 343 in the multi-homing example. 345 +---+ L1 +---+ IPA -------- IPD +---+ +---+ 346 |S10|----| S1|-------- / \ ---------|S4 |----|S21| 347 +---+ +---+ / \ +---+ +---+ 348 \/L2 | IP Core | \/ 349 /\ | Networ | /\ 350 +---+ +---+ IPB \ / IPC +---+ +---+ 351 |S11|----|S2 |-------- \ / ---------|S3 |----|S20| 352 +---+ +---+ -------- +---+ +---+ 354 Figure 3: Multi-homing Scenario 356 S1 357 +----------------------+ 358 |Nickname |Interface | 359 +----------------------+ 360 | S1 | self | 361 +----------------------+ 362 | S2 | - | 363 +----------------------+ 364 | S3 | IPC | 365 +----------------------+ 366 | S4 | IPD | 367 +----------------------+ 368 | S10 | L1 | 369 +----------------------+ 370 | S11 | L2 | 371 +----------------------+ 372 | S20 | IPC/IPD | 373 +----------------------+ 374 | S21 | IPC/IPD | 375 +----------------------+ 377 Figure 4: Forwarding Table of S1 379 In S1 device, the traffic destinated to S10 and S21 have two next 380 hops, IPC and IPD. In forwarding process, hashing of TRILL packet 381 inner information will be used to determine which next hop IP address 382 to use. Thus, the ingress traffic will be load balanced between 383 multiple Joint Devices within a site. 385 5. IANA Considerations 387 IANA need to allocate the following UDP Ports for the TRILL IS-IS and 388 Data channels: 390 UDP Port Protocol 392 TBD TRILL IS-IS Channel 393 TBD TRILL Data Channel 395 6. Security Considerations 397 6.1. Failure Separation 399 To be added. 401 7. Acknowledgements 403 Much of the wording herein was adapted from draft-hasmit-otv-03. 405 8. Normative References 407 [I-D.hasmit-otv] 408 Grover, H., Rao, D., Farinacci, D., and V. Moreno, 409 "Overlay Transport Virtualization", draft-hasmit-otv-03 410 (work in progress), July 2011. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 416 Ghanwani, "Routing Bridges (RBridges): Base Protocol 417 Specification", RFC 6325, July 2011. 419 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 420 Ghanwani, "Transparent Interconnection of Lots of Links 421 (TRILL) Use of IS-IS", RFC 6326, July 2011. 423 [RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. 424 Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, 425 July 2011. 427 Authors' Addresses 429 Xiaolan Wan 430 HangZhou H3C Co. Limited 431 No. 2 ChuangYe Road, HaiDian District 432 Beijing 433 P.R. China 435 Phone: +86 10 82774971 436 Email: wxlan@h3c.com 438 Xiaopeng Yang 439 HangZhou H3C Co. Limited 440 No. 2 ChuangYe Road, HaiDian District 441 Beijing 442 P.R. China 444 Phone: +86 10 82774963 445 Email: yxp@h3c.com 447 Vishwas Manral 448 Hewlett-Packard Co. 449 19111 Pruneridge Ave. 450 Cupertino, CA 451 USA 453 Email: vishwas.manral@hp.com 455 Alvaro Retana 456 Hewlett-Packard Co. 457 2610 Wycliff Road 458 Raleigh, NC 459 USA 461 Email: alvaro.retana@hp.com