idnits 2.17.1 draft-lapuh-spb-deployment-03.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 14 instances of lines with control characters in the document. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2017) is 2439 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6329' is defined on line 671, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Lapuh 3 Intended Status: Informational P. Unbehagen 4 Expires: February 27th, 2018 Extreme Networks 5 L. Stevens 6 Avaya 7 P. Ashwood-Smith 8 Huawei 9 E. Miller 10 D. Smith 11 Ascension 13 August 2017 15 SPB Deployment Considerations 16 draft-lapuh-spb-deployment-03 18 Abstract 20 Based on many live deployments, including the Sochi Winter Olympics 21 2014 network and multiple interoperability events, this document has 22 been created to provide advice to network operators about best 23 practices when implementing IEEE 802.1aq Shortest Path Bridging (SPB) 24 networks. It is principally addressed to system integrators, network 25 operators and solution providers, including those that do not yet 26 support SPB. Some advice to protocol implementers is also provided. 27 The intention of the advice is to facilitate multi vendor network 28 deployments as well as provide guidance for new installations. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on February 27th, 2018. 52 Copyright and License Notice 54 Copyright (c) 2017 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.2 Motivation and Background . . . . . . . . . . . . . . . . . 4 72 2. General Deployment Recommendations . . . . . . . . . . . . . . 4 73 3. Infrastructure Configuration Recommendations . . . . . . . . . 5 74 3.1 IS-IS SYSTEM ID AND SPB NICKNAME CONFIGURATION . . . . . . 6 75 3.3 SPB AND SPANNING TREE . . . . . . . . . . . . . . . . . . . 9 76 3.4 SPB FABRIC CONFIGURATION . . . . . . . . . . . . . . . . . 9 77 3.5 SPB SERVICES MAPPING . . . . . . . . . . . . . . . . . . . 10 78 3.6 SPB AND IP ROUTING . . . . . . . . . . . . . . . . . . . . 12 79 4. OA&M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5. Tenant Separation Considerations and Payment Card Industry 81 Security Requirements . . . . . . . . . . . . . . . . . . . . 13 82 6 Deployment Experiences . . . . . . . . . . . . . . . . . . . . 13 83 6.1 DEPLOYMENT SCENARIO A . . . . . . . . . . . . . . . . . . . 13 84 6.2 DEPLOYMENT SCENARIO B . . . . . . . . . . . . . . . . . . . 14 85 6.3 DEPLOYMENT SCENARIO C . . . . . . . . . . . . . . . . . . . 14 86 6.4 DEPLOYMENT SCENARIO D . . . . . . . . . . . . . . . . . . . 15 87 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 88 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 89 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 91 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 94 1 Introduction 96 This document provides a set of recommendations and reference points 97 for the deployment of [IEEE 802.1aq]/[RFC6329] - Shortest Path 98 Bridging (SPB) networks based on MAC in MAC encapsulation. It focuses 99 on the key network design items and does not go into describing the 100 protocol details. 102 The IEEE 802.1aq standard has been ratified in March 2011 and is now 103 part of IEEE 802.1Q-2014. The recommendations described here are 104 focusing on the standards based implementations. 106 1.1 Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 1.2 Motivation and Background 114 This document provides a checklist of recommendations which are based 115 on multiple documented multi vendor Interoperability tests [SPBWIKI] 116 and more than six years of standards based production deployment 117 experiences including the following scenarios: Data center 118 interconnections (DCI)for data center migrations and consolidations, 119 hosted data center virtualization, multi-site WAN and metro backbone 120 over carrier Ethernet service infrastructures, campus LAN switching 121 for multi tenant applications, IP Multicast based video surveillance 122 solutions as well as event and exposition networks. 124 It summarizes the learning's and experience acquired during those 125 activities. New SPB installations can benefit from following the 126 recommendations and deployment guidelines below. 128 2. General Deployment Recommendations 130 General Recommendation 1: 132 All the following described deployments have shown sub second 133 convergence times in case of link or nodal failures and recovery 134 within the SPB fabric. To achieve quick failure recovery, connection 135 oriented point-to-point interfaces SHOULD be used, and shared 136 segments between SPB fabric nodes SHOULD be avoided. Ethernet based 137 methods such as Ethernet based remote fault indication (RFI), IEEE 138 802.ag (CFM) or similar SHOULD be used to detect link faults quickly 139 to trigger path recalculations in case of a link or nodal failure. 141 General Recommendation 2: 143 The end-point-only provisioning for network virtualization with SPB 144 has proven very effective in many of the installations described 145 below. 147 SPB's service ID (I-SID) with its (24 bit) addressing space has 148 helped to keep the VLAN numbering (1 to 4095) local to the respective 149 access network region (e.g. Data Center or tenant), avoiding the 150 complexity of managing a global VLAN space out of a range of only 12 151 bits. In larger networks, it is RECOMMENDED to define a global 152 virtualization schema based on I-SIDs, and not tie VLAN ids directly 153 to I-SIDs in a 1 to 1 relationship throughout the network. 155 Following this practice allows implementing SPB interconnect fabrics 156 spanning multiple data centers with independent VLAN addressing 157 schemas in each data center. This practice has proven especially 158 effective during data center consolidation efforts. 160 General Recommendation 3: 162 Using SPB to keep Spanning Tree regions local to access networks 163 (therefore reducing the impact of network changes) or bringing SPB 164 all the way out to the user access switches, thus removing the need 165 for Spanning Tree altogether, can significantly improve end user 166 experience and at the same time simplify network implementations and 167 deployments. Where possible it is RECOMMENDED to use SPB as a 168 Spanning Tree protocol replacement. 170 General Recommendation 4: 172 Besides the need for L2 traffic virtualization, below described 173 deployments also required to route virtualized traffic between L2 174 services (I-SID) which constitute IP subnets/broadcast domains. 176 Routing between services (I-SIDs) can be done with dedicated routers 177 external to the SPB region, but there is a performance and deployment 178 advantage if SPB nodes can route traffic between services similar to 179 traditional routing switches that are able to perform routing between 180 VLANs/IP subnets in-band on SPB node network node to network node 181 interconnect links (NNI) links or on user to network interconnect 182 (UNI) links. With this approach IEEE 802.1aq based routing deployment 183 models are similar to traditional VLAN-tagged routing models, with 184 the advantage that the routing instance can dynamically be migrated 185 to any fabric node by extending the service I-SIDs accordingly. 187 3. Infrastructure Configuration Recommendations 188 3.1 IS-IS SYSTEM ID AND SPB NICKNAME CONFIGURATION 190 As of this writing the IEEE SPB standard defines a single IS-IS area 191 for an SPB region, even though large SPB regions can be defined and 192 operated. In the future this will likely be extended to multi-area 193 support. 195 Recommendation 5: 197 In order for an SPB network to operate it is necessary for every node 198 to be provisioned with a set of identifiers, some of which need to be 199 the same and some which need to be unique to every node. 201 SPB IS-IS Area 203 An SPB network is defined as one IS-IS Area and all SPB nodes need to 204 be provisioned with the very same IS-IS Area id in order to join the 205 SPB network. The IS-IS area format is . where AFI is two 206 hex digits and Area ID is 4 hex digits. It is RECOMMENDED to select 207 SPB IS-IS area IDs 49.xxxx where the AFI = 49 indicates locally 208 administered NSAP addresses. The xxxx field can then be used to 209 uniquely identify the SPB network. Examples of commonly used SBP IS- 210 IS Areas are "49.0000", "49.0001", etc. 212 IS-IS System ID 214 Every node in an SPB network requires a unique System ID in order to 215 operate. The IS-IS System ID of an SPB node has the same value as, 216 and defines, the node's Backbone MAC address (BMAC). Hence an SPB 217 node provisioned with IS-IS System ID 02bb.0102.3400 will use BMAC 218 02:bb:01:02:34:00. Failure to ensure the uniqueness of the IS-IS 219 System IDs can have undesirable effects on the SPB network by 220 compromising connectivity. 222 There are three possible approaches to ensuring uniqueness of the SPB 223 IS-IS System IDs. 225 (i) Let the SPB nodes auto-generate these from their burnt in MAC 226 address. MAC addresses are guaranteed to be unique so an 227 implementation which uses the burnt in MAC address to generate both 228 the BMAC and the IS-IS System ID will ensure its uniqueness. However 229 the downside of using the burnt in MAC address is that this is 230 usually not an easily recognizable ID for the SPB node. 232 (ii) The network administrator provisions unique SPB IS-IS System IDs 233 according to a well-defined allocation scheme. The available System 234 ID octets can be broken into hierarchical fields defining the node's 235 location and numbering within the SPB network. This can ease any 236 troubleshooting efforts involving packet captures since inspection of 237 the Destination & Source BMAC will clearly indicate to/from which SPB 238 BEB node the packet originates from or is destined to. The MAC 239 multicast bit must not be set and it is good practice to indicate 240 that the BMAC address has been manually configured by setting the 241 Locally Administered Address (LAA) bit. To this effect the System 242 ID/BMAC first octet SHOULD be set to 02. Likewise it is a good 243 practice to keep the last byte at 00 as some implementations will 244 require the SPB node to allocate more than one single BMAC. The 245 System ID will thus look like: 247 02yy.yyxx.xx00. 249 It is also advised to use the yy.yy bytes to reflect the location of 250 the node in the SPB network while ensuring that xx.xx remains a fully 251 unique number across the SPB network, which can then also be re-used 252 to generate a unique SPBM nick-name. 254 (iii) A hybrid of (i) and (ii) where core and distribution SPB nodes, 255 which are few, are deployed using uniquely provisioned SPB IS-IS 256 System IDs according to a well-defined allocation scheme, whereas 257 access SPB BEB nodes, which are many, are deployed with auto- 258 generated System IDs based on the device's burnt in MAC address. Core 259 and Distribution nodes are generally provisioned during initial 260 deployment, in accordance with the network design plan. Access nodes 261 however are often added throughout the network lifetime and can be 262 more prone to being misconfigured on deployment. This approach has 263 the advantage of limiting the risk of introducing an access BEB node 264 with a duplicate System ID. In this approach, the System ID allocated 265 to core and distribution nodes will again set the LAA bit using the 266 format 02yy.yyxx.xx00, as in (ii), so as to ensure that no values of 267 02:yy:yy can ever match the burnt in MAC vendor OUIs in use on the 268 access BEB nodes. 270 For best network robustness and operational simplicity it is 271 RECOMMENDED to use option (iii), when possible. 273 SPBM Shortest Path Source Identifier (SPSourceID), aka nick-name 275 Every node in an SPB network requires a unique SPBM nick-name in 276 order to operate. The nick-name's fundamental purpose is to help 277 derive a multicast BMAC address for I-SID specific multicast trees. 278 The nick-name identifier is encoded in 5 nibbles ranging from 0.00.01 279 to f.ff.ff. Failure to ensure the uniqueness of the SPBM nick-name 280 can have undesirable effects on the SPB network by compromising 281 connectivity. 283 There are two possible approaches to ensuring uniqueness of the SPBM 284 nick-name: 286 (a) Let the SPB nodes auto-generate their nick-name. Not all vendors 287 offer this capability. 289 (b) The network administrator provisions unique SPBM nick-names 290 according to a well-defined allocation scheme. The available nibbles 291 can again be broken into hierarchical fields defining the node's 292 location and numbering within the SPB network as was done for the IS- 293 IS System ID. However the available bits for such schemes is much 294 reduced in the nick-name. A better approach is to numerically 295 allocate available nick-name values ensuring their uniqueness. If the 296 allocation scheme used for the IS-IS System ID was (ii) nick-names 297 SHALL be assigned in the format of 0.xx.xx where xx.xx has the same 298 value from the System ID 02yy.yyxx.xx00. If the allocation scheme 299 used for the IS-IS System ID was (i) nick-names SHALL be assigned in 300 the format of 1.zz.zz. If the allocation scheme used for the IS-IS 301 System ID was (iii) then nick-names SHALL be assigned in the format 302 of 0.xx.xx for core and distribution SPB nodes and in the format of 303 1.zz.zz for access BEB nodes. 305 Note: On systems which are also supporting IPv6 routing on NNI links, 306 avoid using the nick name 3.33.xx, or the derived multicast MAC 307 address would overlap with the reserved Ethernet IPv6 multicast MAC 308 address 33:33:xx:xx:xx:xx. 310 3.2 SPB NETWORK LINKS 312 Details on Recommendation 1: 314 SPB Fabric inter-connections in the preceding SPB deployments are all 315 based on point-to-point Ethernet links, optical CWDM/DWDM connections 316 or some sort of transparent E-LINE service. By avoiding connecting 317 SPB over a shared segment (or E-LAN) failure detection and network 318 convergence times have been kept very low. Failure detection and 319 recovery is thus not dependent on IS-IS hello-multiplier intervals 320 but triggered by lower layer protocols. 322 E-LINE services (to interconnect SPB nodes) can be based on any type 323 of transparent Ethernet service (WDM, MPLS or PBB based), as long as 324 they are loop free and the service Maximum Transmission Unit (MTU) 325 size allows for a minimum of MTU 1544 bytes for non Jumbo Frames. 327 Tagged IP: = 1522 = 1500(IP MTU)+ 2(Ethertype)+ 12(MAC SA/DA) + 328 4(TAG) + 4 (CRC) and MacInMac Header = 22 bytes. 330 On dark-fiber based Ethernet connections, link failures can be 331 detected by the Ethernet remote fault detection mechanisms; however, 332 on service provider based links, there can be multiple active 333 components between two SPB nodes, and thus not all failures can be 334 detected by monitoring link status indications. To ensure quick fail- 335 over times across an E-LINE service, an end-to-end connectivity check 336 mechanism such as 802.1ag based Connectivity Check Mechanism (CCM), 337 or similar, is RECOMMENDED. 339 3.3 SPB AND SPANNING TREE 341 Details on Recommendation 3: 343 Many networks today are still operating with some sort of Spanning 344 Tree (MSTP/RSTP or proprietary versions). SPB can be leveraged to 345 separate Spanning Tree regions into smaller independent domains. 346 Therefore a Spanning Tree root bridge change impacts smaller regions 347 only and is not spread across the whole network. Keeping root bridge 348 elections and the effect of Topology Change Notifications local has 349 proven a significant improvement of network availability in larger 350 Spanning Tree deployments. 352 Even though SPB allows extending Spanning Tree (MSTP) domains over an 353 SPB region by sharing a MSTP-CST tree, it is only recommended keeping 354 MSTP enabled on SPB NNI links if those links also need to transport 355 non-SBP VLANs in parallel to SPB based L2 services. Result of keeping 356 MSTP enabled on SPB NNI links will be, that all VLANs which share the 357 same MSTP-CST will be affected by a CST topology change. Disabling 358 MSTP on SPB NNI links will avoid any participation of SPB services in 359 the CST state transitions and thus will increase network 360 availability. 362 3.4 SPB FABRIC CONFIGURATION 364 Recommendation 6: 366 SPB is part of the IEEE standard framework, thus it is fully 367 interoperable and compatible with all other IEEE standards. Therefore 368 SPB can be added to any IEEE standards based network infrastructure 369 without changing existing configurations, as long as there is no VLAN 370 ID overlap between the SPB backbone VLAN IDs and the traditional VLAN 371 ids. In an SPB network the Backbone VLAN IDs (BVIDs) are used to 372 separate and load-spread SPB traffic across multiple paths. The 373 802.1aq standard defines up to 16 BVIDs. These BVIDs need to be 374 consistently configured across the SPB region. The BVIDs can be 375 selected out of the available VLAN range (1-4095), however, using a 376 pre-defined set of VLANs is RECOMMENDED. 378 Usually the lowest 4000 IDs are used by customers for network access 379 VLAN configurations; thus it has been seen as a good practice to use 380 BVLAN numbering that is in the highest upper addressable range. It is 381 RECOMMENDED to start with 4051 for the primary BVLAN and all switches 382 and 4052 to 4066 for the subsequent ones. It is RECOMMENDED to use at 383 least two BVIDs for load-spreading reasons. 385 3.5 SPB SERVICES MAPPING 387 Details on Recommendation 2: 389 SPB's service ID (I-SID) with its (24 bit) addressing space provides 390 an abundant 16777215 possible values to designate networking 391 virtualized services. In some implementations a service ID name 392 attribute might be available, but these I-SID name bindings will 393 typically be localized on the SPB nodes or on the Network Management 394 platform. It is therefore advisable to devise an allocation scheme 395 for assigning I-SID service IDs, so that a given service can be 396 easily recognized from the I-SID value itself. 398 Most implementations treat the I-SID as a single decimal number much 399 like was the case for VLAN IDs. Allocation schemes SHOULD therefore 400 seek to allocate the I-SID value in decimal ranges; i.e. in the 401 format yyxxxxxx where each x is a decimal digit (0-9) and yy can 402 range between 0-15. 404 It should be noted that certain I-SID ranges are reserved and should 405 not be used. 407 On the standard side, the IEEE [802.1Q-2014] defines the following 408 reserved I-SID values: 410 - 0x000000 / 0 Null I-SID 411 - 0x000001 / 1 Default value/unassigned I-SID 412 - 0x000002 - 0x0000fe / 2-254 Reserved for future 413 - 0x0000ff / 255 SPBM Default I-SID 414 - 0xffffff / 16777215 Reserved for implementation use 416 While some vendor implementation may allow you to configure and use 417 these IEEE reserved ranges, it is best not to use these values. 419 On the vendor side, certain I-SID ranges will also be reserved for 420 advanced SPB features which typically leverage SPBM's I-SID multicast 421 trees for additional control plane functions. Typically these vendor 422 reserved I-SID ranges are at the end of the available values 423 spectrum, i.e. all I-SID values beyond 16000000. The vendor 424 documentation will need to be consulted for actual reserved ranges. 426 Finally an SPBM network provides much of the service type flexibility 427 and capability of a traditional MPLS network (where the I-SID 428 performs exactly the same function as MPLS inner labels on the data 429 plane, yet unlike MPLS, becomes a unique global ID for the service 430 type). So much like an MPLS network, an SPB network can deliver 431 service types ranging from E-LINE, E-LAN, E-TREE, IPVPN, etc. Hence 432 when allocating an I-SID to a service it is advisable to use an I-SID 433 encoding which can easily distinguish a service type from another. 435 A simple allocation scheme MAY therefore be as follows: 437 yyxxxxxx 439 Where yy can take decimal values: 441 - 00 Unused value; avoids clashing with IEEE reserved I-SID values 442 - 01 E-LINE service type 443 - 02 E-LAN/E-TREE service type 444 - 03 IPVPN service type 445 - 04-14 446 - 15 I-SIDs reserved for infrastructure side configuration 447 - 16 Unused value; avoids clashing with vendor reserved I-SID values 449 And xxxxxx is the service ID which can take any decimal value in 450 range 0-999999. Since xxxxxx is already a very large range, some 451 implementations might seek to carve out additional upper digits from 452 it to represent the administrative domain which provisioned/owns the 453 service. For instance using an allocation scheme like yyddxxxx, where 454 dd offers 256 administrative domain values for each service type and 455 with an xxxx decimal range reduced to 0-9999. 457 A final note on the xxxxxx/xxxx range is to make sure that all 458 services within the same service type (and administrative domain if 459 applicable) should allocate service IDs in a sequential manner. This 460 is particularly important on SPB vendor implementations where the SPB 461 service (I-SID) is allocated to one of the available SPB BVLANs using 462 an even/odd I-SID or round-robin I-SID allocation scheme. The 463 allocation of an I-SID to a BVLAN determines which equal cost 464 shortest path the traffic for that service will follow across the SPB 465 network and it is desirable to obtain a good spread across the 466 available BVLANs. With an even/odd I-SID allocation scheme it would 467 therefore be important to ensure that half of the I-SIDs in use are 468 even and the other half are odd numbers. If the I-SID values were to 469 be allocated ending in values 10, 20, 30, etc, this would not be the 470 case. 472 3.6 SPB AND IP ROUTING 474 Details on Recommendation 4: 476 In an SPB network the typical size of broadcast domains of user and 477 server IP subnets are similar to what one is used to with traditional 478 technologies. This means that SPB nodes at the core or aggregation 479 layer require an IPv4 and IPv6 routing functionality. Today's larger 480 SPB nodes, which are typically Ethernet routing switches can directly 481 route individual IP subnets which directly map to I-SIDs, similar to 482 how those nodes can route VLAN based IP subnets. In Enterprise 483 networks routing typically is employed at the building aggregation 484 layer while the user access layer is typically operated in a bridging 485 mode. With an SPB network, this deployment model is not changed and 486 traffic is still routed at the same layer as in traditional non-SPB 487 networks. In Enterprise data center networks, for lowest latency, 488 maximum bandwidth and to avoid unnecessary traffic tromboning, 489 traffic is typically bridged and routed at the first hope network 490 switch. The combination of bridging and routing function allows 491 extending L2 subnets for virtual machine migration, while the routing 492 function at the first hop ensures shortest path forwarding between IP 493 subnets. 495 In order to provide IP routing redundancy for access networks, VRRP 496 or similar technologies SHOULD be available and leveraged on 497 core/aggregation SPB nodes at the same time. 499 4. OA&M 501 Recommendation 8: 503 In all deployment experiences, the use of L2 based OAM capabilities 504 have been invaluable in managing the network. 506 It is RECOMMENDED that IEEE 802.1ag based Maintenance Association End 507 Point (MEP) configuration is deployed. The Maintenance Domain level 508 shall be set at least to level 4. If the SPB network is extended over 509 provider based Ethernet service infrastructure, then increasing 510 Maintenance Domain level to 5 might be required to avoid interfering 511 with Provider Domains MEP. 802.1ag based Connectivity Fault 512 Management(CFM)check mechanisms can be used to run Layer 2 Ping, 513 Layer 2 Traceroute and Layer 2 Tracetree for effective network 514 connectivity debugging. 516 5. Tenant Separation Considerations and Payment Card Industry Security 517 Requirements 519 Customer, tenant and application separation are key requirements in 520 provider or cloud hosting solutions, however are also becoming a key 521 requirement in any Enterprise network where credit card transactions 522 are being relayed. SPB separates any type of traffic at the edge of 523 the SPB region into its own service instance (I-SID). Classification 524 into the I-SID can be done based on port, vlan, a combination of 525 port/vlan or any other unique packet identifier. Once a customer- or 526 application traffic is classified into an I-SID, it is kept separate 527 until it exits the SPB region, very similar to MPLS with its tunnel 528 and service labels. In SPB the "tunnel label" is comprised of the 529 SRC/DST BMAC pair and the "service label", which is the I-SID. Thus 530 SPB enables a stealth transport of Ethernet frames across a network, 531 independent from any other tenant domain (I-SID). Widely used 532 Provider Backbone Bridging (PBB) and Shortest Path Bridging (SPB) 533 share the same IEEE 802.1ah packet frame format. 535 6 Deployment Experiences 537 6.1 DEPLOYMENT SCENARIO A 539 SPB AS DATA-CENTER-INTERCONNECT NETWORK (DCI) FOR DC REDUNDANCY OR DC 540 MIGRATIONS 542 Typically in a large enterprise core, it is not viewed as good 543 practice to extend L2 broadcast domains across the backbone network. 544 However, with the advent of server virtualization, it has become a 545 common requirement to extend server VLAN segments between geo- 546 redundant Data Centers to dynamically, efficiently and cost 547 effectively leverage the ability to perform Virtual Machine 548 migrations and run load balancing techniques across multiple Data 549 Centers. The deployment of SPB as a data center interconnect solution 550 allows the following challenges to be addressed. 552 SPB with IS-IS can be deployed natively in a data center. IS-IS is 553 being used for SPB to extend server VLANs across the backbone. 554 Typically the server VLANs to be extended across the network are 555 locally configured within the Data Centers, on the server access 556 (i.e., Top of Rack) switch ports, the server VLANs are assigned to a 557 service ID (I-SID) and then extended across the SPB network, thus 558 becoming available in any other server access switch in the local, or 559 if required, remote data center. Any IP routing protocol, including 560 SPB's IS-IS, can be used to populate the IP routing tables and 561 provide L3 routed connectivity. VRRP can provide the default gateway 562 redundancy. For more optimal forwarding in a data center where 563 bridging and routing needs to occur most efficiently, the first hop 564 network switch (i.g. Top of Rack) should provide the default gateway 565 functionality for the server VLANs. Extended L2 domains (VLANs) 566 required for virtual machine movements are most efficient, if the 567 routing gateway function is distributed across all server access 568 switches where the server VLAN resides in an active-active mode. At 569 this point vendor proprietary mechanisms are available to achieve the 570 desired distributed virtual routing capability which goes beyond the 571 single instance VRRP routing approach. 573 6.2 DEPLOYMENT SCENARIO B 575 SPB TO RE-ARCHITECT SECURITY ZONES 577 There are other valid reasons why it might be necessary to extend L2 578 segments across the enterprise core. A good example is a major 579 manufacturing plant which has a very rigorous design based on a pure 580 IP routed architecture with a strong focus on firewalling different 581 parts of the network. This is achieved by physically wedging 582 firewalls within the physical topology in such a way as to deny any 583 unwanted interaction between different network zones. The security 584 provided by this model has to be offset by the rigidity it imposes in 585 terms of where devices are allowed to be connected to the network. In 586 this particular example, connecting devices in locations where they 587 were not initially intended to be located was addressed by laying 588 additional cabling, with the costs and delays that this involves. 589 Once deployed, SPB brought to this model the ability to decouple the 590 physical infrastructure from the logical connectivity running above 591 it. This means that it is no longer necessary to wedge firewalls into 592 the physical topology to intercept traffic, but rather let SPB force 593 L2 VLANs to reach the desired firewalls, wherever those firewalls 594 might be located on the network. It is now possible to connect 595 devices anywhere on the physical network infrastructure and simply 596 connect these devices to the VLAN segment to which they need to 597 belong. 599 6.3 DEPLOYMENT SCENARIO C 601 SPB FOR CAMPUS VIRTUALIZATION 603 Another example of where it is useful to extend L2 segments can be 604 found in the health care vertical. An operational challenge, typical 605 of most hospitals, is to be able to support network connectivity for 606 mobile medical equipment which typically needs to connect to a server 607 application hosted in the Data Center. The real challenge with this 608 equipment is often the fact that it is supplied and maintained by 609 separate, often external, technicians with little or no IP skills. As 610 such this equipment is usually not able, or not configured, to use 611 DHCP and instead uses a single flat IP subnet which encompasses the 612 mobile units as well as the server application in the Data Center. 613 The hospital's network team essentially has limited control over the 614 IP configuration of these devices and hence a desire to segregate 615 such applications within a constrained L2 service. By deploying SPB 616 L2 instances, it is now possible to much more easily manage such 617 applications. 619 6.4 DEPLOYMENT SCENARIO D 621 SPB AS MULTI-TENANT FABRIC SOLUTION 623 In a multi-tenant deployment SPB is leveraged to provide secured and 624 separated services for several tenants. In this implementation SPB 625 leverages 10 Gigabit Ethernet heavily. In the two geo-disbursed data 626 centers LAN and IP connectivity is utilized in a way that makes both 627 appear as one virtual data center. A common 3-tier design is utilized 628 for the entire network. There may be multiple tenants per edge which 629 are then segregated into their own private broadcast domain. 631 Over 500 L2 services are spread across the network providing IP 632 subnet connectivity to any of the tenants. At the data center those 633 IP subnets are assigned to over a dozen of Virtual Router Forwarding 634 (VRF)instances corresponding to their security requirements. VRRP is 635 used to provide router redundancy. 637 Layer 3 routing between VRF instances, hence between tenants, to 638 external organizations and to the Internet is performed by stateful 639 firewalls. 641 This simplified model utilizing Layer 2 I-SIDs, including routing 642 between service instances, across a common SPB backbone allows this 643 solution provider to quickly and effectively extend either Layer 2 644 services or Layer 3 services to any location in the network for any 645 application. 647 For Voice over IP a Quality of Service (QoS) framework for traffic 648 prioritization has been employed. IP Differentiated Services 649 (DiffServ) EF DSCP and several specific AF DSCP groups are mapped 650 into the appropriate 802.1p priority classes at the SPB BEB nodes to 651 provide the necessary traffic prioritization within the SPB backbone. 653 7 Security Considerations 655 Security implications of SPB deployments are to be discussed in 656 separate documents. 658 8 IANA Considerations 660 This document makes no requests to IANA. 662 9 References 664 9.1 Normative References 666 9.2 Informative References 668 [IEEE 802.1aq] http://standards.ieee.org/news/2012/802.1aq.html May 669 2012 671 [RFC6329] Fedyk, D., "IS-IS Extensions Supporting IEEE 802.1aq 672 Shortest Path Bridging" July 2011 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels" March 1997 677 [SPBWIKI] http://en.wikipedia.org/wiki/Shortest_Path_Bridging 679 Authors' Addresses 681 Roger Lapuh (editor) 682 Extreme Networks 683 Leutschenbachstrasse 95 684 Zurich, 8050 SWITZERLAND 685 EMail: rlapuh@extremenetworks.com 687 Paul Unbehagen 688 Extreme Networks 689 4600 S Ulster St 690 Denver, CO 80237 USA 691 Email: punbehagen@extremenetworks.com 692 Ludovico Stevens (editor) 693 Avaya 694 25 Allee Pierre Ziller 695 06560 Valbonne, FRANCE 696 EMail: ludovicostev@avaya.com 698 Peter Ashwood-Smith (editor) 699 Huawei Technologies Canada Ltd. 700 303 Terry Fox Drive, 701 Kanata, Ontario, K2K 3J1 CANADA 702 EMail: Peter.AshwoodSmith@huawei.com 704 Eric Miller 705 Ascension 706 101 South Hanley Rd. 707 St. Louis, MO 63105, USA 708 Email: eric.miller@ascension.org 710 Daniel Smith 711 Ascension Information Services 712 20330 N Illinois St 713 Carmel, IN 46032 USA 714 Email: Daniel.smith@ascension.org 716 Steven W. Emert 717 Global Consulting Systems Engineer, APDS, ACE Fx #24 718 Extreme Networks 719 Office 603-952-6364 720 Mobile 651-226-6820 721 semert@extremenetworks.com 723 Srikanth Keesara 724 Extreme Networks 725 9 Northeastern Blvd 726 Salem NH 03079 USA 727 Email: skeesara@extremenetworks.com