idnits 2.17.1 draft-xl-trill-over-wan-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 (December 7, 2011) is 4523 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 390, but no explicit reference was found in the text == Unused Reference: 'RFC6325' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC6327' is defined on line 406, 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. -------------------------------------------------------------------------------- 1 Network Working Group XiaoLan. Wan 2 Internet-Draft XiaoPeng. Yang 3 Intended status: Standards Track HangZhou H3C 4 Expires: June 9, 2012 Vishwas. Manral 5 Alvaro. Retana 6 HP 7 December 7, 2011 9 Extending TRILL over WAN 10 draft-xl-trill-over-wan-00.txt 12 Abstract 14 TRILL is a key technology for large-scale layer 2 networking within 15 data center, most enterprises have multiple data centers in different 16 physical sites, 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 June 9, 2012. 39 Copyright Notice 41 Copyright (c) 2011 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 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Forwarding Process . . . . . . . . . . . . . . . . . . . . 8 64 4.2.1. Forwarding from an Internal Link to the Overlay . . . 8 65 4.2.2. Forwarding from the Overlay Link to an Internal 66 Link . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2.3. Multicast Packet Flows . . . . . . . . . . . . . . . . 8 68 4.2.4. Broadcast Packet Flows . . . . . . . . . . . . . . . . 8 69 4.2.5. Mac Address Learning . . . . . . . . . . . . . . . . . 8 70 4.2.6. Multi-homing . . . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 6.1. Failure Separation . . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Overview 80 TRILL over WAN is a technology for supporting L2 VPNs over an L2/L3 81 infrastructure. It provides an "over-the-top" method of doing 82 virtualization among several sites where the routing and forwarding 83 state is maintained at the network edge, but not within the site or 84 in the core. 86 TRILL over WAN can reside in a small number of device at the edge 87 between TRILL sites and the core, we call these devices "Joint 88 Devices" which perform typical transit Rbridges functions(nickname- 89 based forwarding) and perform overlay functions on their core facing 90 interfaces. 92 TRILL traffic which requires traversing the WAN to reach its 93 destination, is prepended with an IP header. As shown in figure1, if 94 a destination RBridge(Nickname) is reachable via Joint Device S2(with 95 a core facing IP address of IPB), other Joint Devices forwarding 96 traffic to such Rbridge will add on IP header with a destination IP 97 address of IPB and forward the traffic into the core. The core will 98 forward traffic based on IP address IPB, once the traffic makes it to 99 Joint Device S2 it will be stripped of the overlay IP header and it 100 will be forwarded into the site in the same way a regular RBridge 101 would forward a packet. Broadcast or multicast traffic is 102 encapsulated with a multicast header and follows a similar process. 104 +---+ +---+IPA --------- IPB +---+ +---+ 105 |S10|-----|S1 |----/ IP Core \----|S2 |-----|S20| 106 +---+ ^ +---+ \ Network / +---+ ^ +---+ 107 | --------- | 108 | | 109 | +------------+ | 110 | | DA=IPB | | 111 | +------------+ | 112 | | SA=IPA | | 113 +------------+ +------------+ +------------+ 114 |Outer Eth. | |Outer Eth. | |Outer Eth. | 115 |Header | |Header | |Header | 116 +------------+ +------------+ +------------+ 117 |TRILL Header| |TRILL Header| |TRILL Header| 118 +------------+ +------------+ +------------+ 119 |Inner Eth. | |Inner Eth. | |Inner Eth. | 120 |Frame | |Frame | |Frame | 121 +------------+ +------------+ +------------+ 123 Figure 1: Traffic encapsulation 125 The key piece that TRILL over WAN adds is the state to map a given 126 egress Nickname to an IP address of the Joint Device behind which 127 that egress Nickname is located. TRILL over WAN forwarding is a 128 function of mapping a destination Nickname to a Joint Device IP 129 address in the overlay network. 131 To achieve this, a control plane is required to exchange the 132 reachability information among different Joint Devices. After Joint 133 Device discovery and adjacency setup, the virtual links to neighbor 134 Joint Devices will be treated as TRILL interface, and the TRILL's 135 control plane runs over these virtual links. Through these steps, 136 all the Rbridges in multiple site forms a single TRILL domain. Each 137 Rbridge (including Joint Device) calculates its TRILL forwarding 138 table independently. Figure 2 shows what the resulting forwarding 139 tables look like in a simple example. 141 +---+ L11+---+IPA --------- IPB +---+ L21+---+ 142 |S10|----|S1 |----/ IP Core \----| S2|----|S20| 143 +---+ +---+ \ Network / +---+ +---+ 144 --------- 146 S1 S2 147 +----------------------+ +-------------------+ 148 |Nickname |Interface | |Nickname |Interface| 149 +----------------------+ +-------------------+ 150 | S10 | L11 | | S10 | IPA | 151 +----------------------+ +-------------------+ 152 | S20 | IPB | | S20 | L21 | 153 +----------------------+ +-------------------+ 154 | S1 | self | | S1 | IPA | 155 +----------------------+ +-------------------+ 156 | S2 | IPB | | S2 | self | 157 +----------------------+ +-------------------+ 159 Figure 2: Forwarding Tables 161 TRILL over WAN supports multi-homing for sites where one or more of 162 the Joint Devices connected to core network. It can support active- 163 active multi-homing capability and loop elimination by nature of 164 TRILL. No need to add other extra mechanism. 166 2. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 Some ideas of this specification is being discussed on the EAI 173 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 174 information about subscribing. The list's archive is at 175 http://www1.ietf.org/mail-archive/web/ima/index.html. 177 3. Control Plane 179 3.1. Provider Control Plane 181 The provider control plane enables unicast reachability among the 182 Joint Devices and also provides the multicast group than makes Joint 183 Devices adjacent from the overlay control plane perspective. It also 184 provides the multicast trees in the core that will be used for 185 optimal forwarding of the TRILL data traffic. 187 3.2. Overlay Control Plane 189 The overlay control plane provides auto-discovery of the Joint 190 Devices that are members of an overlay VPN. 192 The TRILL control plane traffic between Joint Devices of different 193 sites will be carried over the virtual link. 195 Detailed to be added. 197 4. Data Plane 199 4.1. Encapsulation 201 The encapsulation format is TRILL frame encapsulated in UDP inside of 202 IPv4 or IPv6. 204 The format of the UDP IPv4 encapsulation is as follows: 206 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |Version| IHL |Type of Service| Total Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Identification |Flags| Fragment Offset | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Time to Live | Protocol = 17 | Header Checksum | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Source-site TRILL Joint Device IP Address | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Destination-site TRILL Joint Device (or multicast) Address | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Source Port = xxxx | Dest Port = TBD | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | UDP length | UDP Checksum = 0 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |R|R|R|R|I|R|R|R| Overlay ID | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Instance ID | Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Outer Ethernet Header | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 229 | TRILL Header | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Inner Ethernet Header | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Ethernet Payload | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 The format of the UDP IPv6 encapsulation is as follows: 239 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |Version| Traffic Class | Flow Label | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Payload Length | Next Header=17| Hop Limit | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 + + 248 | | 249 + Source-site TRILL Joint Device IPv6 Address + 250 | | 251 + + 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 + + 256 | | 257 + Destination-site TRILL Joint Device (or multicast) Address + 258 | | 259 + + 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Source Port = xxxx | Dest Port = TBD | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | UDP Length | UDP Checksum | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |R|R|R|R|I|R|R|R| Overlay ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Instance ID | Reserved | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Outer Ethernet Header | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 272 | TRILL Header | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Inner Ethernet Header | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Ethernet Payload | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 4.2. Forwarding Process 282 4.2.1. Forwarding from an Internal Link to the Overlay 284 The forwarding within a site is normal TRILL forwarding, so here only 285 describes the forwarding from an Internal link to the Overlay Link, 286 or vice versa. 288 A Joint Device is a transit Rbridge from TRILL point of view. When a 289 TRILL packet is received from the internal interface, egress Nickname 290 is used to lookup the Nickname table which will yield a next-hop IP 291 address entry pointing to a remote Joint Device. Then the packet is 292 encapsulated with UDP/IP header and sent over the overlay interface 293 to destination Joint Device at Layer-3 as a regular IP packet. 295 4.2.2. Forwarding from the Overlay Link to an Internal Link 297 When a packet is received on the overlay interface, it will be IP 298 decapsulated to reveal the inner TRILL(including the outer MAC) 299 header for forwarding. The egress Nickname will used for forwarding, 300 the forwarding action is same as a transit RBridge. 302 4.2.3. Multicast Packet Flows 304 To be added. 306 4.2.4. Broadcast Packet Flows 308 To be added. 310 4.2.5. Mac Address Learning 312 The TRILL edge devices learn remote MAC addresses(including the MAC 313 addresses in other data centers) in data plane by hardware. In most 314 cases, the Joint device is like a transit RBridge, and doesn't learn 315 end host's MAC addresses. From DCI(Data Center Interconnect) 316 perspective, the Joint Device is DCI device at the same time, so 317 TRILL over WAN can relieve the pressure of MAC addresses table 318 capability in DCI device. 320 4.2.6. Multi-homing 322 In the situation of multi-homing shown as Figure 3, all the Joint 323 Devices can be active by the nature of TRILL. 325 Figure 4 shows what the resulting forwarding tables would look like 326 in the multi-homing example. 328 +---+ L1 +---+ IPA -------- IPD +---+ +---+ 329 |S10|----| S1|-------- / \ ---------|S4 |----|S21| 330 +---+ +---+ / \ +---+ +---+ 331 \/L2 | IP Core | \/ 332 /\ | Networ | /\ 333 +---+ +---+ IPB \ / IPC +---+ +---+ 334 |S11|----|S2 |-------- \ / ---------|S3 |----|S20| 335 +---+ +---+ -------- +---+ +---+ 337 Figure 3: Multi-homing Scenario 339 S1 340 +----------------------+ 341 |Nickname |Interface | 342 +----------------------+ 343 | S1 | self | 344 +----------------------+ 345 | S2 | - | 346 +----------------------+ 347 | S3 | IPC | 348 +----------------------+ 349 | S4 | IPD | 350 +----------------------+ 351 | S10 | L1 | 352 +----------------------+ 353 | S11 | L2 | 354 +----------------------+ 355 | S20 | IPC/IPD | 356 +----------------------+ 357 | S21 | IPC/IPD | 358 +----------------------+ 360 Figure 4: Forwarding Table of S1 362 In S1 device, the traffic destinated to S10 and S21 have two next 363 hops, IPC and IPD. In forwarding process, hashing of TRILL packet 364 inner information will be used to determine which next hop IP address 365 to use. Thus, the ingress traffic will be load balanced between 366 multiple Joint Devices within a site. 368 5. IANA Considerations 370 IANA need to allocate the following UDP Ports for the TRILL IS-IS and 371 Data channels: 373 UDP Port Protocol 375 TBD TRILL IS-IS Channel 376 TBD TRILL Data Channel 378 6. Security Considerations 380 6.1. Failure Separation 382 To be added. 384 7. Acknowledgements 386 Many ideas are from the discussion in the list ima@ietf.org. 388 8. Normative References 390 [I-D.hasmit-otv] 391 Grover, H., Rao, D., Farinacci, D., and V. Moreno, 392 "Overlay Transport Virtualization", draft-hasmit-otv-03 393 (work in progress), July 2011. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 399 Ghanwani, "Routing Bridges (RBridges): Base Protocol 400 Specification", RFC 6325, July 2011. 402 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 403 Ghanwani, "Transparent Interconnection of Lots of Links 404 (TRILL) Use of IS-IS", RFC 6326, July 2011. 406 [RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. 407 Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, 408 July 2011. 410 Authors' Addresses 412 XiaoLan Wan 413 HangZhou H3C 414 No.2 ChuangYe Road, HaiDian District 415 Beijing 416 P.R. China 418 Phone: +86 10 82774971 419 Email: wxlan@h3c.com 421 XiaoPeng Yang 422 HangZhou H3C 423 No.2 ChuangYe Road, HaiDian District 424 Beijing 425 P.R. China 427 Phone: +86 10 82774963 428 Email: yxp@h3c.com 430 Vishwas.Manral 431 HP 432 19111 Pruneridge Ave. 433 Cupertino, CA 434 USA 436 Email: vishwas.manral@hp.com 438 Alvaro.Retana 439 HP 440 2610 Wycliff Road 441 Raleigh, NC 442 USA 444 Email: alvaro.retana@hp.com