[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

INTERNET-DRAFT                                                  R. Lapuh
Intended Status: Informational                              P. Unbehagen
Expires: February 27th, 2018                            Extreme Networks
                                                              L. Stevens
                                                        P. Ashwood-Smith
                                                               E. Miller
                                                                D. Smith

                                                             August 2017

                     SPB Deployment Considerations


   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   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.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",
   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

   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


   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

   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 <AFI>.<AreaID> 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:


   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


   There are two possible approaches to ensuring uniqueness of the SPBM

   (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.


   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.


   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


   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.


   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:


   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      <Other service types to be defined>
   - 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


   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

   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

   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



   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.



   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



   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



   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

   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

   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

   [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)
   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
   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

   Srikanth Keesara
   Extreme Networks
   9 Northeastern Blvd
   Salem NH 03079 USA
   Email: skeesara@extremenetworks.com

Lapuh, R.              Expires February 27, 2018               [Page 17]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/