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