INTERNET-DRAFT R. Lapuh Intended Status: Informational P. Unbehagen Expires: February 27th, 2018 Extreme Networks L. Stevens Avaya P. Ashwood-Smith Huawei E. Miller D. Smith Ascension August 2017 SPB Deployment Considerations draft-lapuh-spb-deployment-03 Abstract Based on many live deployments, including the Sochi Winter Olympics 2014 network and multiple interoperability events, this document has been created to provide advice to network operators about best practices when implementing IEEE 802.1aq Shortest Path Bridging (SPB) networks. It is principally addressed to system integrators, network operators and solution providers, including those that do not yet support SPB. Some advice to protocol implementers is also provided. The intention of the advice is to facilitate multi vendor network deployments as well as provide guidance for new installations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Lapuh, R. Expires February 27, 2018 [Page 1] INTERNET DRAFT SPB Deployment Recommendations August 2017 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 27th, 2018. Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Motivation and Background . . . . . . . . . . . . . . . . . 4 2. General Deployment Recommendations . . . . . . . . . . . . . . 4 3. Infrastructure Configuration Recommendations . . . . . . . . . 5 3.1 IS-IS SYSTEM ID AND SPB NICKNAME CONFIGURATION . . . . . . 6 3.3 SPB AND SPANNING TREE . . . . . . . . . . . . . . . . . . . 9 3.4 SPB FABRIC CONFIGURATION . . . . . . . . . . . . . . . . . 9 3.5 SPB SERVICES MAPPING . . . . . . . . . . . . . . . . . . . 10 3.6 SPB AND IP ROUTING . . . . . . . . . . . . . . . . . . . . 12 4. OA&M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Tenant Separation Considerations and Payment Card Industry Security Requirements . . . . . . . . . . . . . . . . . . . . 13 6 Deployment Experiences . . . . . . . . . . . . . . . . . . . . 13 6.1 DEPLOYMENT SCENARIO A . . . . . . . . . . . . . . . . . . . 13 6.2 DEPLOYMENT SCENARIO B . . . . . . . . . . . . . . . . . . . 14 6.3 DEPLOYMENT SCENARIO C . . . . . . . . . . . . . . . . . . . 14 6.4 DEPLOYMENT SCENARIO D . . . . . . . . . . . . . . . . . . . 15 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 Lapuh, R. Expires February 27, 2018 [Page 2] INTERNET DRAFT SPB Deployment Recommendations August 2017 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Lapuh, R. Expires February 27, 2018 [Page 3] INTERNET DRAFT SPB Deployment Recommendations August 2017 1 Introduction This document provides a set of recommendations and reference points for the deployment of [IEEE 802.1aq]/[RFC6329] - Shortest Path Bridging (SPB) networks based on MAC in MAC encapsulation. It focuses on the key network design items and does not go into describing the protocol details. The IEEE 802.1aq standard has been ratified in March 2011 and is now part of IEEE 802.1Q-2014. The recommendations described here are focusing on the standards based implementations. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Motivation and Background This document provides a checklist of recommendations which are based on multiple documented multi vendor Interoperability tests [SPBWIKI] and more than six years of standards based production deployment experiences including the following scenarios: Data center interconnections (DCI)for data center migrations and consolidations, hosted data center virtualization, multi-site WAN and metro backbone over carrier Ethernet service infrastructures, campus LAN switching for multi tenant applications, IP Multicast based video surveillance solutions as well as event and exposition networks. It summarizes the learning's and experience acquired during those activities. New SPB installations can benefit from following the recommendations and deployment guidelines below. 2. General Deployment Recommendations General Recommendation 1: All the following described deployments have shown sub second convergence times in case of link or nodal failures and recovery within the SPB fabric. To achieve quick failure recovery, connection oriented point-to-point interfaces SHOULD be used, and shared segments between SPB fabric nodes SHOULD be avoided. Ethernet based methods such as Ethernet based remote fault indication (RFI), IEEE 802.ag (CFM) or similar SHOULD be used to detect link faults quickly to trigger path recalculations in case of a link or nodal failure. Lapuh, R. Expires February 27, 2018 [Page 4] INTERNET DRAFT SPB Deployment Recommendations August 2017 General Recommendation 2: The end-point-only provisioning for network virtualization with SPB has proven very effective in many of the installations described below. SPB's service ID (I-SID) with its (24 bit) addressing space has helped to keep the VLAN numbering (1 to 4095) local to the respective access network region (e.g. Data Center or tenant), avoiding the complexity of managing a global VLAN space out of a range of only 12 bits. In larger networks, it is RECOMMENDED to define a global virtualization schema based on I-SIDs, and not tie VLAN ids directly to I-SIDs in a 1 to 1 relationship throughout the network. Following this practice allows implementing SPB interconnect fabrics spanning multiple data centers with independent VLAN addressing schemas in each data center. This practice has proven especially effective during data center consolidation efforts. General Recommendation 3: Using SPB to keep Spanning Tree regions local to access networks (therefore reducing the impact of network changes) or bringing SPB all the way out to the user access switches, thus removing the need for Spanning Tree altogether, can significantly improve end user experience and at the same time simplify network implementations and deployments. Where possible it is RECOMMENDED to use SPB as a Spanning Tree protocol replacement. General Recommendation 4: Besides the need for L2 traffic virtualization, below described deployments also required to route virtualized traffic between L2 services (I-SID) which constitute IP subnets/broadcast domains. Routing between services (I-SIDs) can be done with dedicated routers external to the SPB region, but there is a performance and deployment advantage if SPB nodes can route traffic between services similar to traditional routing switches that are able to perform routing between VLANs/IP subnets in-band on SPB node network node to network node interconnect links (NNI) links or on user to network interconnect (UNI) links. With this approach IEEE 802.1aq based routing deployment models are similar to traditional VLAN-tagged routing models, with the advantage that the routing instance can dynamically be migrated to any fabric node by extending the service I-SIDs accordingly. 3. Infrastructure Configuration Recommendations Lapuh, R. Expires February 27, 2018 [Page 5] INTERNET DRAFT SPB Deployment Recommendations August 2017 3.1 IS-IS SYSTEM ID AND SPB NICKNAME CONFIGURATION As of this writing the IEEE SPB standard defines a single IS-IS area for an SPB region, even though large SPB regions can be defined and operated. In the future this will likely be extended to multi-area support. Recommendation 5: In order for an SPB network to operate it is necessary for every node to be provisioned with a set of identifiers, some of which need to be the same and some which need to be unique to every node. SPB IS-IS Area An SPB network is defined as one IS-IS Area and all SPB nodes need to be provisioned with the very same IS-IS Area id in order to join the SPB network. The IS-IS area format is . where AFI is two hex digits and Area ID is 4 hex digits. It is RECOMMENDED to select SPB IS-IS area IDs 49.xxxx where the AFI = 49 indicates locally administered NSAP addresses. The xxxx field can then be used to uniquely identify the SPB network. Examples of commonly used SBP IS- IS Areas are "49.0000", "49.0001", etc. IS-IS System ID Every node in an SPB network requires a unique System ID in order to operate. The IS-IS System ID of an SPB node has the same value as, and defines, the node's Backbone MAC address (BMAC). Hence an SPB node provisioned with IS-IS System ID 02bb.0102.3400 will use BMAC 02:bb:01:02:34:00. Failure to ensure the uniqueness of the IS-IS System IDs can have undesirable effects on the SPB network by compromising connectivity. There are three possible approaches to ensuring uniqueness of the SPB IS-IS System IDs. (i) Let the SPB nodes auto-generate these from their burnt in MAC address. MAC addresses are guaranteed to be unique so an implementation which uses the burnt in MAC address to generate both the BMAC and the IS-IS System ID will ensure its uniqueness. However the downside of using the burnt in MAC address is that this is usually not an easily recognizable ID for the SPB node. (ii) The network administrator provisions unique SPB IS-IS System IDs according to a well-defined allocation scheme. The available System Lapuh, R. Expires February 27, 2018 [Page 6] INTERNET DRAFT SPB Deployment Recommendations August 2017 ID octets can be broken into hierarchical fields defining the node's location and numbering within the SPB network. This can ease any troubleshooting efforts involving packet captures since inspection of the Destination & Source BMAC will clearly indicate to/from which SPB BEB node the packet originates from or is destined to. The MAC multicast bit must not be set and it is good practice to indicate that the BMAC address has been manually configured by setting the Locally Administered Address (LAA) bit. To this effect the System ID/BMAC first octet SHOULD be set to 02. Likewise it is a good practice to keep the last byte at 00 as some implementations will require the SPB node to allocate more than one single BMAC. The System ID will thus look like: 02yy.yyxx.xx00. It is also advised to use the yy.yy bytes to reflect the location of the node in the SPB network while ensuring that xx.xx remains a fully unique number across the SPB network, which can then also be re-used to generate a unique SPBM nick-name. (iii) A hybrid of (i) and (ii) where core and distribution SPB nodes, which are few, are deployed using uniquely provisioned SPB IS-IS System IDs according to a well-defined allocation scheme, whereas access SPB BEB nodes, which are many, are deployed with auto- generated System IDs based on the device's burnt in MAC address. Core and Distribution nodes are generally provisioned during initial deployment, in accordance with the network design plan. Access nodes however are often added throughout the network lifetime and can be more prone to being misconfigured on deployment. This approach has the advantage of limiting the risk of introducing an access BEB node with a duplicate System ID. In this approach, the System ID allocated to core and distribution nodes will again set the LAA bit using the format 02yy.yyxx.xx00, as in (ii), so as to ensure that no values of 02:yy:yy can ever match the burnt in MAC vendor OUIs in use on the access BEB nodes. For best network robustness and operational simplicity it is RECOMMENDED to use option (iii), when possible. SPBM Shortest Path Source Identifier (SPSourceID), aka nick-name Every node in an SPB network requires a unique SPBM nick-name in order to operate. The nick-name's fundamental purpose is to help derive a multicast BMAC address for I-SID specific multicast trees. The nick-name identifier is encoded in 5 nibbles ranging from 0.00.01 to f.ff.ff. Failure to ensure the uniqueness of the SPBM nick-name can have undesirable effects on the SPB network by compromising Lapuh, R. Expires February 27, 2018 [Page 7] INTERNET DRAFT SPB Deployment Recommendations August 2017 connectivity. There are two possible approaches to ensuring uniqueness of the SPBM nick-name: (a) Let the SPB nodes auto-generate their nick-name. Not all vendors offer this capability. (b) The network administrator provisions unique SPBM nick-names according to a well-defined allocation scheme. The available nibbles can again be broken into hierarchical fields defining the node's location and numbering within the SPB network as was done for the IS- IS System ID. However the available bits for such schemes is much reduced in the nick-name. A better approach is to numerically allocate available nick-name values ensuring their uniqueness. If the allocation scheme used for the IS-IS System ID was (ii) nick-names SHALL be assigned in the format of 0.xx.xx where xx.xx has the same value from the System ID 02yy.yyxx.xx00. If the allocation scheme used for the IS-IS System ID was (i) nick-names SHALL be assigned in the format of 1.zz.zz. If the allocation scheme used for the IS-IS System ID was (iii) then nick-names SHALL be assigned in the format of 0.xx.xx for core and distribution SPB nodes and in the format of 1.zz.zz for access BEB nodes. Note: On systems which are also supporting IPv6 routing on NNI links, avoid using the nick name 3.33.xx, or the derived multicast MAC address would overlap with the reserved Ethernet IPv6 multicast MAC address 33:33:xx:xx:xx:xx. 3.2 SPB NETWORK LINKS Details on Recommendation 1: SPB Fabric inter-connections in the preceding SPB deployments are all based on point-to-point Ethernet links, optical CWDM/DWDM connections or some sort of transparent E-LINE service. By avoiding connecting SPB over a shared segment (or E-LAN) failure detection and network convergence times have been kept very low. Failure detection and recovery is thus not dependent on IS-IS hello-multiplier intervals but triggered by lower layer protocols. E-LINE services (to interconnect SPB nodes) can be based on any type of transparent Ethernet service (WDM, MPLS or PBB based), as long as they are loop free and the service Maximum Transmission Unit (MTU) size allows for a minimum of MTU 1544 bytes for non Jumbo Frames. Tagged IP: = 1522 = 1500(IP MTU)+ 2(Ethertype)+ 12(MAC SA/DA) + Lapuh, R. Expires February 27, 2018 [Page 8] INTERNET DRAFT SPB Deployment Recommendations August 2017 4(TAG) + 4 (CRC) and MacInMac Header = 22 bytes. On dark-fiber based Ethernet connections, link failures can be detected by the Ethernet remote fault detection mechanisms; however, on service provider based links, there can be multiple active components between two SPB nodes, and thus not all failures can be detected by monitoring link status indications. To ensure quick fail- over times across an E-LINE service, an end-to-end connectivity check mechanism such as 802.1ag based Connectivity Check Mechanism (CCM), or similar, is RECOMMENDED. 3.3 SPB AND SPANNING TREE Details on Recommendation 3: Many networks today are still operating with some sort of Spanning Tree (MSTP/RSTP or proprietary versions). SPB can be leveraged to separate Spanning Tree regions into smaller independent domains. Therefore a Spanning Tree root bridge change impacts smaller regions only and is not spread across the whole network. Keeping root bridge elections and the effect of Topology Change Notifications local has proven a significant improvement of network availability in larger Spanning Tree deployments. Even though SPB allows extending Spanning Tree (MSTP) domains over an SPB region by sharing a MSTP-CST tree, it is only recommended keeping MSTP enabled on SPB NNI links if those links also need to transport non-SBP VLANs in parallel to SPB based L2 services. Result of keeping MSTP enabled on SPB NNI links will be, that all VLANs which share the same MSTP-CST will be affected by a CST topology change. Disabling MSTP on SPB NNI links will avoid any participation of SPB services in the CST state transitions and thus will increase network availability. 3.4 SPB FABRIC CONFIGURATION Recommendation 6: SPB is part of the IEEE standard framework, thus it is fully interoperable and compatible with all other IEEE standards. Therefore SPB can be added to any IEEE standards based network infrastructure without changing existing configurations, as long as there is no VLAN ID overlap between the SPB backbone VLAN IDs and the traditional VLAN ids. In an SPB network the Backbone VLAN IDs (BVIDs) are used to separate and load-spread SPB traffic across multiple paths. The Lapuh, R. Expires February 27, 2018 [Page 9] INTERNET DRAFT SPB Deployment Recommendations August 2017 802.1aq standard defines up to 16 BVIDs. These BVIDs need to be consistently configured across the SPB region. The BVIDs can be selected out of the available VLAN range (1-4095), however, using a pre-defined set of VLANs is RECOMMENDED. Usually the lowest 4000 IDs are used by customers for network access VLAN configurations; thus it has been seen as a good practice to use BVLAN numbering that is in the highest upper addressable range. It is RECOMMENDED to start with 4051 for the primary BVLAN and all switches and 4052 to 4066 for the subsequent ones. It is RECOMMENDED to use at least two BVIDs for load-spreading reasons. 3.5 SPB SERVICES MAPPING Details on Recommendation 2: SPB's service ID (I-SID) with its (24 bit) addressing space provides an abundant 16777215 possible values to designate networking virtualized services. In some implementations a service ID name attribute might be available, but these I-SID name bindings will typically be localized on the SPB nodes or on the Network Management platform. It is therefore advisable to devise an allocation scheme for assigning I-SID service IDs, so that a given service can be easily recognized from the I-SID value itself. Most implementations treat the I-SID as a single decimal number much like was the case for VLAN IDs. Allocation schemes SHOULD therefore seek to allocate the I-SID value in decimal ranges; i.e. in the format yyxxxxxx where each x is a decimal digit (0-9) and yy can range between 0-15. It should be noted that certain I-SID ranges are reserved and should not be used. On the standard side, the IEEE [802.1Q-2014] defines the following reserved I-SID values: - 0x000000 / 0 Null I-SID - 0x000001 / 1 Default value/unassigned I-SID - 0x000002 - 0x0000fe / 2-254 Reserved for future - 0x0000ff / 255 SPBM Default I-SID - 0xffffff / 16777215 Reserved for implementation use While some vendor implementation may allow you to configure and use these IEEE reserved ranges, it is best not to use these values. On the vendor side, certain I-SID ranges will also be reserved for Lapuh, R. Expires February 27, 2018 [Page 10] INTERNET DRAFT SPB Deployment Recommendations August 2017 advanced SPB features which typically leverage SPBM's I-SID multicast trees for additional control plane functions. Typically these vendor reserved I-SID ranges are at the end of the available values spectrum, i.e. all I-SID values beyond 16000000. The vendor documentation will need to be consulted for actual reserved ranges. Finally an SPBM network provides much of the service type flexibility and capability of a traditional MPLS network (where the I-SID performs exactly the same function as MPLS inner labels on the data plane, yet unlike MPLS, becomes a unique global ID for the service type). So much like an MPLS network, an SPB network can deliver service types ranging from E-LINE, E-LAN, E-TREE, IPVPN, etc. Hence when allocating an I-SID to a service it is advisable to use an I-SID encoding which can easily distinguish a service type from another. A simple allocation scheme MAY therefore be as follows: yyxxxxxx Where yy can take decimal values: - 00 Unused value; avoids clashing with IEEE reserved I-SID values - 01 E-LINE service type - 02 E-LAN/E-TREE service type - 03 IPVPN service type - 04-14 - 15 I-SIDs reserved for infrastructure side configuration - 16 Unused value; avoids clashing with vendor reserved I-SID values And xxxxxx is the service ID which can take any decimal value in range 0-999999. Since xxxxxx is already a very large range, some implementations might seek to carve out additional upper digits from it to represent the administrative domain which provisioned/owns the service. For instance using an allocation scheme like yyddxxxx, where dd offers 256 administrative domain values for each service type and with an xxxx decimal range reduced to 0-9999. A final note on the xxxxxx/xxxx range is to make sure that all services within the same service type (and administrative domain if applicable) should allocate service IDs in a sequential manner. This is particularly important on SPB vendor implementations where the SPB service (I-SID) is allocated to one of the available SPB BVLANs using an even/odd I-SID or round-robin I-SID allocation scheme. The allocation of an I-SID to a BVLAN determines which equal cost shortest path the traffic for that service will follow across the SPB network and it is desirable to obtain a good spread across the available BVLANs. With an even/odd I-SID allocation scheme it would therefore be important to ensure that half of the I-SIDs in use are Lapuh, R. Expires February 27, 2018 [Page 11] INTERNET DRAFT SPB Deployment Recommendations August 2017 even and the other half are odd numbers. If the I-SID values were to be allocated ending in values 10, 20, 30, etc, this would not be the case. 3.6 SPB AND IP ROUTING Details on Recommendation 4: In an SPB network the typical size of broadcast domains of user and server IP subnets are similar to what one is used to with traditional technologies. This means that SPB nodes at the core or aggregation layer require an IPv4 and IPv6 routing functionality. Today's larger SPB nodes, which are typically Ethernet routing switches can directly route individual IP subnets which directly map to I-SIDs, similar to how those nodes can route VLAN based IP subnets. In Enterprise networks routing typically is employed at the building aggregation layer while the user access layer is typically operated in a bridging mode. With an SPB network, this deployment model is not changed and traffic is still routed at the same layer as in traditional non-SPB networks. In Enterprise data center networks, for lowest latency, maximum bandwidth and to avoid unnecessary traffic tromboning, traffic is typically bridged and routed at the first hope network switch. The combination of bridging and routing function allows extending L2 subnets for virtual machine migration, while the routing function at the first hop ensures shortest path forwarding between IP subnets. In order to provide IP routing redundancy for access networks, VRRP or similar technologies SHOULD be available and leveraged on core/aggregation SPB nodes at the same time. 4. OA&M Recommendation 8: In all deployment experiences, the use of L2 based OAM capabilities have been invaluable in managing the network. It is RECOMMENDED that IEEE 802.1ag based Maintenance Association End Point (MEP) configuration is deployed. The Maintenance Domain level shall be set at least to level 4. If the SPB network is extended over provider based Ethernet service infrastructure, then increasing Maintenance Domain level to 5 might be required to avoid interfering with Provider Domains MEP. 802.1ag based Connectivity Fault Management(CFM)check mechanisms can be used to run Layer 2 Ping, Layer 2 Traceroute and Layer 2 Tracetree for effective network connectivity debugging. Lapuh, R. Expires February 27, 2018 [Page 12] INTERNET DRAFT SPB Deployment Recommendations August 2017 5. Tenant Separation Considerations and Payment Card Industry Security Requirements Customer, tenant and application separation are key requirements in provider or cloud hosting solutions, however are also becoming a key requirement in any Enterprise network where credit card transactions are being relayed. SPB separates any type of traffic at the edge of the SPB region into its own service instance (I-SID). Classification into the I-SID can be done based on port, vlan, a combination of port/vlan or any other unique packet identifier. Once a customer- or application traffic is classified into an I-SID, it is kept separate until it exits the SPB region, very similar to MPLS with its tunnel and service labels. In SPB the "tunnel label" is comprised of the SRC/DST BMAC pair and the "service label", which is the I-SID. Thus SPB enables a stealth transport of Ethernet frames across a network, independent from any other tenant domain (I-SID). Widely used Provider Backbone Bridging (PBB) and Shortest Path Bridging (SPB) share the same IEEE 802.1ah packet frame format. 6 Deployment Experiences 6.1 DEPLOYMENT SCENARIO A SPB AS DATA-CENTER-INTERCONNECT NETWORK (DCI) FOR DC REDUNDANCY OR DC MIGRATIONS Typically in a large enterprise core, it is not viewed as good practice to extend L2 broadcast domains across the backbone network. However, with the advent of server virtualization, it has become a common requirement to extend server VLAN segments between geo- redundant Data Centers to dynamically, efficiently and cost effectively leverage the ability to perform Virtual Machine migrations and run load balancing techniques across multiple Data Centers. The deployment of SPB as a data center interconnect solution allows the following challenges to be addressed. SPB with IS-IS can be deployed natively in a data center. IS-IS is being used for SPB to extend server VLANs across the backbone. Typically the server VLANs to be extended across the network are locally configured within the Data Centers, on the server access (i.e., Top of Rack) switch ports, the server VLANs are assigned to a service ID (I-SID) and then extended across the SPB network, thus becoming available in any other server access switch in the local, or if required, remote data center. Any IP routing protocol, including SPB's IS-IS, can be used to populate the IP routing tables and provide L3 routed connectivity. VRRP can provide the default gateway redundancy. For more optimal forwarding in a data center where Lapuh, R. Expires February 27, 2018 [Page 13] INTERNET DRAFT SPB Deployment Recommendations August 2017 bridging and routing needs to occur most efficiently, the first hop network switch (i.g. Top of Rack) should provide the default gateway functionality for the server VLANs. Extended L2 domains (VLANs) required for virtual machine movements are most efficient, if the routing gateway function is distributed across all server access switches where the server VLAN resides in an active-active mode. At this point vendor proprietary mechanisms are available to achieve the desired distributed virtual routing capability which goes beyond the single instance VRRP routing approach. 6.2 DEPLOYMENT SCENARIO B SPB TO RE-ARCHITECT SECURITY ZONES There are other valid reasons why it might be necessary to extend L2 segments across the enterprise core. A good example is a major manufacturing plant which has a very rigorous design based on a pure IP routed architecture with a strong focus on firewalling different parts of the network. This is achieved by physically wedging firewalls within the physical topology in such a way as to deny any unwanted interaction between different network zones. The security provided by this model has to be offset by the rigidity it imposes in terms of where devices are allowed to be connected to the network. In this particular example, connecting devices in locations where they were not initially intended to be located was addressed by laying additional cabling, with the costs and delays that this involves. Once deployed, SPB brought to this model the ability to decouple the physical infrastructure from the logical connectivity running above it. This means that it is no longer necessary to wedge firewalls into the physical topology to intercept traffic, but rather let SPB force L2 VLANs to reach the desired firewalls, wherever those firewalls might be located on the network. It is now possible to connect devices anywhere on the physical network infrastructure and simply connect these devices to the VLAN segment to which they need to belong. 6.3 DEPLOYMENT SCENARIO C SPB FOR CAMPUS VIRTUALIZATION Another example of where it is useful to extend L2 segments can be found in the health care vertical. An operational challenge, typical of most hospitals, is to be able to support network connectivity for mobile medical equipment which typically needs to connect to a server application hosted in the Data Center. The real challenge with this Lapuh, R. Expires February 27, 2018 [Page 14] INTERNET DRAFT SPB Deployment Recommendations August 2017 equipment is often the fact that it is supplied and maintained by separate, often external, technicians with little or no IP skills. As such this equipment is usually not able, or not configured, to use DHCP and instead uses a single flat IP subnet which encompasses the mobile units as well as the server application in the Data Center. The hospital's network team essentially has limited control over the IP configuration of these devices and hence a desire to segregate such applications within a constrained L2 service. By deploying SPB L2 instances, it is now possible to much more easily manage such applications. 6.4 DEPLOYMENT SCENARIO D SPB AS MULTI-TENANT FABRIC SOLUTION In a multi-tenant deployment SPB is leveraged to provide secured and separated services for several tenants. In this implementation SPB leverages 10 Gigabit Ethernet heavily. In the two geo-disbursed data centers LAN and IP connectivity is utilized in a way that makes both appear as one virtual data center. A common 3-tier design is utilized for the entire network. There may be multiple tenants per edge which are then segregated into their own private broadcast domain. Over 500 L2 services are spread across the network providing IP subnet connectivity to any of the tenants. At the data center those IP subnets are assigned to over a dozen of Virtual Router Forwarding (VRF)instances corresponding to their security requirements. VRRP is used to provide router redundancy. Layer 3 routing between VRF instances, hence between tenants, to external organizations and to the Internet is performed by stateful firewalls. This simplified model utilizing Layer 2 I-SIDs, including routing between service instances, across a common SPB backbone allows this solution provider to quickly and effectively extend either Layer 2 services or Layer 3 services to any location in the network for any application. For Voice over IP a Quality of Service (QoS) framework for traffic prioritization has been employed. IP Differentiated Services (DiffServ) EF DSCP and several specific AF DSCP groups are mapped into the appropriate 802.1p priority classes at the SPB BEB nodes to provide the necessary traffic prioritization within the SPB backbone. Lapuh, R. Expires February 27, 2018 [Page 15] INTERNET DRAFT SPB Deployment Recommendations August 2017 7 Security Considerations Security implications of SPB deployments are to be discussed in separate documents. 8 IANA Considerations This document makes no requests to IANA. 9 References 9.1 Normative References 9.2 Informative References [IEEE 802.1aq] http://standards.ieee.org/news/2012/802.1aq.html May 2012 [RFC6329] Fedyk, D., "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging" July 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" March 1997 [SPBWIKI] http://en.wikipedia.org/wiki/Shortest_Path_Bridging Authors' Addresses Roger Lapuh (editor) Extreme Networks Leutschenbachstrasse 95 Zurich, 8050 SWITZERLAND EMail: rlapuh@extremenetworks.com Paul Unbehagen Extreme Networks 4600 S Ulster St Denver, CO 80237 USA Email: punbehagen@extremenetworks.com Lapuh, R. Expires February 27, 2018 [Page 16] INTERNET DRAFT SPB Deployment Recommendations August 2017 Ludovico Stevens (editor) Avaya 25 Allee Pierre Ziller 06560 Valbonne, FRANCE EMail: ludovicostev@avaya.com Peter Ashwood-Smith (editor) Huawei Technologies Canada Ltd. 303 Terry Fox Drive, Kanata, Ontario, K2K 3J1 CANADA EMail: Peter.AshwoodSmith@huawei.com Eric Miller Ascension 101 South Hanley Rd. St. Louis, MO 63105, USA Email: eric.miller@ascension.org Daniel Smith Ascension Information Services 20330 N Illinois St Carmel, IN 46032 USA Email: Daniel.smith@ascension.org Steven W. Emert Global Consulting Systems Engineer, APDS, ACE Fx #24 Extreme Networks Office 603-952-6364 Mobile 651-226-6820 semert@extremenetworks.com Srikanth Keesara Extreme Networks 9 Northeastern Blvd Salem NH 03079 USA Email: skeesara@extremenetworks.com Lapuh, R. Expires February 27, 2018 [Page 17]