Juniper Networks Design Fundamentals

Juniper Networks’ Response to Request for Proposal for XYZ, INC.

Data Centre RFP

Sally Stevens
Friday 14th March 2015

www.juniper.net Sample Request for Proposal • Appendix C-3

Juniper Networks Design Fundamentals

Appendix C-4 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

JUNIPER NETWORKS CONFIDENTIALITY

NOTICE

Thank you for the opportunity to submit this non-binding (other than pricing for now-available
products listed in our quotes), subject to contract, proprietary and confidential proposal for your
consideration

Trademarks

Juniper Networks, the Juniper Networks logo, Junos, NetScreen and ScreenOS are registered
trademarks of Juniper Networks, Inc. in the United States and other countries. All other
trademarks, service marks, registered trademarks or registered service marks are the property of
their respective holders.

Statement of Product Direction (SOPD)

This RFI contains information relating to Juniper Networks’ development plans and plans for future
products, features or enhancements (“SOPD”). SOPD information is subject to change at any
time, without notice. Except as may be set forth in definitive agreements for the potential
transaction, Juniper Networks provides no assurances, and assumes no responsibility, that such
future products, features or enhancements will be introduced. Therefore, XYZ, INC. should
ensure that purchasing decisions:
a) are not being made based upon reliance of timeframes or specifics outlined in the SOPD;
and
b) would not be affected if Juniper Networks delays or never introduces the future products,
features or enhancements.

Submitted By: Sally Stevens

Telephone:
Email Address:
Distributed to: Bob Jones, Procurement Category Manager, XYZ, Inc.
Version Number: 1.0 Date: 14th March 2015

www.juniper.net Sample Request for Proposal • Appendix C-5

Juniper Networks Design Fundamentals

RFP Contacts
Name Sally Stevens
Title Account Director
Telephone 07918 947032
Email salstevens@juniper.net

Name William Wright

Title Sales Engineer
Telephone 07254 359932
Email wilwright@juniper.net

Appendix C-6 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Contents
RFP Contacts ........................................................................................................................... 6
Executive Summary ................................................................................................................ 8
Partnership ............................................................................................................................. 10
Technical Summary ............................................................................................................... 11
Technical Specifications ....................................................................................................... 13
Platform Roadmap .............................................................................................. 13
Physical Requirements ........................................................................................ 19
Future enhancements ..................................................................................................... 37
Data Centre Interconnect conclusion .............................................................................. 37
Transition Plan ....................................................................................................................... 38
Legacy to Point-of-Proof migration ...................................................................... 38
VLAN Harmonisation .................................................................................................... 47
Feature and Service Support ............................................................................... 47
Data Centre Operations’ Standards ..................................................................... 50
Virtualization, Consolidation, Expansion and Cost Innovation ............................. 51
ILNP – (Identifier-Locator Network Protocol) Juniper are considering as an alternative
standard to Cisco LISP. ................................................................................................ 57
Summary ............................................................................................................. 57
Sales Services .................................................................................................... 60
Product Introduction ............................................................................................ 62
Data Centre Network Transformation Phases .................................................................... 65
Project Management ......................................................................................... 71
Environmental Requirements .............................................................................. 73
Additional Requirements ..................................................................................... 74
Maintenance........................................................................................................ 75
References .......................................................................................................... 75
Supporting Material ............................................................................................. 76
Commercial Offering ............................................................................................................. 78
Legal ....................................................................................................................................... 79
Appendix One - Appendices................................................................................................. 80

www.juniper.net Sample Request for Proposal • Appendix C-7

Juniper Networks Design Fundamentals

Executive Summary
Juniper Networks is pleased to present to XYZ, Inc. our Data Centre solution.
We offer a proven solution such that XYZ, Inc. can deploy a cost-effective family of switches that
delivers the high availability, unified communications, integrated security and operational
excellence which you need today, whilst also providing a platform for supporting your
requirements in the future.
Working with our authorized partners, Juniper has a broad, deep and successful track record in
delivering Data Centre technology that is easy to deploy and manage which is both reliable and
cost effective, along with software and services to manage the network in a virtualized data
centre environment.
Juniper Networks has a strong footprint and track record within the Public Sector in the UK.
Several Central Government Departments utilise Juniper security solutions, as well as our
switching portfolio. We have PSN customers, for example Regional Government, as well as a
large percentage of Higher Education facilities in the UK. DFTS,
Janet and Dante, all run on secure Juniper Networks.
The Juniper switch solution offers an innovative alternative to the cost and complexity of
managing a legacy network.
Our solution will help lower your total cost of ownership through a flatter design, with a single
Networking OS, common management structure and will reduce the space, power and cooling
requirements.
Juniper solutions are designed to deliver scalable port density and performance, providing XYZ,
Inc. with an economical pay-as-you-grow approach to building your flexible and high performance
network.
The proposed solution for the DC Network Refresh provides the following key business benefits:-

• Business Continuity - No disruption of critical services when upgrades are required;

fewer physical devices to manage and reduced blast radius.
• Lower Cost of Ownership - Reduce operations overhead, increased return on security
investments, and improve continuity of operations, to deliver the most effective high
latency network and capability available.* See Appendix one for data.
• Business Agility - Comprehensive automation and provisioning capabilities to provide
increased business agility and reduced time to market for new services.
• Pay As You Grow – Juniper’s solution uses the latest QFX switch technology
(QFX5100) based around 1RU and 2RU switch platforms enabling a true pay as you
grow model.
• Financial Options – Juniper proposes traditional capex pricing models as well as flexible
pay as you go and FMV leasing.
• Green Savings – Substantial quantifiable savings on power and rack space. *See
appendix one for detail.
• Simplified Operations - Rich automated solutions that help eliminate complexities by
streamlining Data Centre operations for network provisioning, management, and
orchestration. XYZ, Inc. can improve network response times while requiring fewer
resources.

Appendix C-8 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

• Cost Performance - Juniper is a pure play organisation with significant investment back
into R & D, delivering cutting edge products at a lower cost of ownership and
procurement cost.

Thank you for the opportunity to respond. Juniper has a dedicated team available to meet with
you at your earliest convenience to discuss our proposal and answer any questions which you
may have.

www.juniper.net Sample Request for Proposal • Appendix C-9

Juniper Networks Design Fundamentals

Partnership
Juniper Networks Partner Advantage Program

Juniper Networks’ go-to-market model puts a deliberate dependency on our Authorised Partner
Community. Juniper Partners are backed up by Juniper Partner Advantage, a partner program
designed to ensure that Partners are rewarded, trained and certified to sell, design and support
Juniper products and solutions.

For the purpose of this RFP Juniper is partnering with ACME to deliver the UK Pricing schedule,
ACME is also XYZ, Inc.’s Distribution Partner, so we trust that this is the best possible
arrangement.

Juniper also has a strong partnership with XYZ, Inc. XYZ, Inc. is a Juniper Elite Portfolio and
Services partner across the complete Juniper portfolio. XYZ, Inc. can deliver and support the
entire Juniper product suite, from High End Routing, Routing, Switching, Firewalls, Secure
Routers, and Remote Access solutions. XYZ, Inc. has many Juniper certified Pre and Post
Sales Engineers and also takes part in our Ingenious Champion Program, being one of the very
few Juniper partners globally to have multiple Ingenious champions (subject matter experts in
Juniper technologies).

In addition to the delivery of Juniper solutions to a wide range of Government and Enterprise
customers (including Home Office, Centrica, G4S and Marks and Spencer), XYZ, Inc. Services
also run the XYZ, Inc. Core Network on a Juniper platform and utilise Juniper technologies
throughout its business. XYZ, Inc. is also one of Juniper’s selected EMEA marketing partners,
and is invited to participate in the Juniper Partner Advisory Council. In support of XYZ, Inc., we
have assigned a full time Partner Manager and Technical Account Manager.

Appendix C-10 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Technical Summary
The Juniper Networks technology solution offers a reliable, repeatable, secure and scalable
network that reduces the current physical footprint and meets XYZ, Inc.’s requirements for today,
whilst scaling to meet XYZ, Inc.’s requirements in the future.

The proposed solution for the DC Network provides XYZ, Inc. with the following key technical
benefits:

• Flexibility - Our solution is ultimately flexible; with virtual-chassis fabric enabling

software defined switch boundaries allowing the hardware to provide L2/L3
services today with a long roadmap through to secure full SDN implementation.

• Network Virtualisation – our virtual Chassis technology enables multiple switches

to be interconnected and operate as a single system. Users get the reliability,
availability, and high-port densities of traditional chassis-based systems in a cost-
effective, compact form factor.

• Scalability - Our solution is scalable from one virtual chassis fabric of two switches
to 32 switches per Virtual Chassis Fabric (VCF) , which can be replicated into a
series of VCF’s to meet the forthcoming implementation of virtual servers, also
allowing implementation of an elastic service to meet changing requirements
without the need for large upfront capital costs.

• Simplicity - Reduced network complexity through a single operating system, the

reduction in the number of control planes and management points across the
solution and a standardization of native 1/10/40GbE connectivity.

• Resiliency
- Our solution is resilient at component, chassis, and architectural

level. Furthermore, Juniper equipment is built to carrier grade quality with In
Service Software Upgrades (ISSU), ensuring no disruption of business critical
service when upgrades are required in the switch infrastructure.

• Reliability - Our solution leverages much of the same field-proven Juniper Carrier
technology―including high performance ASICs, system architecture and Junos
software―that powers the world’s largest service provider networks. The result is a
robust, time-tested and highly reliable infrastructure solution for high performance
networking.

• Data Centre Savings – By utilizing switches that are 1RU in size, the Juniper
solution reduces space and power consumption but increases the scale and size of
the services that can be supported and developed. * See Appendix one for data

• Interoperability – Our solution is fully standards compliant and, due to our Open
API’s, can work with legacy hardware and other vendors as required to support
migration from your current estate. We will fully support and plan your migration in
an incremental fashion. We also ensure complete configuration and testing prior to
deployment.

• Longevity of spares and support -
The hardware proposed is new to the market
and, as a result, XYZ, Inc. can expect the longest anticipated lifetime, as well as
support for 5 years from the announcement of any end of sale date. Juniper also
has a culture of improvement through software evolution.

www.juniper.net Sample Request for Proposal • Appendix C-11

Juniper Networks Design Fundamentals

• Management - Junos Space is a comprehensive Network Management Solution

that simplifies and automates management of Juniper’s switching, routing, and
security devices. Junos Space consists of a network management platform for
deep element and FCAPS management, plug-n-play management applications for
reducing costs and provisioning new services quickly, and a programmable SDK
for network customization. With each of these components working cohesively,
Junos Space offers a unified network management and orchestration solution.

All of these elements contribute to a simple cost efficient solution that provides XYZ, Inc. with a
solid foundation for the development of faster applications running on high speed virtual
platforms, to enable you to provide an excellent service to your Customer.

Appendix C-12 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Technical Specifications
Platform Roadmap
Table 13.1: Required platform roadmap detail.
Ref Requirement Weighting
R001 Please provide a platform roadmap to cover a minimum 5 year period from Mandatory
[6.2.1] the middle of 2015 till the end of 2019. The platform(s) should be available as
general release by Q2 calendar year 2015. New hardware introduced during
this period can be included if it adheres to requirement R004. It is expected
that the roadmap will include platforms capable of fulfilling scalability and
availability not less than that achievable with the current Cisco Catalyst
switches (combination of 6500-series and 3750G-series).
Juniper Juniper Networks has proposed three switches for the Server Access and
Core layer within our proposal. These include the EX4300-48T to provide
100MB and 1GbE RJ45 for existing server connectivity and the QFX5100-
48S to provide both 1GbE and 10GbE Fibre based connectivity and the
EX9200 to provide core 10GbE, 40GbE and 100GbE connectivity whilst also
providing EVPN and MPLS support for site-to-site connectivity.

The roadmap on the items specified in our response is listed below. At this
time, Statements of Product Directions (SOPD) are only issued for a 12-
month period for QFX based and EX based products.

More specific SOPD information can be obtained from our Product Line
Management Team who would be happy to attend a meeting in relation to
this bid. (Please refer to our SOPD statement within the Juniper
Confidentiality Notice)

QFX Series – QFX5100

1st Half 2015

Class of Service (CoS)

• Finer grained classification of RE generated packets

High Availability (HA) and Resiliency

• HA Feature support - NSR, GRES, NSB

• ISSU (Standalone-only)
• LAG of mixed rate links for AE bundles on QFX series
• NSB and NSR support on QFX3500, QFX3600 VC
• NSR and NSB
• NSSU support in mixed mode VCF
• VC local link preference

Infrastructure

• Hardware: 8x10GE (SFP+) QIC module for all OPUS TORs

• QFX5100-96S

www.juniper.net Sample Request for Proposal • Appendix C-13

Juniper Networks Design Fundamentals

Interfaces and Chassis

• Parallel Single Mode (PSM) optic support

IPv4

• BGP ADD PATH support

IPv6

• IPv6 match criteria for L2 ACLs

Metro Ethernet

• QinQ support
• MPLS
• RSVP auto-bandwidth

Platform and Infrastructure

• 64 WAY ECMP with OSPF/ISIS/BGP

• Flex Junos Support
• QFX5100-24Q standalone, MC-LAG,VC and VCF
• QFX5100-48T standalone, MC-LAG,VC and VCF
• QFX5100-96S Software parity with QFX5100-48S

Routing Protocols

• BGP Monitoring Protocol v3 Compliance

• Filter based GRE decapsulation and forwarding action

Switching

• Metafabric 1.1

System Management

• ZTP

Virtual Chassis

• 20 Member VCF Architecture w/ Plug & Play

• QFX5100-96S 4-member Virtual Chassis Support
• VCF members as QFX5100, EX4300, QFX3500, QFX3600

VLAN Infrastructure

• VC Local Bias

2nd Half 2015

Interfaces and Chassis

• G.8032v1 and v2

Appendix C-14 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

• Integration with VMware's NVP controller

Layer 2 Features

• VXLAN L2 Gateway

MPLS

• Loop Free Alternate Support for ISIS and OSPF (LFA)

• MPLS Phase 3

Network Management and Monitoring

• SNMPv3 support
• Operation, Administration, and Maintenance (OAM)
• 802.3ah support

Software Defined Networking (SDN)

• OpenFlow 1.3 client

Storage and Fibre Channel

• FCoE Transit on QFX3500, 3600 VC

Switching

• Metafabric 2.0

Virtual Chassis

• 32 member VCF
• ISSU support on VCF

EX Series – EX4300 and EX9200

1st Half 2015

Authentication and Access Control

• Access control : Access security UAC

• EEE (Energy Efficient Ethernet) for EX4300 copper prots
• EEE for EX4300 Copper Ports
• Protect switch from unauthorized access

High Availability (HA) and Resiliency

• EX4300 MC-LAG support

• MC-LAG

IPv6

• BGP

www.juniper.net Sample Request for Proposal • Appendix C-15

Juniper Networks Design Fundamentals

• IPv6 access security - RA guard, DHCPv6 snooping, ND

inspection, v6 source guard
• IPv6 match criteria for L2 ACLs

Management

• Nonstop software upgrade (NSSU)

Metro Ethernet

• PVLAN within switch (Private VLAN)

Multicast

• MLD Snooping v1/v2

Network Management and Monitoring

• Async support for Interface statistics on Junos(ui/kernel/pfe)

• L2NG - SFLOW for EX9204/9208/9214
• sFlow

Platform and Infrastructure

• Hardware EX4300 Fibre 2x40G Extension Module

• Hardware EX4300 Fibre 32-port Base AC SKU
• Hardware EX4300 Fibre 8x10G Fibre Extension Module
• Hardware: EX4300 Fibre 32-port Base DC SKU

Switching

• Campus 1.0
• Metafabric 1.0
• Metafabric 1.1

System Management

• Zero Touch Provisioning (ZTP) functionality

• ZTP

TBD

• Puppet Agent

Virtual Chassis

• EX4300 VC local link preference

2nd Half 2015

Authentication and Access Control

• Access control: Access security Captive Portal

• Access control: dot1x

Appendix C-16 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

• Access security 802.1x on Virtual Chassis

• Access security Captive Portal on Virtual Chassis
• Access security on Virtual Chassis
• L2NG - Access control: dot1x, captive-portal, UAC support
on VC for EX9204/9208/9214

Class of Service (CoS)

• Unknown unicast forwarding (UUF)

High Availability (HA) and Resiliency

• ISSU support with 32XS, 4QS and 2C-8XS line cards

Interfaces and Chassis

• 6-port 40GbE line cards

IPv6

• DHCPv6 Snooping and ND Inspection

• IPv6 Access/Port Security features EX4300

Layer 2 Features

• L2PT

Metro Ethernet

• Private VLAN
• PVLAN Support within a switch and across switches

Network Management and Monitoring

• Insight Technology (Microbursts Monitoring and Statistics

Reporting)
• sFlow for Virtual Chassis

Port Security

• DHCP v4 snooping on Virtual Chassis

• Dynamic Arp Inspection on Virtual Chassis
• Native analyzer SPAN and RSPAN on Virtual Chassis
• Storm control on Virtual Chassis
• Routing Policy and Firewall Filters
• ERSPAN

Software Defined Networking (SDN)

• SDN: OpenFlow v1.3

Switching

www.juniper.net Sample Request for Proposal • Appendix C-17

Juniper Networks Design Fundamentals

• Campus 1.1

VLAN Infrastructure

• VXLAN Overlay solution for EX4300

R002 Please indicate your End of Sale / Support lifecycle policy for device Mandatory
[6.2.2] hardware, particularly regarding the timeline and support availability between
End of Sale announcement and the end of product life.
Juniper Juniper End of Sale (EoS) policy for hardware devices is communicated
through the support website and directly via e-mail to the e-mail address or
support contract holder. When a product reaches its end of life (EOL), Juniper
is committed to communicating important milestones throughout the EOL
period, including the initial EOL notification, Last Order Date (LOD) for
product, End of Support (EOS) EOS milestone dates, as well as other key
information pertaining to Juniper hardware and software products. Any
product being discontinued will be announced as EOL a minimum of one
hundred-eighty (180) days prior to the discontinuation and end of sale date,
also referred to as last order date. On the last order date, products are
removed from the price list and are no longer available for purchase.

Last day of support for both hardware and software is five years after the End
of Sale date. Up to this point hardware and software will be supported under
the existing contract in place prior to the End of Sale announcement.

An example of the EOL-EOS timetable can be seen below. Please note that
this example is not specific to the technology proposed within this RFP.

Appendix C-18 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Each milestone is communicated with the support contract holder of the

equipment and via the Juniper EoL web site.
R003 Please indicate your End of Sale / Support lifecycle policy for the operating Mandatory
[6.2.3] system and any additional system software, particularly regarding the timeline
and support availability between End of Sale announcement and the end of
software support.
Juniper End of Sale and End of Support for software follows the same guidelines as
outlined in the previous question for hardware.
R004 Please confirm protocol and service compatibility across all platforms in the Mandatory
[6.2.4] roadmap i.e. full compatibility between hardware implementations with
product certification only dependent on the operating system version. Please
include supporting evidence to show where compatibility has been a feature
of, or improved by previous platform roadmaps.
Juniper The Juniper hardware runs the same version of code across all platforms in
the EX and QFX series switches. Junos is designed with compatibility
between platforms from day one and, as such, for our solution we look to run
the same version of Junos on the EX4300’s, EX9200’s and QFX5100’s to
ensure complete compatibility between the platforms. In running the same
version of code, we know that features and functions are the same and will
work in the same way across all platforms.

As and when XYZ, Inc. requires a new feature in forthcoming releases, a beta
version of that code would be released to XYZ, Inc. to test in their lab with the
results passed back to our development team. The development team would
make any changes that XYZ, Inc. have noted and then issue either as
standard code or as a special release. Juniper would suggest that XYZ, Inc.
sign up to the beta release programme and Junos development programme
so they can work with Juniper on new features.
R005 Please include major functionality introduced during the course of the Medium
[6.2.5] roadmap, this should be divided into hardware and software/operating system
specific functionality. Examples of this would include: enhancements to
product uptime, throughput, availability and support for new services &
protocols.
Juniper Please refer to Question R001 for a full list of roadmap or Statement of
Product direction (SOPD) information which includes both Hardware and
Software specific functions.
R006 Please provide any published benchmarks for the platforms in your roadmap. Medium
[6.2.6]
Juniper Please refer to Question R001 for a full list of roadmap or Statement of
Product direction (SOPD) on the platform proposed in our solution. No
internal or external published benchmark information is available in regards to
SOPD statement.

Physical Requirements
Appendix 3 details a high-level view of the current data centre networks. It also contains key
requirements which should be addressed in the supplier’s response.

Suppliers should be innovative in the introduction of new infrastructure in the data centres where
rack space and power is at a premium.
_____________________________________________________________________
Juniper: Read and Understood

www.juniper.net Sample Request for Proposal • Appendix C-19

Juniper Networks Design Fundamentals

Table 13.2: Physical Requirements

Ref Requirement Weighting

R007 Please provide your solution(s) proposal to replace the current switch Mandatory
[6.3.1] infrastructure with a completely new Data Centre switch topology for SDC01,
SDC02 and SHP01.
Juniper To provide XYZ, Inc. with the best of breed solution and a foundation upon
which new and more flexible applications can be deployed, Juniper Networks
proposes the latest QFX and EX switching solution utilising the unique
properties of Virtual Chassis Fabric to allow a multi-tenancy overlay
architecture deployed in a series of virtual switch clusters.
In proposing this form of architecture, XYZ, Inc. can move away from the
large, centralised locations for server connectivity to a more flexible
distributed solution that centres on a spine and leaf approach, but still
provides the single points of management and distributed layer 2 and layer 3
switching and routing domains they are used to.
This architecture also provides the option scaling up or down to suit the
flexibility of newer virtual server installations and provides the option of an
SDN overlay to provide traffic separation for different security requirements
whilst introducing management orchestration and automation to both the
server layer and network layer.

Solution Overview
Juniper proposes a two-tier architecture utilising the new EX4300 and
QFX5100 to provide both copper and Fibre connectivity for 1GbE and 10GbE
server connections at the access/aggregation layer. Utilising a spine and leaf
approach the spine switches would connect to a core/WAN layer of EX9200.
Each tier within the solution is then virtualised using Juniper’s unique Virtual
Chassis (VC) technology to allow the solution to be deployed in manageable
VC clusters, providing additional scale when required, retaining ease of
management and minimizing space and power requirements.

At the server access layer the QFX5100-48S provides 48 ports of 1/10GbE

SFP connectivity with 6 x 40GbE SFP ports for uplinks. The QFX5100-48S
also comes with dual out of band management ports (both SFP and RJ45),
dual 650watt power supplies and five fan trays. All of which are hot
swappable.

To complement the QFX and provide connectivity for existing servers the
EX4300 provides 48 ports of 10/100/1000Mbps RJ45 copper connectivity

Appendix C-20 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

with 4 x 1/10GbE front facing uplink ports and a further 4 x 40GbE port on the
rear. Again like the QFX5100-48S, the EX4300 has dual power supplies and
fan trays, which are all hot swappable.

It’s at this point that we can introduce Virtual Chassis in to the solution.
Juniper Networks unique Virtual Chassis technology, enables up to 20
interconnected switches to be managed and operated as a single, logical
device with a single IP address and single MAC address. Virtual Chassis
technology enables enterprises to separate physical topology from logical
groupings of endpoints and, as a result, provides efficient resource utilization.
The advantages of connecting multiple switches into a Virtual Chassis Fabric
include:
• better-managed bandwidth at a network layer,
• simplified configuration and maintenance because multiple devices
can be managed as a single device,
• increased fault tolerance and high availability (HA) because a Virtual
Chassis can remain active and network traffic can be redirected to
other member switches when a single member switch fails,
• and a flatter, simplified Layer 2 network topology that minimizes or
eliminates the need for loop prevention protocols such as Spanning
Tree Protocol (STP).
It also allows multiple links to be aggregated together into single links. Thus
the two 10GbE links from each top of rack switch would aggregated into a
single link providing 20GbE of uplink connectivity to the concentrators.
With the introduction of the QFX5100 series of switches the existing Juniper
Virtual Chassis technology is further scaled and enhanced to support a spine-
and-leaf topology that is ideal for high-performance, low-latency data centre
deployments.
In its first instance, this topology, called Virtual Chassis Fabric (VCF), enables
up to 20 QFX5100, EX4300 and QFX3500 switches to be deployed in a
spine-and-leaf configuration, with two to four QFX5100s in the spine and up
to 18 QFX5100, EX4300 and QFX3500 switches as leaf nodes. This
architecture provides any-rack-to-any-rack deterministic throughput and less
than 2 microseconds of latency, while significantly simplifying network
operations through a single point of management.
Some of the key VCF features include:
• Any to Any uniform performance
• Single Managed Fabric
• Scales to 768 1/10G ports
• Integrated Routing Engines
• Loss-less In-band Control Network
• Network ports on Hub and Spoke Switches
• Plug N Play Deployment
• Single Tier Architecture
• Supports variety of interface speeds
• Predictable over-subscription and Performance

www.juniper.net Sample Request for Proposal • Appendix C-21

Juniper Networks Design Fundamentals

• Integrated Director and in-band communication for Control

Plane
• WAN and Security devices can plug into the spine or any
member
• Full Layer2 and Layer3 support in every member of the Fabric
• Enhanced In Service Software Upgrade
As the diagram shows below and as mentioned in the previous section, the
Virtual Chassis Fabric (VCF) topology would start with two QFX5100-48S
switches with a dual 10/40GbE link connecting them together and forming the
Spine of the VCF formation.

One of the switches is configured as the master Route Engine (RE) and the
other is configured as the hot-standby backup RE. This formation provides
the single IP gateway and MAC address for the whole of the VCF whilst
providing a converged control plane across the two spine switches. This
converged control plane removes any convergence issues if a single spine
switches were to fail. In line with every Juniper product, we maintain the
control plane and data plane separation, allowing traffic to flow even if the
whole control plane were to fail.

It’s at this point that additional nodes or leafs can be added to the VCF. This
is implemented on the master RE, by configuring the serial number and
assigning a member number to each node. Once this is completed, each leaf
node is dual connected via either 1/10 or 40GbE fibre or DAC cables to the
two spine switches. The spine use LLDP to communicate with the new leaf
nodes and confirms that the serial number on the leaf nodes match the serial
numbers in the master configuration. Once confirmed, the leaf switches join
the VCF and are now fully operational from the master RE.

Another consequence of joining the VCF is that the uplinks from leaf nodes to
the spine switches are automatically aggregated and renamed virtual chassis
ports or VCP’s. These VCP’s are removed from the configuration so they
cannot be renamed or re-configured.

As more leaf nodes are added to the VCF and registered with the master RE
the control plane and forwarding planes on each device start to become
aware of the other switches in the VCF. The master RE creates the state
information and federates the state to other switches enabling distributed
forwarding. As mentioned, all the fabric links are active-active; there is no

Appendix C-22 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Spanning Tree inside the fabric. Traffic is load balanced on all links to
achieve an internal 1.8 microsecond latency. And it is worth noting that inside
the VCF the default is to do local switching, so only traffic that is destined for
either the spine or further will traverse the spine all other traffic inside the
VCF will be switched locally. As such, you can achieve 550 nanoseconds
inside a VCF, and you can also do 16 way server multi-homing going from
your server into the VCF fabric.

Using the same process as outlined earlier, you can add up to 18 leaf nodes
to a single VCF. As our roadmap information states, this will be changed via
software to 32 leaf nodes in mid-2015. Once you hit this limit, you can then
create a second VCF in the same way. This is where our solution scales to
support the large number of ports in the existing data centres.

As the diagram above shows, the first VCF is replicated as many times as
required to support the number of ports within each Tech Hall.

To provide connectivity between the VCF’s we can implement two things. The
first is to introduce a Core layer which will aggregate the connections from

www.juniper.net Sample Request for Proposal • Appendix C-23

Juniper Networks Design Fundamentals

each VCF, whilst providing ongoing connectivity to the other Data Centres
and the wider network environment. We can also connect the VCF’s together
as well. This then allows another route for traffic to flow in an east-west basis
as opposed to the traditional north south route.

The Core layer would comprise of EX9200 chassis’. These provide dual route
engines, multiple power supplies and fan trays. Our initial solution would be
to place a 6RU (Rack Unit) EX9204 within each Tech Hall and then connect
these to EX9200’s together to form a Virtual Chassis. In implementing the
EX9200’s at this layer we introduce the following benefits:

• Distributed forwarding plane whilst enabling a single point of

management for the core layer
• In the same way that the QFX5100’s support multiple interface types
to allow for future growth, the EX9200 series provide support for
multi-10GbE, 40GbE and 100GbE. This allows 10GbE to be utilized
on day one, but with the option of 40GbE and 100GbE when traffic
patterns and bandwidth utilization dictate higher link speeds
• Advanced Layer 2 (up to 32k Bridge Domain, 128k VLAN ID
supported, 8k Virtual Switch, VPLS with the option of EVPN (Juniper
SOPD Roadmap and currently planned for release in 1H2015),
Layer3 features (MPLS, BGP etc.) and high scalability (>4k VLANS)
• With Virtual Chassis technology at both layers of the network, links
between the two layers will be automatically aggregated maximizing
bandwidth within the data Centre
• EX9200’s as the core layer support open standard EVPN, MPLS,
VXLAN and VPLS. This would allow the layer 2 environment to be
stretched between data centres as more virtual server applications
come on line and provide a more flexible approach for active/active
applications
• Both layers within the network would support the same version of
software meaning no difference in command structure or
implementation
• The EX9200’s in conjunction with the QFX5100’s and EX4200’s
provide support for the Juniper SDN contrail solution allowing a SDN
overlay of L2 and L3 tunnels to be implemented using standard
based MPLS.

With the introduction of the EX9200’s we come full circle to our entire
solution per a data Centre (as shown in the diagram below) and Juniper
would look to replicate this across all of the data centres in the same way as
noted above.

Appendix C-24 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

The next section of this response covers some of the innovation of our
solution and hardware involved.

Hitless Upgrade With Single Switch ISSU

In the traditional Data Centre environment, typically there are multiple racks,
multiple top of racks in each rack, and so the customer is leveraging the
hardware redundancy to do its upgrade. So you always have one of the
TORs active, however when you’re doing that you basically have one node
available to you at the time when you’re doing the upgrade. Applications will
basically run at half bandwidth and you end up having to group these multiple
racks and create longer maintenance windows. Whereas using VCF you can
actually do hitless software upgrade using a single switch and you can
upgrade multiple racks at a time and applications can run at full bandwidth
because you’re not taking down any of your data links while you’re still
upgrading your active RE. Because you continue to… you can do multiples of
these racks at a time with shorter maintenance windows, and it does not
require hardware redundancy. You don’t have to maintain dual TORs in each
rack just for the purpose of upgrading.

This innovation allows a more distributed placement of switches within each

tech hall. The diagram below provides an overview of the QFX5100 internal
architecture and it is worth noting that both the EX9200 supports ISSU as
standard and the EX4300 will support it in the coming months.

www.juniper.net Sample Request for Proposal • Appendix C-25

Juniper Networks Design Fundamentals

Juniper Networks QFabric Series Switches

Juniper Networks’ QFabric System is the only fabric solution that delivers
any-to-any connectivity and simplified operations, making it the ideal
architectural foundation for virtualized data centres today and for the next
decade. It is a scalable, high-performance, non-blocking, and easy-to-
manage fabric that enables traditional L2 and L3 connectivity along with
virtualization and convergence. The standards-based QFabric System is
completely interoperable and seamlessly integrates with customers’ existing
data centre environments, allowing them to easily migrate traditional tiered
networks to a single tier QFabric architecture that connects compute, storage,
network, and services resources as extensions of a low latency network.
The QFX Series is also a standards-based Fibre Channel over Ethernet
(FCoE) transit switch and FCoE-to-Fibre Channel (FCoE-FC) gateway that
protects customer investments in existing data centre aggregation and Fibre
Channel storage area network (SAN) infrastructures.

Juniper Networks QFX5100

The QFX5100 line of flexible, high-performance, low-latency and feature-rich

L2 and L3 switches are optimized for virtualized data centre environments.
QFX5100 switches are a universal building block for multiple fabric
architectures including Juniper Networks’ mixed 1/10/40GbE Virtual Chassis,
Virtual Chassis Fabric and QFabric architectures, and open architectures
such as Spine and Leaf and L3 All QFX5100 switches support ISSU to
deliver hitless data centre operations

Appendix C-26 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

QFX5100 switches also include support for virtualized network environments

including Juniper Contrail and VMware NSX L2 gateway services.
For added flexibility, the 40GbE ports on the QFX5100 switches can be used
as 4x10GbE ports using QSFP+ to SFP+ direct attach copper (DAC) or
QSFP+ to SFP+ Fibre splitter cables and optics.
Juniper Networks QFX Series Switches features include:
• Up to 2.56Tbps
throughput and 1.44
Tbps switching
capacity: Sustain
wire-speed switching
with low latency and
jitter for all ports at
wire speed with full
L2 and L3
performance.
• Redundant power
supplies and fans, control and data plane separation: QFX Series
switches are designed with robust high-availability features, including
redundant AC and DC power supplies and fan modules to ensure
hardware availability. Control plane and data plane separation, combined
with the high-availability Junos OS design, ensures maximum systems-
level availability.
• Server and network virtualization support: QFX Series switches
support large media access control (MAC) address tables that enable
large-scale server virtualization deployment. Select QFX Series switches
include integrated support for Juniper Contrail and VMware NSX L2
Gateway Services functionality to programmatically enable connectivity
between VMware virtual networks and physical network environments.
The switches are also supported by Junos Space Network Director,
which unifies physical and virtual infrastructures to provide network
operators with a comprehensive view of the complete end-to-end
network.
• Energy efficient, environmentally friendly solutions: QFX Series
switches are environmentally conscious “green” solutions that lower
operational expenses. The switches’ variable-speed fans dynamically
adjust their speed based on ambient temperature to optimize and reduce
power consumption to just over 2 Watts per 10GbE port.
For more information, please see: http://www.juniper.net/us/en/products-
services/switching/qfx-series/#overview

Juniper Networks EX4300

www.juniper.net Sample Request for Proposal • Appendix C-27

Juniper Networks Design Fundamentals

EX4300 Ethernet switches are compact, fixed-configuration platforms that

satisfy a variety of high-performance branch, campus and data centre access
deployments.
Juniper Networks Virtual Chassis technology enables up to 10 EX4300
switches to be interconnected over a 320 Gbps backplane using four back-
panel 40GE ports or in to a Virtual Chassis Fabric with the QFX5100 series,
creating a single, logical device that delivers a highly scalable, cost-effective
solution for growing campus environments.
Juniper Networks EX4300 features include:
• Hot-swappable fans
• Consistent modular Juniper Networks Junos OS control plane feature
implementation
• Dual RE’s with graceful Routing Engine switchover (GRES)
• Single management interface
• Easy, centralized software upgrades
• Scalability from 24 to 48 10/100/1000BASE-T ports, with up to 40 10GE
uplinks and 40 40GE uplinks
For more information, please see: http://www.juniper.net/us/en/products-
services/switching/ex-series/ex4300/

Juniper Networks EX9200

Juniper Networks EX9200 Series next-generation carrier-class campus and

data centre core Ethernet switching platforms (shown below) are designed for
performance and scale, delivering greater port densities, space efficiency,
and an on-ramp to 40GE and 100GE for enterprise customers.
The EX9200 line of programmable, flexible, and scalable modular Ethernet
core switches simplifies the deployment of cloud applications, virtualized
servers and rich media collaboration tools across campus and data centre
environments. As a key element of Juniper Networks “Simply Connected”
portfolio of resilient switching, security, routing, and wireless products, the
EX9200 Series enables collaboration and provides simple and secure access
to mission critical applications. In the data centre, the EX9200 simplifies
network architectures and network operations to better align the network with
today’s dynamic business environments.

Appendix C-28 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Juniper Networks EX9200 Series Ethernet Switches.

As networks become a more strategic part of an enterprise’s business, they

need to be more agile. Network agility requires programmability, and the
EX9200 provides that and more in its silicon and at the system and
networking levels. The EX9200 is based on Juniper One custom silicon, an
ASIC designed by Juniper Networks which provides a programmable Packet
Forwarding Engine (PFE) and allows for native support of networking
protocols such as virtualization using MPLS over IP and overlay network
protocols. ASIC micro code changes delivered through updates to Juniper
Networks Junos OS provide investment protection by allowing existing
hardware to support new or future networking protocols.
All EX9200 system programmability provides support for Junos OS-based
automation along with the Junos SDK, which enables integration with Puppet,
Open Flow, and other automation applications. The EX9200 network
programmability also enables integration with leading orchestration
applications.
Trends such as mobility and increasing rich-media traffic in the campus,
combined with virtualization and cloud computing in the data centre, mandate
a core switch that can deliver:
• Increased bandwidth and throughput via 40GE and 100GE
interfaces;
• Increased logical scale needed to support more devices and servers;
• Increased 10GE port densities;
• Form factor alternatives;
• Programmability to address future business needs;
• Carrier grade availability
Juniper Networks EX9200 Series is ready to handle changing networking
demands for at least the next decade.

www.juniper.net Sample Request for Proposal • Appendix C-29

Juniper Networks Design Fundamentals

Simplifying and Transforming IT Infrastructures

The table below lists EX9200 Series features that enable customers to
simplify and transform their IT infrastructure.
EX9200 Series: Features for Simplifying and Transforming IT
Infrastructures
Feature Benefit
Programmable ASIC Provides the platform for future innovation (e.g.,
VXLAN, NVGRE, etc.) and offers investment
protection to customers by delivering features
that were traditionally delivered by replacing the
hardware
Junos automation Automates operational and configuration
tasks―simplifying configurations and reducing
potential errors
Junos SDK Exposes programmable interfaces for Software
Defined Networking (e.g., OpenFlow, Puppet,
etc.)
Logical and physical Allows for “flatter” network architectures (i.e.,
scale fewer devices which are easier to deploy and
manage)
Junos Node Unifier Allows connected switches to be managed
from/by the EX9200 Series
Carrier-grade Prevents network downtime
platform

Models
Three EX9200 chassis options are available, providing full deployment
flexibility:
• EX9204 – 4-slot, 6 RU chassis that supports up to three line cards
• EX9208 – 8-slot, 8 RU chassis that supports up to six line cards
• EX9214 – 14-slot, 16 RU chassis that supports up to 12 line cards

Fully configured, a single EX9214 chassis can support up to 320 10GE ports
(240 at wire speed for all packet sizes), delivering one of the industry’s
highest line-rate 10GE port densities for this class of feature rich and
programmable switch.
The EX9200 switch fabric is capable of delivering 240 Gbps (full duplex) per
slot, enabling scalable wire-rate performance on all ports for any packet size.
The pass-through biplane design also supports a future capacity of up to 13.2
Tbsp.

Juniper Networks proposal is based on two EX9204 chassis switches,

providing 40GE or 10GE connectivity to the Aggregation layer. 1/10GE
connectivity is also proposed for WAN and inter-DC connectivity. An
EX9204 will be deployed in each tech hall, but virtualized together via
Virtual chassis to provide a single Core layer/WAN gateway.

Appendix C-30 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

R008 Please provide your solution proposal to provide multi-tenancy (same Mandatory
[6.3.2] customer different domains; e.g. Live, Dev, Clone) separation within a data
centre switch infrastructure and details of any assurance for any separation
technologies used.
Juniper The Juniper solution can provide multi-tenancy in a series of ways from
EVPN at the edge of the network to VPLS, VXLAN, MPLS and our SDN
approach to VPN overlay through Juniper contrail to the internal data centre.

Our response first looks at separation at layer 2 and through the use of
Juniper contrail.

Layer 2 Separation within the Data Centre

VPLS
Juniper Networks offers virtual private LAN service (VPLS) over MPLS, a
standards-based technology that meets the challenges and requirements
associated with data centre interconnectivity. A single physical network can
be partitioned into several logical VPLS instances that are separate and
secure logical L2 networks. This means that all logical instances can be
overlaid on the same physical network, and the same physical network can
appear as different logical VPLS networks. Each VPLS instance appears as a
bridge domain that extends the L2 segments between the different data
centres and offers point-to-multipoint connectivity.

The VPLS instances are mapped to the VLANs, which contain virtualized
resources. VLAN continuity can be maintained across the Wan without
disruption. MPLS is a multiservice transport technology designed to carry
different traffic such as IP packets, a TM cells, Frame Relay or Ethernet
frames, and so on. It inherently allows separation of traffic coming from
various logical network instances by labelling and sending them across
specific, optimized network paths. It has built-in protection and resiliency
mechanisms that allow fast recovery from failures or preventive maintenance.
Using MPLS, different types or forms of traffic can be transported quickly,
securely, and reliably over the same physical infrastructure.
VPLS leverages MPLS as the transport mechanism in the Wan to carry traffic
between what would have previously been a discontinuous L2 network or
VLAN segments at different data centres or sites. High availability is
maintained using MPLS resiliency mechanisms such as MPLS fast reroute
and on-demand paths in the network. Prioritization between applications is
made possible by using quality of service (QoS), and network bandwidth is
managed using traffic engineering (TE), thereby guaranteeing application
performance. Being a standards-based technology, VPLS over MPLS is well
suited to support data centre infrastructure convergence. This is an excellent
choice for a multivendor network, which needs to connect data centres
without having to massively replace equipment. While VPLS allows network
partitioning and extension of L2 segments, MPLS provides a transport
mechanism to carry various types of traffic between data centres.
Both the QFX5100’s, EX4300 and EX9200’s support VPLS
The web link below provides an extensive implementation of VPLS within a
Data Centre environment.

Whitepaper on Implementing VPLS for Data Centre interconnectivity

http://www.juniper.net/us/en/local/pdf/implementation-guides/8010050-en.pdf

EVPN

www.juniper.net Sample Request for Proposal • Appendix C-31

Juniper Networks Design Fundamentals

To provide Layer 2 stretch services between the data centres, then EVPN
(Ethernet Virtual Private Networks) becomes a logical choice. Ethernet VPN
(EVPN) enables you to connect a group of dispersed customer sites which in
this case would be SDC01, SDC02 and SHP01 using a Layer 2 virtual bridge.
As with other types of VPNs, an EVPN is comprised of customer edge (CE)
devices (QFX5100’s) connected to provider edge (PE) devices. The PE
devices can include an MPLS edge switch (MES) such as the EX9200’s
proposed at the core layer that acts at the edge of the MPLS
infrastructure. To provide multi-tenancy aspect you can deploy multiple
EVPNs within the network, with each EVPN assigned to a series of virtual
routers within virtual servers which in turn connect to customers while
ensuring that the traffic sharing that network remains private.
The MPLS infrastructure allows you to take advantage of the MPLS
functionality including fast reroute, node and link protection, and standby
secondary paths whilst allowing for inter-op between different vendors, as
MPLS/EVPN is an open standard.
For EVPNs, learning between MES’s takes place in the control plane rather
than in the data plane (as is the case with traditional network bridging). The
control plane provides greater control over the learning process, allowing you
to restrict which devices discover information about the network. You can
also apply policies on the MESs, allowing you to carefully control how
network information is distributed and processed. EVPNs utilize the BGP
control plane infrastructure, providing greater scale and the ability to isolate
groups of devices (hosts, servers, virtual machines, and so on) from each
other.
The MESs attach an MPLS label to each MAC address learned from the CE
devices. This label and MAC address combination is advertised to the other
MESs in the control plane. Control plane learning enables load balancing and
improves convergence times in the event of certain types of network failures.
The learning process between the MESs and the CE devices is completed
using the method best suited to each CE device (data plane learning, IEEE
802.1, LLDP, 802.1aq, and so on).
The policy attributes of an EVPN are similar to an IP VPN (for example, Layer
3 VPNs). Each EVPN routing instance requires that you configure a route
distinguisher and one or more route targets. In this case the route reflector
could be a virtual router sitting within the EX9200’s that are or would be
facing out in to the WAN. A CE device attaches to an EVPN routing instance
on an MES through an Ethernet interface that might be configured for one or
more VLANs or this could be a VPLS domain as you can take the VPLS
elements to implement inside the Data Centre and the EVPN to provide Layer
2 between data centres.
The following features are available for EVPNs:
• Ethernet connectivity between data centres spanning metropolitan
area networks (MANs) and WANs
• One VLAN for each MAC VPN
• Automatic route distinguishers
• Active Standby multihoming

Contrail
Another option, which leverages the open standards of MPLS and the newer
functionality of Juniper SDN approach, is through the use of Contrail.

Appendix C-32 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

From a Data Centre perspective, Juniper has developed Contrail, which is an

open source SDN solution that automates and orchestrates a virtual network
overlay. All of the networking features such as switching, routing, security,
and load balancing are moved from the physical hardware infrastructure to
software running in the hypervisor kernel that is managed from a central
orchestration system.

Contrail

The Contrail system consists of two main components: Contrail SDN

Controller and Contrail vRouter.

Contrail SDN Controller is a logically centralized but physically distributed

SDN controller that is responsible for providing the management, control, and
analytics functions of the virtualized network.

The Contrail vRouter is a forwarding plane (of a distributed router) that runs in
the hypervisor of a virtualized server. It extends the network from the physical
routers and switches in a data centre into a virtual overlay network hosted in
the virtualized servers. Contrail vRouter is conceptually similar to existing
commercial and open-source vSwitches such as the Open vSwitch (OVS),
but it also provides routing and higher-layer services (for example, vRouter
instead of vSwitch).

The Contrail SDN Controller provides the logically centralized control plane
and management plane of the system and orchestrates the vRouters.

Virtual Networks

Virtual Networks (VNs) are a key concept in the Contrail system. VNs are
logical constructs implemented on top of the physical network. They are used
to replace VLAN-based isolation and provide multi-tenancy in a virtualized
data centre. Each tenant or an application can have one or more virtual
networks. Each virtual network is isolated from all the other virtual networks
unless explicitly allowed by security policy.

Overlay Networking

VNs can also be implemented using two networks—a physical underlay

network and a virtual overlay network. This overlay networking technique has
been widely deployed in the wireless LAN (WLAN) industry for more than a
decade, but its application to data centre networks is relatively new. It is
being standardized in various forums such as the Internet Engineering Task
Force (IETF) through the Network Virtualization Overlays (NVO3) working
group and has been implemented in open-source and commercial network
virtualization products from a variety of vendors.

The role of the physical underlay network is to provide an “IP fabric”—its

responsibility is to provide unicast IP connectivity from any physical device
(server, storage device, router, or switch) to any other physical device. An
ideal underlay network provides uniform low-latency, non-blocking, high-
bandwidth connectivity from any point in the network to any other point in the
network.

The vRouters running in the hypervisors of the virtualized servers create a

www.juniper.net Sample Request for Proposal • Appendix C-33

Juniper Networks Design Fundamentals

virtual overlay network on top of the physical underlay network using a mesh
of dynamic “tunnels” among themselves. In the case of Contrail these overlay
tunnels can be MPLS over GRE/UDP tunnels or VXLAN tunnels.

The underlay physical routers and switches do not contain any per-tenant
state. They do not contain any Media Access Control (MAC) addresses, IP
address, or policies for virtual machines. The forwarding tables of the
underlay physical routers and switches only contain the IP prefixes or MAC
addresses of the physical servers. Gateway routers or switches that connect
a virtual network to a physical network are an exception—they do need to
contain tenant MAC or IP addresses.

The vRouters, on the other hand, do contain per-tenant state. They contain a
separate forwarding table (a routing instance) per virtual network. That
forwarding table contains the IP prefixes (in the case of L3 overlays) or the
MAC addresses (in the case of Layer 2 overlays) of the virtual machines. No
single vRouter needs to contain all IP prefixes or all MAC addresses for all
virtual machines in the entire data centre. A given vRouter only needs to
contain those routing instances that are locally present on the server (that is,
which have at least one virtual machine present on the server.)

Overlay Based on MPLS

The Contrail system is inspired by and conceptually very similar to standard

MPLS L3VPNs (for L3 overlays) and MPLS EVPNs (for L2 overlays).

In the data plane, Contrail supports MPLS over GRE, a data plane
encapsulation that is widely supported by existing routers from all major
vendors. Contrail also supports other data plane encapsulation standards
such as MPLS over UDP (better multi-pathing and CPU utilization) and
VXLAN. Additional encapsulation standards such as NVGRE can be easily
added in future releases.

The control plane protocol between the control plane nodes of the Contrail
system or a physical gateway router (or switch) is BGP (and NETCONF for
management). This is the exact same control plane protocol that is used for
MPLS L3VPNs and MPLS EVPNs.

The protocol between the Contrail SDN Controller and the Contrail vRouters
is based on XMPP [ietf-xmpp-wg]. The schema of the messages exchanged
over XMPP is described in an IETF draft [draft-ietf-l3vpn-end-system] and this
protocol, while syntactically different, is semantically very similar to BGP.

The fact that the Contrail system uses control plane and data plane protocols
that are very similar to the protocols used for MPLS L3VPNs and EVPNs has
multiple advantages. These technologies are mature and known to scale, and
they are widely deployed in production networks and supported in
multivendor physical gear that allows for seamless interoperability without the
need for software gateways.

Appendix C-34 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Contrail Architecture Details 


As the diagram above shows, the Contrail system consists of two parts—a
logically centralized but physically distributed Contrail SDN Controller and a
set of Contrail vRouters that serve as software forwarding elements
implemented in the hypervisors of general-purpose virtualized servers. 

Contrail SDN Controller provides northbound REST APIs used by
applications. These APIs are used for integration with the cloud orchestration
system—for example, for integration with OpenStack via a Neutron (formerly
known as Quantum) plugin. The REST APIs can also be used by other
applications and operator’s OSS/BSS. Finally, the REST APIs are used to
implement the web-based GUI included in the Contrail system. 
The Contrail
system provides three interfaces: a set of northbound REST APIs that are
used to talk to the orchestration system and the applications, southbound
interfaces that are used to communicate to virtual network elements (Contrail
vRouters) or physical network elements (gateway routers and switches), and
an east-west interface used
to peer with other controllers. OpenStack and
CloudStack are the supported orchestrators, standard BGP is the east- west
interface, XMPP is the southbound interface for Contrail vRouters, and BGP
and NETCONF are the southbound interfaces for gateway routers and
switches.

Internally, the Contrail SDN Controller consists of three main components:

• Configuration nodes are responsible for translating the high-

level data model into a lower-level form suitable for
interacting with network elements.
• Control nodes are responsible for propagating this low-level
state to and from network elements and peer systems in an
eventually consistent way.

www.juniper.net Sample Request for Proposal • Appendix C-35

Juniper Networks Design Fundamentals

• Analytics nodes are responsible for capturing real-time data

from network elements, abstracting it, and presenting it in a
form suitable for applications to consume.

XYZ, INC. Data Centre Operations Implementation

So, from XYZ, INC. Data Centre Operations’ point of view Contrail would be
implemented in the following way.

The QFX5100 Virtual Chassis Fabric architecture proposed by Juniper would

provide the network fabric for which the overlay would sit on top. The VR’s
would sit within the virtual servers to provide the point at which traffic enters
the overlay network. The controller or gateway router would sit on the
EX9200 core layer to provide the full overlay enter point for traffic entering
and exiting the data Centre network.

R009 Please provide your solution proposal for DMZ provision within the proposed Mandatory
[6.3.3] architecture. The DMZs may be in a shared or separate architecture. The
DMZs may contain Firewalls, Load Balancers and other network related
devices. The refresh of Firewalls is not within scope of this RFP.
Juniper Juniper would look to implement the same VCF architecture within the DMZ
environment as proposed for the wider data Centre solution, but scaled to
support the size and layout of the DMZ. This would mean the switches can be
the same, installed and configured in the same way in either spine or leaf or
in a daisy-chain architecture. The principles of a single point of management,
distributed forwarding table and flexible scaling would stay the same.

Juniper does not provide load-balancing or physical appliances for IDS/IPS.

Our implementation both of these are now done in virtual software or through
the use of Next-gen services through the SRX platform.

Juniper would look to be provided with more details on the DMZ environment
and would then architect our DMZ approach to suit.
R010 The Nexus switch infrastructure is not being replaced; however please Mandatory
[6.3.4] provide details of how your switch solution can be merged with the current
infrastructure to provide additional capacity with no loss of current
capabilities.
Juniper Data Centre Interconnect using VPLS
Virtual Private LAN Service (VPLS), which provides both intra- and inter-
metro Ethernet connectivity over a common IP/MPLS network is our preferred
method of connecting between different Datacentres. VPLS is a standard
implementation that guarantees interoperability between this is preferable
over propriety implementations such as OTV promoted by a single vendor
and introducing no significant benefits to justify a new technology. VPLS also
ensures a low risk deployment options to XYZ, Inc. Data Centres with
different vendor infrastructures
VPLS/MPLS is an extension to VLANs. Some of these similarities between
VLANS and MPLS are:
• VLANS have dot1q tags similar to the tags in MPLS LSP. The
VLANS use priorities in the packet header (i.e. 802.1p) similar to the
priority fields in MPLS (DSCP/EXP QOS).
• VLANS enable Layer2 segmentation whereas MPLS enables Layer2
and Layer3 segmentation.

Appendix C-36 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

• VLANs provide localized segmentation that is limited in scale

whereas MPLS enables network wide segmentation with very large
scale.
• VLANs use STP to discover and establish neighbor paths whereas
MPLS uses OSPF/BGP and LDP to do the same.
• To optimize the multicast, broadcast and flooding VPLS uses P2MP
that allows data plane based replication to designated recipients.
This enables optimal bandwidth utilization and better scalability.
• VPLS uses L3 routing protocols to automatically discover neighbors
and signal connections.
• Juniper Networks’ routers support both implementations: RFC 4761
which uses BGP signaling and RFC 4762 which uses LDP signaling.

Future enhancements
To meet future demands of XYZ, Inc. regarding optimized DCI, localization
and controlled traffic flow, EVPN will be introduced with the ability for an
MPLS edge switch (MES) that acts at the edge to advertise locally learned
MAC addresses in BGP to other MESes, using principles borrowed from IP
VPNs EVPN requires an MES to learn the MAC addresses of CEs connected
to other MESes in the control plane using BGP

Enhancements delivered by EVPN:

• Active multi-homed
• Extended control plane (MAC address) scaling
• Faster convergence from edge failures using local repair
• Flooding AND Control Plane learning
• Increased granularity on MAC address reach-ability distribution – increased
support for host mobility – policy based decisions

Juniper Contrail also uses EVPN to interconnect multiple edges (virtual

machines) within a data centre. Traditionally, the data centre is built as a flat
Layer 2 network with issues such as flooding, limitations in redundancy and
provisioning, and high volumes of MAC addresses learned, which cause
churn at node failures. EVPN is designed to address these issues without
disturbing flat MAC connectivity.

Data Centre Interconnect conclusion

EVPN will replace or be running in parallel with already deployed VPLS DCI
connections. As EVPN matures and A/A EVPN DCI is supported in the
environment, old VPLS links can gradually be tiered down.

XYZ, Inc. Data Centres that have not adopted EVPN will use VPLS as DCI
protocol. This ensures connectivity with new and existing data centres
independent of vendor infrastructure.
R010-1 To be able to be integrated with the existing Cisco topology both physically Mandatory
[6.3.5] and logically in such a way as to allow a phased migration from old to new
infrastructure, without compromising the stability of the network.
Consideration must be given to how the layer 2 VLAN topology, the layer 3
routing instances and the load-balancing functions will be dealt with during
and after the migration.

www.juniper.net Sample Request for Proposal • Appendix C-37

Juniper Networks Design Fundamentals

Juniper
Transition Plan
This section details the recommended migration steps to migrate from XYZ,
Inc.’s existing DC to the new DC network.
We will study the following transitions:
• Legacy to Point-of-Proof
• Nexus-based to Point-of-Proof
• Multi-interconnections concerns

Please note: The Transition Plan proposed in this section has been built with
Juniper’s knowledge of XYZ, Inc. DC networks at the time of writing. The
Transition Plan should be re-evaluated when Juniper is able to assess the
XYZ, Inc. DC environment in more detail and then be validated in the lab,
with impact analysis.

Please note(2): This Transition Plan covers technology aspects only. A more
detailed Transition Plan will be built before the migration, as described in the
‘Transition Methodology’ Chapter. This detailed Plan will be built after a
complete assessment of the XYZ, Inc. environment, and will include, for
example:
• Identification of the transition steps (as provided
in this document)
• Pre-requisites for each steps
• Detailed methodology of each of those steps
• Integration to XYZ, Inc. Tools and Procedures
• Recommended migration validation steps
• Rollback Procedures
• Risk management migration dependencies,
including applications, servers, services
• Roles and Responsibilities
• Network and site maintenance window schedules
• Timetable

Legacy to Point-of-Proof migration

Starting Point
Here we are using an example of the interconnection of the existing and
proposed networks during the server migration phase.
The example configuration is built with:
• 4 Catalyst 65xx acting as access + distribution
• L2 and L3 multitenancy
• Serving multiple racks (either in racks rows,
single racks or standalone)

Appendix C-38 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Build new solution (with first PoD)

Here, we’ll start building The Core of the solution, and 1 PoD:

EX 9K

Virtual
Chassis
Fabric
InterConnect Solutions
There are 2 options to interconnect the 2 solutions. One is STP free, and
using Multi-Chassis LAG Active/Standby technology; the second one needs
STP to run between the 2 solutions.
• MC-LAG (STP-free):
An MC-LAG in Active/Standby mode is created on the new solution core
(MX). Each link of the MC-LAG connects 1 MX to a different Catalyst. This
link will be used for L2 traffic.

www.juniper.net Sample Request for Proposal • Appendix C-39

Juniper Networks Design Fundamentals

This first approach is the preferred one, to keep both environments as much
independent as possible during the transition, and will be used as reference
for the remaining of the transition.
• RSTP:
Another option, which is less preferred, is to enable STP between existing
and the new solutions. We have the options to use VSTP on the MX
(equivalent of Cisco’s RPVST+), or use the compatibility of PVST+ to operate
with regular STP. If this solution should be selected, the EX9K should be the

Appendix C-40 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Root bridge and back-up root bridge of the STP, to get the following STP
topology:

X X X

• Interconnection capacity:
Technologies like Q-in-Q can be used to make those Gateways transparent
to any VLAN need, so they won’t need any type of specific configuration
except the Q-in-Q to carry all VLANs.

Migrate attached elements

Now that we have L2 connectivity between the 2 solutions, servers and
services can be migrated, with any of the options presented earlier (Replace,
Overlay, Hybrid, Out-of-PoD, or Virtualized):

www.juniper.net Sample Request for Proposal • Appendix C-41

Juniper Networks Design Fundamentals

L3 Migration
This is how L3 routing and Server Gateways will be handled during the
migration. The starting point is:
• HSRP used on the example PoD
• Routing (OSPF) for the VLANs of the PoDs is
also hosted on Archipelagos Cat6k
From this point, and as explained so far, servers and
services are migrated to the new solution:

Appendix C-42 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

HSRP
X

Routes Routes

L3 Core OSPF

Please Note: The green “Routes” arrows represent how routing is performed
to reach the server VLAN.

www.juniper.net Sample Request for Proposal • Appendix C-43

Juniper Networks Design Fundamentals

At this stage, all servers from both existing and new solution are using the
example HSRP as their Default Gateway:

HSRP
X

Routes Routes

OSPF

When we reach a critical volume of servers migrated on the new solution

(around 50%), it will be time to move the Default Gateway localization and the
routing to the new solution.
First, the OSPF domain will be extended to the new solution:

Appendix C-44 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

HSRP
X

Routes Routes

OSPF

Then we will move the routing from the existing solution to the new one (the
new solution routers will be the preferred path for traffic being sent to the PoD
VLAN, and the Default gateway will be moved also. Please note: When
VRRP transition to master state, it will send a gratuitous ARP. This will allow
all servers to update their ARP table with the new MAC address for their DG
(VRRP and HSRP are using different Mac address ranges). To get the
benefit of this feature, HSRP must be brought down before this transition
happens.

www.juniper.net Sample Request for Proposal • Appendix C-45

Juniper Networks Design Fundamentals

OSPF

Routes Routes
VRRP

This same workflow will be executed on a per VLAN basis.

Decommission old PoD

Once all the servers of a PoD are migrated to the new solution, the old PoD
can be de-commissioned.
Note: if following an overlay migration type, this de-commission will happen
after the pre-defined stability period, once a rollback plan is not needed
anymore

Appendix C-46 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

OSPF

Routes Routes
VRRP

VLAN Harmonisation
The VLAN harmonization can be handled by the EX9K

Feature and Service Support

For each hardware model specified in the section 13.2, please indicate the level of support as
applicable:
1. Fully supported – mandatory items should all conform to this level
2. Support projected – in these instances please indicate the date support will be available
3. Migration required – in these instances please indicate an alternative feature/service, and
the steps required to migrate or reconfigure existing devices
4. Not supported

www.juniper.net Sample Request for Proposal • Appendix C-47

Juniper Networks Design Fundamentals

_____________________________________________________________________
Juniper: Read and Understood

Table 13.3: Network device feature and service requirements

Ref Requirement Weighting
R011 1. Spanning Tree Protocol (Rapid-PVST and PVST+ used currently) - Mandatory
[6.4.1] Fully supported open standard STP including VSTP, MSTP & RSTP
2. First Hop Redundancy (currently Cisco HSRP) - Fully supported but
Juniper use VRRP or Virtual Chassis or both.
3. Static Routes – Fully supported
4. OSPF (for IPv4) – Fully supported
5. BGP (for IPv4) – Fully supported
5.a Redistribution between routing protocols – Fully supported
6. Access Control Lists (ACLs) e.g. for routing controls SNMP controls
etc. - Fully supported but Juniper call them Firewall filters
7. SNMP v1, v2c and v3 – Fully supported
8. VLAN tagging using 802.1q (including ability for tagged/un-tagged
frames, default/native VLAN etc.) – Fully supported
9. Port-based Network Access Control (802.1x) – Fully supported
10. Port Mirroring (currently Cisco SPAN) – Fully supported
11. Neighbor discovery (currently Cisco CDP) – Fully supported but
Juniper use LLDP (Link Layer Discovery Protocol)
12. Layer 2 Tunneling Protocol (L2TP) or other equivalent protocols –
Fully supported
13. Link Aggregation Control Protocol (LACP) – Fully supported
14. Transmission Control Protocol (TCP) – Fully supported
15. User Datagram Protocol (UDP) – Fully supported
16. Class-Based Weighted Fair Queuing (CBWFQ) or equivalent – Fully
supported
17. Low-Latency Queuing (LLQ) or equivalent – Fully supported
18. Quality of Service (QoS) – 802.1p CoS and DSCP classification,
marking and remarking, Expedited Forwarding (EF), cross-
stack/chassis QoS – Fully supported
19. IPSLA – Fully supported but Juniper use Real Time Performance
monitoring
20. Network Time Protocol (NTP) – Fully supported
21. Secure Shell (SSH) – Fully supported
22. Secure File Transfer Protocol (SFTP) – Fully supported
23. SSL – Fully supported
24. TRILL (Transparent Connection of Lots of Links) – Not Supported as
Juniper support VCF, Q-Fabric and other overlay technologies.
25. OTV (Overlay Transport Virtualization) - – Not Supported as this
proprietary to Cisco. Juniper support EVPN, VCF and Q-fabric
26. Multicast Routing Capability – Fully supported
27. Additional Spanning tree protection features such as
BPDU/Loopguard/Rootguard, loopguard portfast features – and
whether these are global or per interface – Fully Supported and
supported at both a global level and interface level.
28. Flow statistics e.g. Cisco Net flow, and their integration into the
management system – Fully supported and Juniper support J-Flow
and Netflow. Both of which will work with most analytics systems on
the market with the exception of Cisco.
29. UDLD uni-directional link detection type features – Not Supported as
this is Cisco proprietary. Juniper support the 802.3ah OAM link Fault
management feature

Appendix C-48 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

30. Logging capabilities – internal and external syslog – Fully supported

and can push logging to an external device or file server.
31. NTP master capabilities (if upstream NTP sync fails) – Fully
Supported
32. Interface descriptions and ability to easily view applied descriptions -
– Fully Supported
33. Integration with Bluecoat WAN optimisers (e.g. WCCP) – Fully
Supported via Filter based forwarding as WCCP is Cisco Proprietary
34. Interface options: 10M, 100M, 1G and 10G interface capabilities UTP
vs fibre speed, duplex settings – Fully Supported and configurable on
an interface by interface basis. The EX4300 supports
10/100/1000Mbps RJ45 connectivity and speed and duplex settings
are configured on the interfaces. The EX4300 also supports 1/10GbE
Fibre based SFP on the uplink interfaces and 40GbE QSFP on the
rear uplink interfaces. The QFX5100-48S supports 1/10Gb SFP
interfaces and speed can be configured for 1Gb or 10Gb with duplex
settings on the interfaces. The QFX5100-48S supports 40GbE QSFP
on the uplink interfaces, which can also be broken out using a
breakout cable to 4 x 10GbE SFP. Again speed and duplex settings
are on an interface basis. The EX9200 supports the same SFP and
interface options as both the EX4300 and QFX5100. Details on SFP
support for the platforms specified are noted below:
EX4300 SFP
http://www.juniper.net/techpubs/en_US/release-
independent/junos/topics/reference/specifications/optical-interface-
ex4300-support.html
QFX5100
http://www.juniper.net/techpubs/en_US/release-
independent/junos/topics/reference/specifications/interface-qfx5100-
support.html
EX9200
http://www.juniper.net/techpubs/en_US/release-
independent/junos/topics/reference/specifications/optical-interface-
ex9200-support.html
35. DHCP and other UDP port forwarding – Fully Supported

Juniper Answers in line in the list above.

R012 1. MPLS VRF Lite separation – Fully Supported Mandatory
[6.4.2] 2. VLAN ACL (Capture/Redirect) – Fully Supported
3. IPv6 (including IPv6-capable routing protocols (e.g. OSPFv6) – Fully
Supported
4. Non-disruptive Operating System Updates – Fully supported and
please refer to response within question R07 for a full overview.
4.a Low failover times between supervisors and between resilient
chassis – Fully supported, but relevant from a core layer point of
view as the access and aggregation layer comprises of 1RU switch
units formed in to a virtual chassis.
5. Traffic Shaping/Throttling (to reduce traffic flow to use only a portion
of Available link bandwidth) – Fully supported
6. Multi device/Multi chassis stacking - – Fully supported but classed as
Virtual Chassis in Juniper terms
7 Inter-switch / inter-stack cross-device link aggregation (like Cisco

www.juniper.net Sample Request for Proposal • Appendix C-49

Juniper Networks Design Fundamentals

VPC) – Fully supported but classed as virtual chassis and virtual

chassis fabric and MC-LAG
8. Inter-device connectivity options to replace dependency on spanning
tree . (e.g. Cisco Fabric Path) – Fully supported but Juniper would use
Virtual Chassis Fabric as this removes STP
9. Location independent IP addressing e.g. Cisco LISP – Not supported.
LISP is Cisco proprietary and still in an "Experimental" state according
to the latest RFC. Juniper would like to discuss options around why
this would be required.
10. Routing protocol authentication & graceful restarts – Fully supported
11. Configuration checkpoints / rollbacks – Fully supported
12. Banners for pre/post logons – for SSH and HTTPS – Fully supported
Juniper Answers in line in the list above.

Data Centre Operations’ Standards

Table 13.4: Device support requirements
Ref Requirement Weighting
R013 Enterprise Management: All devices are currently monitored 24x7 using HP Mandatory
[6.5.1] Network Node Manager, Solar Winds and the BMC software suite, and node
up/down alerts are used to create automated fault tickets. Please indicate
your device support for the SNMP protocol, and any configuration changes
which would be required to support your proposed products.
Juniper Open standard SNMP versions 1, 2 and 3 are fully supported by the QFX and
EX platforms proposed. The devices can respond to SNMP polling requests
or generate configurable SNMP traps. Multiple SNMP versions can run
concurrently to facilitate a migration to SNMP v3. No configuration change in
your existing management systems would be required to support SNMP from
Juniper equipment.
R014 Device Access Control: TACACS+ is currently used to provide login accounts Mandatory
[6.5.2] for Network Services staff, and enables Authentication, Authorization and
Accounting controls. Please indicate your support for TACACS+, and identify
any additional configuration or software requirements to provide the same
functionality when using your products. Indicate your support of a Syslog
capability.
Please also indicate your support for RADIUS.
Juniper TACACS+ and RADIUS are both fully supported for administrator
authentication on QFX and EX platforms, as well as for authentication to the
Junos Space management platform. Configurable syslog is also supported on
both QFX and EX platforms, including support for sending differentiated event
logs to different Syslog servers.

R015 Remote configuration is currently achieved in-band using SSH, and out-of- Mandatory
[6.5.3] band using asynchronous connectivity to the Cisco console port. Please
indicate how the same configuration methods can be achieved using your
products/solutions.
Juniper All EX and QFX configuration and troubleshooting can be performed using in-
band or out-of-band (recommended) SSH connectivity, although in practice
administrators would be more likely to use Junos Space to make
configuration changes. All insecure protocols can be disabled. All devices
feature a standard console port for serial console access. Juniper devices
also provide a dedicated out of band management Ethernet port, which has
direct connectivity to the route engine. This allows out of band management,
which bypasses the packet-forwarding engine and the in-band forwarding

Appendix C-50 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

traffic to allow complete isolated access to the switch. The EX4300 has a
10/100/1000Mbps RJ45 port and the QFX5100 has both a RJ45 port and a
SFP port.
R016 Configuration backup/restore: A backup copy of all network device Mandatory
[6.5.4] configurations are help on a CiscoWorks server so that they can be restored
in the event of device failure. Please indicate this function can be carried out
on your products, and any additional software tools which may be required.
Juniper Junos Space is able to maintain regular configuration backups of all EX and
QFX devices.
In addition to the local configuration history (by default Junos devices store
up to 50 previous configurations locally on the device), devices can be
configured to automatically upload configuration files to an FTP or SCP target
after every change or at specific (e.g. daily) intervals.
R017 Please indicate any additional mandatory or recommended device software High
[6.5.5] tools, which are required for configuration, management, monitoring or
diagnostic purposes.
Juniper All EX, QFX and Junos Space configuration and monitoring can be performed
using standard terminal emulation and web browser tools. No mandatory
device tools are required.

Junos Space is recommended for the centralised management of the

solution, however devices can still be monitored using standards-based
monitoring tools such as Solarwinds Orion NPM, HP node manager and other
management platforms.

Virtualization, Consolidation, Expansion and

Cost Innovation
Table 13.5: Virtualization requirements
Ref Requirement Weighting
R018 The vast majority of server connectivity across the XYZ, INC. Estate is using High
[6.6.1] multiple 1GE copper RJ45 connections, although Fast Ethernet is still used in
limited circumstances. As these physical servers are assessed for hardware
technology refresh, the default assumption is that the services residing on
them will be deployed onto a virtualized platform (unless justification is given
explaining why it must remain on dedicated hardware).
Please suggest how your network solution would enhance the connectivity,
configuration and management of the virtualized servers, as demand for
faster connectivity and management visibility will increase dramatically in the
future.
Juniper As noted earlier within the Juniper solution, we have proposed virtual chassis
fabric or VCF to enable multiple switches supporting 100Mb or 1GbE on
copper connections and 1/10GbE switches to co-exist with in the same single
switch fabric and management domain.

This co-existence would allow multiple servers from existing to virtual to

reside on the same switches with no change in the architecture or in the way
traffic traverses the fabric and the wider data centre.

From a management point of view several options exist for the configuration
and control of the proposed data centre design and implementing automation
in to the design.

www.juniper.net Sample Request for Proposal • Appendix C-51

Juniper Networks Design Fundamentals

CLI
The entire proposed devices run the same Operating system – JunOS. Junos
operating system is a reliable, high-performance network operating system
for routing, switching, and security. It reduces the time necessary to deploy
new services and decreases network operation costs. Junos offers secure
programming interfaces and the JunOS SDK for developing applications that
can unlock more value from the network.
Running Junos in a network improves the reliability, performance, and
security of existing applications. It automates network operations on a
streamlined system, allowing more time to focus on deploying new
applications and services. And it's scalable both up and down—providing a
consistent, reliable, stable system for developers and operators. Which in
turn means a more cost-effective solution for your business.
SDN
Path Computation Client (PCC): PCC is an SDN technology available on the
EX9200 Series. PCC enables network programmability to allow IT managers
to dynamically create optimal paths including slices, overlays or virtual paths,
to optimize on-demand bandwidth requirements.
Junos Space
Junos Space is a Network Application Platform, which is fully capable of
fulfilling the role of a Network Management System (NMS) for Juniper
Network Devices and providing integration into the existing Operational
Support Systems (OSS) through leveraging existing capability and further
configuration/customisation where there is specific need. As the Network
Application Platform it integrates readily with Junos devices, such as the
EX4300, EX9200 and QFX5100, through a Direct Management Interface
(DMI) and exposes a set of APIs for integration into North Bound OSS. Junos
Space provides an integrated suite of capability across the FCAPS functions
and provides a web based GUI for end-user client access.

Junos Space Context

Network Director (Junos Space Application)

Junos Space Network Director is one of the plug-and-play applications
running on the Junos Space Network Management Platform. While the Junos
Space Network Management Platform offers broad fault, configuration, and
device provisioning capabilities with a task-specific user interface, the
multiple Junos Space Management Applications extend the breadth of the
platform to optimize network management for various domains. These
applications enable you to automate the end-to-end provisioning of new
services across thousands of devices with a simple point-and-click GUI, as
well as optimize management for specific domains such as core, edge,
access and aggregation Junos Space Network Director provides a single
pane of glass view into both the wired and wireless networks, and creates a
holistic, full lifecycle management solution for the network.

Appendix C-52 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Junos Space Network Director today delivers:

• Critical elements of advanced management applications by providing
operational efficiency, expedited error free service roll-out, enhanced
visibility and fast troubleshooting.
• Operational efficiency by employing a correlated view of various
networks elements. It offers a holistic view of every aspect of network
operation to remove the need for disjointed applications throughout
the lifecycle of the network.
• Faster roll-out and activation of services while protecting against
configuration errors with profile-based configuration and configuration
pre-validation.
• Single pane of glass management that provides a unified view of the
network infrastructure including a correlated view of overlay services
and user experience on top of network infrastructure. Junos Space
Network Director also tracks aggregated utilization, network hotspots,
failures, correlated RF data and usage to a user level providing deep
visibility and easy troubleshooting of connectivity, equipment and
general failures.
Summary of the feature currently provided in Network director

More details on Network Director 1.5 features can be found in the following
link:
http://www.juniper.net/techpubs/en_US/network-director1.5/information-
products/pathway-pages/index.html

Unified management framework

• Single pane of management for campus and datacentre
networks
Virtualization management
• vCenter 5.x integration (LLDP based , VM mobility, P+V
topology)
• Auto Discovery, topology, vMotion moves and view
FCAPS for new platforms
• Data Centre - QFX3000-M/G, EX9200, EX4300, QFX3500,
QFX3600, QFX5100

www.juniper.net Sample Request for Proposal • Appendix C-53

Juniper Networks Design Fundamentals

• Campus – EX4300, EX9200, Firescout, Altair

Topology
• QFabric Topology
• VCF Topology
• Auto discovery, topology import
• Physical, logical, Status, utilization and monitoring of links,
ports and devices
Advanced grouping features
• Custom grouping of devices in hierarchical fashion
o Auto assignment of new devices based on predefined
rules
• Grouping of ports from 1 or more device
Zero Touch provisioning
Monitoring
• Thresholding
• Utilization, Top N links, VM mobility
• IPv6 Sessions
Visibility & Troubleshooting
• End-to-end visibility w/fast polling
• Detail client and AP stats
Mobile interface
• Monitoring and Fault management
• Orchestration APIs
• Single point for integration with external Cloud/DC
orchestration tools
• Service and device abstraction
o End-to-end provisioning
o High level APIs supporting L2, L3, Security and
Internet/WAN
o Provisioning of secure multitenant networks on a
shared network infrastructure
• Integrates seamlessly with orchestration tools
o OpenStack
Another element of Junos Space is through the Junos Space Virtual Control
application. Virtual Control allows users to manage, monitor, and control the
virtual networks that run within virtualized servers deployed in the data
centre. Built on the Junos Space Network Management Platform, Virtual
Control contributes to a comprehensive solution that extends across the
routing, switching, and security infrastructure.

Rather than rebuild the virtual switch that comes as part of the hypervisor
software, Junos Space Virtual Control integrates with the hypervisor vendor’s

Appendix C-54 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

existing management tools, delivering a combined solution that benefits from

both vendors’ innovation and Juniper Networks’ orchestration solutions.
Virtual Control integrates with VMware vSphere, providing access to the
VMware virtual switch (vSwitch) framework (both vNetwork Distributed Switch
and vNetwork Standard Switch). Virtual Control, users can discover, manage
and monitor the entire virtual network (vNetwork) inventory consisting of
vSphere Hosts, vSwitches, and virtual machines from multiple VMware
vCenter Server instances. Virtual Control efficiently manages vSwitch Port
Groups and Uplink Port Groups and constantly monitors, logs, and reacts to
vNetwork events to keep track of virtual machine locations in the network.
Virtual Control also allows users to group VMware’s recommended vSwitch
Port Group best practice settings into profiles; using these profiles, Port
Groups that share best practice settings but have varying VLAN requirements
can be quickly and easily deployed on different vSwitches. Virtual Control can
also be used to discover Port Groups being managed via VMware vCenter
Server. This allows for flexible operational models that define how
management responsibilities are split between network and server teams. In
addition, Virtual Control enables error free deployment of VMware services
such as VMotion, Distributed Resource Scheduler (DRS), high availability
(HA), and fault tolerance.
Juniper also provides other options around automation using Puppet for
JunOS all of which can be supported on the proposed platforms.
R019 As we move towards a more virtualized service delivery method, we are High
[6.6.2] aware that automated VM expansion and workload mobility would enhance
the delivery of service to our customer.
Please suggest how your network solution would allow us to exploit some of
the VM mobility options, for example, by permitting IP-address mobility for
services moving between Tech Halls and Data Centres.
Also provide recommendations for Layer 2 and Layer 3 topologies for single
and multiple tech hall scenarios; e.g. limit layer 3 boundaries to a single tech
hall for stability.
Juniper As noted in our response in R008, Juniper has a series of options to provide
mobility of VM’s and the L2 environment between the tech halls and data
centre. We touched upon VPLS, MPLS and Contrail in that response, and
how those technologies can be used to provide not only separation but also
mobility of VM’s across the data Centre. Whilst not wanting to outline the
same elements again, we also leverage juniper switches as VMware NSX L2
gateways and using this functionality with VXLAN to provide the option
vMotion between tech halls and maybe between data centres, but Juniper
use the term maybe because we would suggest an element of caution in
regards to the use of long distance vMotion between data centres and that
maybe limiting the L2 and L3 boundaries to individual data centres or groups
of tech halls would be a safer option as opposed to prospect of live vMotion
between data centres.

This is not to suggest that with the right testing and larger enough WAN pipes
that it would not work, and with the use of EVPN this can be done, but an
element of caution should be held.

Our reasoning behind this is as follows. With the Federation of Clouds the
possibly has been put forward that you can connect data centres using WAN
extensions for the purpose of moving VMs without losing sessions. This is
known as Long Distance vMotion by VMware or generically as long distance
live migration. This means that long distance vMotion would provide better-
allocated server resources and maintain application availability between data

www.juniper.net Sample Request for Proposal • Appendix C-55

Juniper Networks Design Fundamentals

centres and to do so they would need to maintain L2 reachability during

vMotion across the WAN.

Juniper see issues with doing long distance live motion and beyond
debunking the protocols we believe that you should consult with customers
on the use cases and recommend best practices when discussing server
virtualization and networking. Live motion has been demonstrated to work
well within a routing domain and within the data centre using Data Centre
Bridging (DCB) but large scale vMotion over the WAN is mostly unproven and
whilst juniper have tested this to some degree customers should be sceptical
of it.

Long distance live motion over the WAN has limitations due to latency and
bandwidth requirements and the complexity of extending layer 2. Issues
include the potential for misrouted traffic coming to the original data centre
when the VM has moved to the backup data centre, traffic tromboning where
traffic is looped from one router to another, large bandwidth requirements,
storage pooling and storage replication requirements and the complexity of
implementing the bridging architecture. The main problem with moving VMs
around is connecting back to the storage. Storage vendors market replication
schemes that could cause problems for customers and need to be carefully
evaluated.

Customers should consider the implications when implementing L2 live

motion. They should look for implementations that are tested and that scale.
They should look for integrated solutions that ease provisioning of the
network technology to enable live motion across domains and over the WAN.

Listed below are some user cases for vMotion.

• Resource Utilization and Application Availability
The most commonly used and most logical use case for vMotion is for
optimizing resource utilization in the data centre within an L2 domain. In this
case if a server has available resources due to lower application activity VMs
can be moved to it. If VM needs more compute resources than are available
on a server it can be moved to another server in the same rack or on another
nearby rack. If a server is experiencing technical issues or is going down for
maintenance the VMs can be moved to another server. No WAN extensions
are required for this use case.
• Work Load Distribution
In this scenario workloads are moved between data centres based on
capacity availability. A Data Centre might be short of compute resources so
the overload workloads are sent to other data centres using DCI at L2 and
live motion. As an example, Amazon deals with the capacity issue without
moving virtual machines. They simply control VM creation in a DC based on
available capacity. Many VMs are running batch jobs and have a short life
span. Capacity quickly becomes available as they are terminated. If one DC
is over loaded the VM can be created in another. Live motion is not required
in this instance.
• Disaster Avoidance
In this model if a disaster is expected such as a weather storm the idea is that
you start moving the virtual machines to the backup data centre while they
are running. In this user case there is a requirement to have high bandwidth,
low latency, and links in place to handle the traffic that would be created once
live motion starts. It is difficult to estimate how much bandwidth would be
needed and how the migration would take since the users are constantly
updating the VMs and live motion must keep sending the deltas. In any case

Appendix C-56 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

it would be expensive to have the bandwidth standing by just in case it is

needed.

One has to wonder if customers would implement live motion across data
centres to prepare for a once in a life time event of a total DC shutdown when
they can implement a backup plan that is not nearly as complex or costly and
only causes approximately 30 minutes of down time using shutdown, copy
and restart.
• Layer 3 – Routed Live Motion
If customers want to do live motion they could consider routed L3 live motion
which most hypervisor vendors support (VMware, Microsoft, KVM, Citrix).
This method uses dynamic DHCP / DNS updates and can use session
tunnelling to keep existing sessions alive if needed and it does not require L2
bridging.

Since Microsoft has announced support for L3 live motion with dynamic DNS
updates from the DHCP server and VMware has it in their product and so do
KVM and Citrix, L3 live motion is a possible alternative for customers that
don’t want to deal with L2 bridging.

Protocols
Listed below is a summary of the protocols that Juniper would recommend in
a Data Centre scenario where VMotion is an option.
• Eliminate STP
Juniper propose Virtual Chassis Fabric on the EX and QFX Series switches.
No STP needed.
• Scale and Extend VLANs
Juniper proposes VPLS to VLAN stitching from the EX9200 to the QFX or
you could use QinQ or VLAN groups. Juniper also supports EVPN for L2
stretch which could tie back to either VLAN’s within the DC or a VPLS domain
or Juniper contrail.
• Connect to virtual ports
Juniper could propose Virtual Ethernet Port Aggregator (VEPA), which is part
of the IEEE 802.1Qbg and available in the EX and QFX series or Space
Virtual Control.
• Enable L2 bridging for live motion
Juniper - VPLS is traditional. EVPN for the EX9200, which is a Juniper,
sponsored standards track protocol that overcomes the limitations of VPLS.
• Move IP address

ILNP – (Identifier-Locator Network Protocol) Juniper are considering as

an alternative standard to Cisco LISP.

Summary

Whilst the option for vMotion over long distances is possible Juniper believes
that at this time they are untried, untested and to some degree rely on
unreasonable amounts of bandwidth, potentially creating routing problems
and problems reaching storage. Customers should proceed with caution and
carefully consider if they should go long distance vMotion or take a more local
approach to vMotion in the first instance and test long distance vMotion
before implementing it or relying on it as the foundation of their virtual
strategy.

www.juniper.net Sample Request for Proposal • Appendix C-57

Juniper Networks Design Fundamentals

R020 Currently the network infrastructure relies upon physical separation, CAPS High
[6.6.3] approved cryptography and Evaluated firewalls to provide separation
between different security domains.
Please explain how your products could enable us to consolidate physical
resources whilst still maintaining assured separation conformant to CESG
standards such as, but not limited to, GPG12 (Virtualization) , IAS1 Part 2
Appendix C (Assurance) and IAS4 (Cryptography)
Juniper As outlined in response R008, several technologies exist from Juniper to aid
in the secure transportation and separation of traffic with different security
grading’s over a single IP infrastructure. As discussed in responses R008
Juniper can use VPLS to provide separation between the different traffic
types and by creating separate VPLS domains for traffic with different
security grades. The VPLS domains could be stretched between data centres
by either extending VPLS in to the WAN or via the use of EVPN, which would
be tied to the VPLS domains at each Data Centre.

Juniper can also encrypt VPN’s, which would allow traffic deemed restricted
(in the old scheme) or secret (Government new scheme) to not only be
isolated with its own VPLS domain but also encrypted. Traffic graded as
official under the new marking scheme would also be allocated to its own
VPLS domain, but would require no encryption.

Whitepaper on Implementing VPLS for Data Centre interconnectivity

https://www.juniper.net/us/en/local/pdf/implementation-guides/8010050-
en.pdf
Another option as outlined in R008 is to use Juniper’s Contrail system. This
turns the IP layer in to a standard forwarding plane with an overlay of VPN’s
based on MPLS, which provides the routing intelligence. As outlined in R008,
the traffic at each VM within a virtual server would be pushed in to its own
dedicated virtual router or VR. This VR would be push traffic in to its own
dedicated VPN with complete isolation from other VR’s on the same VM
server and from other VPN’s in the network. Isolation in this case would be
the same as if the whole network was a large MPLS network. Encryption
could also be employed on traffic deemed to be secret and above and no
encryption on all other traffic. In the same way as described using VPLS,
EVPN could be used to provide L2 connectivity between data centres and
EVPN’s would be tied back to the contrail VPN instances to complete the
isolation of traffic for intra and inter data Centre communication.

In both of these methods, Juniper believe this would provide the same
standard of security as the PSN and Juniper could implement virtual version
of the CPA approved SRX to provide a complete solution.

Juniper would like to point out at this time we believe the following is still true
from CESG. For the moment, cross-domain solutions (where a virtual
machine is connected to more than one security domain) are specifically
excluded and that data sharing is similarly excluded, though it remains
acceptable to use existing approaches to transfer data (for example, passing
data from one security domain to an external cross-domain solution, and then
returning it to the other security domain). The specific example of writing to
removable media, un-mounting that media, and then remounting it in the
other security domain, is permitted provided the data owners have evaluated
the risks of importing malware or leaking data, and have agreed how they are
going to handle the risks.

With this in mind, we would work with XYZ, Inc. to find a suitable solution,

Appendix C-58 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

which would meet CESG requirements and provide the cost saving of not
having to implement separate solutions.

R021 Please explain how your devices are able to provide increased connectivity High
[6.6.4] and throughput, and how they would enable XYZ, Inc. to:
• Increase speed at which new connections are deployed
• Upgrade to 10GigabitEthernet server connectivity to provide
consolidation of existing bulk 1GE copper connections
• Aid planning for short term peak workloads
Juniper To provide this functionality we have specified mixed virtual chassis fabrics of
EX4300’s to provide RJ45 copper based connectivity and QFX5100’s to
provide 1/10GbE SFP based connections. The QFX5100-48S as described
earlier within our responses provides 48 ports of 1/10GbE and 6 x 40GbE
uplink ports. The 48 ports of 1/10GbE are dual speed ports with no limitation
on what can be 10GbE or 1GbE. In providing dual speed ports as standard,
XYZ, Inc. have a low cost migration policy towards 10GbE virtual servers
when older 1GbE server are no longer required. The only cost in this
migration would be for SFP optics or DAC twinax cables as all of the ports on
the QFX5100 are SFP based.

The same principle applies to uplink ports. Juniper have specified 10GbE
connectivity using the 6 x 40GbE uplink via a 40GbE to 4 x 10GbE breakout
cable to allow 10GbE uplinks on day one with the option as traffic increases
to utilise 40GbE via the introduction of 40GbE QSFP’s and 40GbE DAC
cables.

In introducing this capability from day one as standard across the design,
short term peak workloads can be managed as the migration to 10GbE virtual
servers gathers pace whilst providing a simple platform in the form of VCF to
manage multiple switches from a single management instance.

Another benefit of VCF is that there is no physical limitation in its placement.

If short-term peak workloads dictate that a switch needs installing in a
location but needs to be connected back to a VCF, then the only limitation
would be the Fibre run to connect the switch to the spine node. Once
connected it part of the VCF and will act as such. This would also mean that
servers in different locations that need to be migrated to newer VM servers
could be connected to the same VCF allowing a more flexible migration
approach without the need to move servers.
R022 Regarding pricing and cost innovation: High
[6.6.5] • Please indicate innovation in pricing models that would allow XYZ, Inc.
to move towards a ‘pay for what we use’ charging mechanism. Explain
how this could be applied to your solution offerings.
• Please describe the discount structures that would be offered e.g.
tiered discount structure and rebate schemes
Juniper • Based on a financed amount, (based on the *no rebate quote) IBM
Global Financing can offer XYZ, Inc. a 3 years Fair Market Value
lease with 12 quarterly payments. Using a discount factor of 5%, the
Present Value of the repayments would be 81% of the financed
amount.

At end of lease, XYZ, Inc. would have the following End of Lease
options:

www.juniper.net Sample Request for Proposal • Appendix C-59

Juniper Networks Design Fundamentals

- Return the assets to IBM Global Financing

- Continue with the prime term rentals
- Renew the lease
- Pay the conversion charge (based on the Fair Market Value of the
assets) and
- Keep the assets on peppercorn rental (a minimal annual
charge)
- Sell the assets to an independent Third Party Agent
*Above subject to final pricing and credit approval

• Please see all quotes in Pricing Appendix for Discount structures and
Rebates
We have also provided a TCO Savings report, citing savings of 79% in
power and cooling and 76% in space savings.

Sales Services
Table 13.6: Sales Service Requirements
Ref Requirement Weighting
R023 Pre-sales: Please describe the services and/or resources that could be Mandatory
[6.7.1] available to XYZ, Inc. for both commercial and technical help with the design
and pricing of new project requirements.
Juniper Juniper offers Pre sales resources for Named Accounts, such as XYZ, INC.
Juniper has an assigned security cleared pre-sales resource for XYZ, Inc. , a
named account manager , a partner account manager, a partner technical
account manager, and a resource pool of Sales engineers all based in the
UK, to provide commercial and technical support in a pre-sales environment.
R024 Post-sales: Please describe any post-sales services and/or resources which Mandatory
[6.7.2] could be available to XYZ, Inc., in order to assist with the ongoing support
and maintenance of deployed solutions including, especially regarding any
design/feature/function compatibility and interoperation.
Please provide ‘bug-scrubs’ for proposed solutions.
Juniper Juniper can offer an advanced level of support based on your requirements
and the complexity of your network. In order to assist XYZ, Inc. with the
ongoing support and maintenance of the deployed solutions Juniper has
included optional pricing for the Juniper Care Plus service, in addition to the
Juniper Care maintenance pricing with 4 hour hardware replacement as
requested. The full service descriptions for both Juniper Care and Juniper
Care Plus are provided in the Appendix.

J Care Plus is proactive network service providing a high level of

personalisation. Juniper Care Plus keeps your network at optimum readiness
through a combination of advanced services that mitigate risks, provide
application reliability, reduce learning curves, and accelerate time to value,
including:
• High-touch support of a named account Service Manager
• Direct access to Advanced TAC engineers for P1 & P2 cases
• Proactive network automation solutions that help automate and
simplify the network operation.
• Access to Advanced Services to deliver the following prescriptive
services –
o Software Upgrade Recommendation and Review Service

Appendix C-60 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

(includes a Bug Scrub)

o Product Issue Impact Review Service

o Configuration Analysis and Change Review Service

o Design Change Review Service

o Feature Rollout and Change Review Service

o Network Change Plan Review Service

o Implementation Support Service

o Product Health Check Service

The Advance Services provided through Juniper Care Plus enable you to
effectively manage the ongoing lifecycle tasks of design changes, software
feature and functionality review, network change and associated
implementation planning and software recommendation review of your
software requirements, assessment of software upgrade risk, analysis of
potential impact on your network, and recommendations on a target software
release that can best meet your requirements.

The pre-requisite service product is having a Juniper Care contract in place

that ensures you can take full advantage of all the Juniper Care Plus
features, capabilities, and benefits. Please see the Appendix for further
details within the AS Credits datasheet.
R024a Post-sales: Please describe the services and resources which could be Mandatory
[6.7.3] available for involvement in the design, build and operation of the new
network

Juniper Juniper could provide a Resident Consultant to work alongside the XYZ, Inc.
team for either 6 or 12 months. The Resident Consultant works daily with
XYZ, Inc. staff at your location, becoming intimately familiar with your unique
processes and requirements, your network’s specific configurations and
challenges, and your staff’s strengths and limitations. Your Resident
Consultant helps you avoid many network issues before they arise, and is
fully prepared to help resolve issues as quickly as possible when they do
occur. The Resident Consultant assists with network design, deployment, and
support process definition and documentation, deployment and
implementation of Juniper Networks equipment, and post cutover activities for
your network.

Typical Resident Consultant activities include:

• Troubleshooting the network’s design and architecture issues
• Analyzing network and device configurations
• Providing network design leadership; assisting in identifying and
building solutions
• Testing product features and functionality
• Providing deployment guidance to ensure that implementations are
consistent with design
• specifications
• Providing informal workshops to transfer knowledge to engineering
staff
• Applying industry best practices to the design, planning, and
implementation of the

www.juniper.net Sample Request for Proposal • Appendix C-61

Juniper Networks Design Fundamentals

• network
• Applying extensive industry experience to optimize network
performance and proactively
• analyze potential enhancements
• Evaluating technical specifications for interoperability

The Resident Consultant also assists with deployment of Juniper Networks

equipment, post cutover activities, and day-to-day operations for larger
networks.

Consultancy based project time, is also available, please see the SOW in
appendices

Product Introduction
A new network enterprise platform will represent a significant outlay for XYZ, Inc. to develop
support capabilities, build a service model and execute the migration of services from existing
platforms. The resources and time taken to introduce a new platform to live service are a
significant risk. For each of the below requirements please state how your proposal would reduce
the impact and burden of the risks and costs to XYZ, Inc.
_____________________________________________________________________
Juniper: Read and Understood

Table 13.7: Product Introduction Requirements

Ref Requirement Weighting
R025 Operational capability - takes account of the skills gap between current XYZ, Mandatory
[6.8.1] Inc. design and support capability and that which is required to deploy and
manage new infrastructure. This includes, but is not limited to:
• Cost to retrain
• Number of design and support engineers required
• Access to ‘sandpit’ hardware environments for network staff
Included within your response to address this skills gap, please provide
pricing for:
• Training courses suitable for basic design and support
configuration/troubleshooting
• Advanced training courses to cover:
o Advanced configuration
o Troubleshooting
o High availability (i.e. clustering type technologies)
o Security
o Performance management
Please provide details of any interim operational support that could be
provided whilst XYZ, Inc. support capability is being established.
Juniper Juniper Networks can offer a range of training both in class or elearning (as
per quotation found Appendix two).

Juniper are well versed in cross training, we can offer * to Junos courses, as
well as helpful conversion kits to assist ongoing learning.

We also have FASTRACK… which is self-pace and enables staff to dip in

and out of modules as required. Self pace is free of charge, and can get the
Team proficient to JNCIS level with no financial cost.

Appendix C-62 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

There a lot of complimentary tools, training and resources available to reduce

skills gaps quickly.
Hardware environments will be available within the POC options stated.

Juniper offers Publicly scheduled courses are also available at a per person
cost of approximately $700 per person per day. Alternatively Juniper can
provide Private class training for up to 16 students per class at $7,000 per
day (private, onsite with some customization if required).

Suggested courses include, but are not limited to:

To enable and support the XYZ, Inc. operation team during capability
development and network transition, Juniper will provide the following new
customer services which are complimentary.

Training- JNCIA-Junos Training is offered to prepare up to six (6) Customer

www.juniper.net Sample Request for Proposal • Appendix C-63

Juniper Networks Design Fundamentals

employees to take the JNCSI-Junos certification. This training component of

the Services is designed to help train the Customer technical staff
responsible for design and operations tasks, and to help provide foundational
Junos OS skills needed to support Junos OS devices, including networking
and basic routing and switching fundamentals.

This training has been specifically calibrated for multi-tiered network teams
and includes:

Self-guided multimedia content for training pre-requisites.

In-classroom or live on-line training.

Platform specific self-guided multimedia content for post event studies.

Six JNCIA-Junos OS exam vouchers for technical certification testing.

Network Transition Services- Network Transition Services provide a

Professional Services Consultant (PSC) to assist in ensuring a smooth
transition to Juniper Networks products. The PSC will be assigned to bring
Juniper Networks best practices to the engagement. Typical services include:
implementation planning, device configuration best practices, cutover
assistance and knowledge transfer.

Service Management- Provided on a remote basis for ninety (90) days and
include support for key operational tasks as the Customer becomes familiar
with Juniper Networks’ support infrastructure. The start date is one week after
receipt of the purchase order.

The Juniper Networks Service Manager is a designated named contact

assigned as the Customer advocate within Juniper Networks to manage all
Customer service-related operational activities during local business hours. A
Service Manager is a single point of contact within Juniper Networks to
oversee the delivery of all Customer Relationship Management activities in
the Services.

Deliverables of a Service Manager include the following:

Ensure Users and Products are properly registered

Review list of names: e-mail, phone #s, access requirements

Asset inventory, contract level, and physical locations

Case Monitoring and Tracking

Review notification process via case/site ID

eEscalation Management
 - Serve as customer advocate and Single Point of

Contact for escalation within Juniper Networks

eOperational Review

- Organizational roles

Appendix C-64 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

- Maintenance procedures

- Upgrade procedures

Service Management Support is available during normal business hours

Monday through Friday, 8x5.

R026 Service model – this includes all aspects to build a service around the Mandatory
[6.8.2] infrastructure such as:
• Integration with the XYZ, Inc. enterprise management Framework:
work required to configure and deploy management tools for XYZ,
Inc.’s needs
• Support routes: setting up correct support routes for first, second and
third line support with correct paths for escalation
• Validation of XYZ, Inc. solutions: work required by XYZ, Inc. to validate
standard configurations on new hardware/operating system
combinations – a common issue is availability of hardware on which to
do the necessary validation
Please suggest possibilities for reducing the time and associated cost to XYZ,
Inc. to develop these capabilities which would be necessary before any new
platform could be considered ready for live service. If this includes
chargeable professional services please include appropriate costs in your
proposal.
Juniper Juniper’s Professional Services organization includes the most experienced
and knowledgeable internetworking professionals in the industry. Our team
appreciates the complexities and the subtleties inherent in large-scale design
and can assist XYZ, Inc. with respect to the proposed project.

Data Centre Network Transformation Phases

Juniper takes a lifecycle approach when delivering services, based on three
high-level stages: Plan, Build, and Operate. Our Professional Service team
will work with the Customer throughout the Plan phase of this transformation,
with project management ensuring a clean transition to the Build and
Operate phases within the Customer Services team in the Customer and
Juniper. Alongside managing the transition phases, Juniper Professional
Services including project management team can work with the Customer
Programme Management supporting the deployment and Migration Phases.

The transformation methodology is based on four phases, with the first three
being part of the Plan stage of the network lifecycle:

Figure 1. Four project phases in data centre network transformation

methodology

www.juniper.net Sample Request for Proposal • Appendix C-65

Juniper Networks Design Fundamentals

To support XYZ, Inc. during Build and Operate phase Professional Services
(PS) can provide Resident Consultant (RC) and Test, Implementation and
Migration (TIM) Engineers who can complement the customer engineering
and operation teams.

Integration with the XYZ, Inc. enterprise management Framework

Juniper Networks’ Professional Services has extensive experience in
management systems integration in Data Centre environments and with
Enterprise frameworks. Junos Space provides a number of different
integration methods and interfaces based on standard APIs (e.g. REST,
SNMP, RADIUS/TACACS+, SCP).

Often these APIs can be exploited by external systems directly and can be
integrated by the customer’s systems integrators/partners. Further Juniper
Networks’ Processional Services can provide a range of supporting services
from consultancy through to configuration, customisation, implementation and
testing of the Junos Space API and integration.

In addition to integration Juniper Networks’ Professional Services is able to

leverage a variety of Automation mechanisms in Junos Space (e.g. CLI
Configlets, scripts, templates) and other tools (such as Puppet, Chef, Ansible)
to aid in the automation of build and in-life data centre deployment and
operations functions. Examples include DC/device build automation, frequent
configuration tasks and network/service configuration validation.

To provide not only a cost efficient but also time efficient method of validating
the proposed solution, Juniper would look to validate the proposed solution
with XYZ, Inc. through a Proof of Concept at our labs, which would allow both
Juniper and XYZ, Inc. to define the baseline architecture and a common
configuration set across the equipment not only to test different POC
scenarios but also to carry forward to an on-site test.

Once the POC is complete, we can then take these configuration examples
and implement them in to an on-site testing lab such as SHP01 and produce
cut-down version of the full architecture utilising the equipment proposed for
SHP01 and produce a baseline configuration as we move towards a live
implementation.

Appendix C-66 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Juniper would envisage that the equipment proposed for SHP01 would stay
in that location and would be used for further software testing as the live
solution evolves.

Juniper is also able to provide access to Juniper Cloud Labs, which would
provide XYZ, Inc. with another option for testing software and configurations
in a virtual environment. As this is a virtual system run within Juniper’s private
cloud, XYZ, Inc. and Juniper could produce an example of their network and
then XYZ, Inc. people can access this private cloud to test configurations
before retesting in a lab environment.

In each case these services would allow both Juniper and XYZ, Inc. a
process to validate the design and configuration prior to live implementation
and provide testing for further changes to be tested.

As part of the transition to operational support Juniper will deliver an

“Introduction to JTAC” which will cover the best practice methods to engage
and interact with Junipers support organisation. Covering all aspects of case
handling, technical and management escalation processes from initial contact
to resolution and customer service centre tools and knowledge base systems.
The comprehensive “Guide to JTAC” is also attached in the appendix for
general reference.

R027 Product build definition – represents the work required to develop a standard Mandatory
[6.8.3] build:
• Standard OS image
• Hardening of OS configuration as required to meet XYZ, Inc. security
standards
• Template containing standard base configuration (including device
remote access for config/support and management tool access) and
typical interface/routing configuration
Again, please describe the help you can offer to reduce the impact of
ensuring all the above capability is in place as will be necessary for the
platform to be available for live service. If this includes chargeable
professional services please indicate appropriate costs in your proposal.
Juniper Juniper prides its self on the development and stability of the Junos OS
software. This is in part due to our focus on working with customers to
provide them with the best version of software possible for their deployment
and working with them to introduce new features in to Junos.

As you are aware the Junos operating system is a reliable, high-performance

network operating system for routing, switching, and security. Junos offers
secure programming interfaces and the Junos SDK for developing
applications that can unlock more value from the network

• One operating system: Reduces time and effort to plan, deploy, and
operate network infrastructure and provides the same configuration
experience across all platforms
• One release train: Provides stable delivery of new functionality in a
steady, time-tested cadence.
• One modular software architecture: Provides highly available and
scalable software that keeps up with changing needs

www.juniper.net Sample Request for Proposal • Appendix C-67

Juniper Networks Design Fundamentals

This means that XYZ, Inc. can rely on a standard OS image across all of the
platforms proposed in our solution and after testing standardised across a OS
image that meets all of their requirements.

From a hardening point of view, Junos already goes through several beta
versions of testing both within Juniper and with specific customers before
being released to market. With this in mind, Juniper would sign XYZ, Inc. up
to the Junos Beta program. The purpose of the Beta program is to partner
with customers to test and validate new features prior to FRS release and
also provide customers an opportunity to share with Juniper on their feedback
about our product usability, feature and performance.

In this way, XYZ, Inc. can test new software features prior to release and
decide if these features and the new software version could be implemented
in to the network. Another aspect of the beta release program is that the
Junos engineering team can test functions and features specific to XYZ, Inc.
prior to beta release. Your Juniper aligned SE with XYZ, Inc.’s permission
would provide the Junos team with an in-depth design and configuration of
your network. The Junos team would then test new software against this
design in their labs and provide XYZ, Inc. with the results. This allows XYZ,
Inc. to have Junos developed with their infrastructure in mind.

Your aligned SE would provide beta access and sign up to the programme
upon order of the support contract. This is a free service that Juniper provides
for the benefit of both Juniper and it customers.

To complement the above services, Juniper also has a cloud based virtual
environment called Juniper Cloud Labs, (JCL). JCL is a virtual environment
from Juniper Networks that can reduce the costs of network planning and
modelling by giving users access to a virtual environment where they can
create and run elements and networks that run the Junos operating system.
JCL reduces operational costs and limits risk by providing a virtual networking
lab where flawless network implementations can be modelled and designed.
When built, these networks can be used for training, network modelling,
planning for new services or examining "what-if" scenarios for the installed
network.
Networks created in the JCL environment run the same Junos operating
system that powers Juniper routers, switches and security platforms for
unparalleled realism and accuracy. They can be easily and quickly scaled
down or up to hundreds or thousands of nodes for a level of scale and
accuracy not possible with alternative network simulation approaches.
This would provide XYZ, Inc. another option in meeting their security
hardening processes and testing new features and functions without the use
of a test lab or running in the live environment.
The web link below provides access to more details on this service:
https://jlabs.juniper.net/jcl/
What all of the above items provide is the ability to test and configure a
standard configuration template and OS version for devices prior to
implementation in a live environment, thus reducing risk and time to
implementation.

To also compliment the above processes, Juniper also run a Software

Upgrade Recommendation and Review service. This service provides an
expert review of a customer’s software requirements, assessment of software

Appendix C-68 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

upgrade risks, analysis of potential impact to the Customer’s network and

recommendations on a target software release that can best meet the
Customer’s requirements. This process is part of the Juniper Care Plus
support contract. Details of this service have been included in our additional
information section.

R028 Service migration/deployment risk – covers specific risk to migration of Mandatory

[6.8.4] services to a new platform, this goes beyond the technical migration issues of
server/switch connectivity to include, but not limited to:
• Guarantee of live service during migration period; parallel running of
new and old infrastructure
• Capacity planning to deliver correctly sized infrastructure
• Performance and confidence testing
• Managing risk to the business
• Interoperation of your devices in a multi-vendor network
Please describe any additional offerings that would reduce the impact of
service migration/deployment of XYZ, INC. services, including any risk share
you are able to offer. If this includes chargeable resources please indicate
appropriate costs in your proposal.
Juniper To address the elements outlined above and to reduce the potential impact of
the service migration and deployment to a Juniper based platform, Juniper
would look to break the process down in to the series of modular
components. These components utilise the elements noted in the question
above and place them in to a process that Juniper Professional Services and
our solution team can use to implement the Juniper proposal.

The components are divided in to four areas, Design, Assess, Plan and
Migration.

Design
Effective design is essential to reducing risk, delays, and the total cost of
network deployments. This is the element of the process that ties the sales
and solution team to the customer’s technical team and in turn the Juniper
Pro-services team.

It’s at this point that these teams come together to address the following:
• Build upon the initial solution
• Work out any additional requirements not covered by the RFP
• Gain a thorough understanding of the customers immediate and
long-term business requirements
• How the solution will address these requirements and any future
performance and capacity issues
• Test the initial solution in a POC to validate the architecture and how
the solution will interoperate with the customers’s existing solution
and if they can run in parallel with each other

The output from these processes allows Juniper and yourselves to finalise an
architectural foundation capable of supporting your current needs with the
scalability required to allow you to take advantage of future opportunities. It
also proves the solution so Juniper and XYZ, Inc. can move to the next stage,
which is Assess.

www.juniper.net Sample Request for Proposal • Appendix C-69

Juniper Networks Design Fundamentals

Assess
This starts the process in which Juniper Professional Services become the
project leads from Juniper’s point of view and the sales team step back.
Juniper Professional Services use the following diagram to show their
methodology in migrations.

The Assess process defines three main scopes, which are project definition,
project scope and identifying the potential threats to the implementation and
migration.

Project Definition takes in to account customer deliverables, the necessary

resources that both Juniper and the customer will have, and the outline of
what needs to be done and how that fits in to the overall project.

Project Scope audits the existing infrastructure, identifies any potential issues
that may affect the implementation and categorises them and assigns the
right people to migrate that risk.

This then folds in to the threat identification process so all issues prior to
migration and live service implementation have been tested and signed off
with the right stakeholders and any solution adjustments are agreed.

Plan
The plan element of the Pro-services engagement draws up the necessary
documentation and project scope taking in to account the items already
covered so all aspects of the project are ready to be implemented together
with the potential risks, there dependencies, associated risks and how any
unforeseen issues can be mitigated.

Migrate
The Migrate process is the implementation of the project taking in to account
all of the items noted previously and that the implementation is phased to
mitigate any potential problems. A phased approach would also allow both
the existing and new services to be run in parallel with service from the old
moved to the new once a suitable period of time has passed with both
services running.

A white paper detailing the Juniper Methodology for Transformation of Data

Centre Networks can be found as one of our attachments in the appendix.

Appendix C-70 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

R029 Introduction requirement – covers additional costs for the introduction of new Mandatory
[6.8.5] infrastructure, this can include additional resources such as:
• Project management
• Project architect
Please describe the support available to reduce the additional burden on
XYZ, Inc. of coordinating the introduction of a new hardware platform. If this
includes chargeable resources please indicate appropriate costs in your
proposal.
Juniper Project Management
Essential to the success for the DC Network Fabric is clear concise project
management that ensures that the project runs smoothly and that
communication between Customer and Juniper is strong, including the use of
a shared file structure. Juniper Networks has developed the Juniper Project
Management Methodology (JPMM) based on the standardized PMI and
PRINCE2 project management methodologies, utilizing the best practices from
both and incorporating additional internally developed processes.

Juniper Project Managers employ formal project management methodologies

and techniques based on best practice such as planning of the deliverables,
project kick-off call or meeting, periodical calls or meetings, status updates and
reports, issue resolution and escalation management, change management
and communication, risk management.

• As a methodology, JPMM and its sub-processes, can govern all

types of Juniper Project Delivery requirements, whether in sales or
services domain.

• By applying basic project management discipline to customer

engagement, we can ensure we engage Efficiently, Effectively and
consistently, each and every time.

• Juniper can supply appropriately qualified project managers to run

the Juniper specific work packages to reduce the burden on XYZ,
Inc.

• A Project Architect can oversee all design work and act as the
Juniper Technical Lead.

Juniper Professional Services proposal includes Project Management (PM)

within all PS deliverables and also an option for Juniper PM to complement
customer teams during implementation, migration and operations of the new
DC Juniper solution.
R030 Ability to validate new infrastructure proposal within a supplier or customer Mandatory
[6.8.6] proof of concept lab.
o Old to new integration and connectivity
o Trialling migration options, tools & techniques
o Integration of routing protocols
o Integration of firewalls, load balancers
o Integration in to existing network fault and monitoring
systems

The supplier should indicate which of the listed requirements in this document
can be proved in their Proof of Concept environment

www.juniper.net Sample Request for Proposal • Appendix C-71

Juniper Networks Design Fundamentals

Juniper Juniper can provide proof of concept (POC) against all of the listed
requirements noted above in two ways, either via an off-site POC in one of
Junipers purpose built POC labs or via an on-site POC.

Juniper’s purpose built POC labs are located in Sunnyvale US, Westford US,
Amsterdam NL, Hong Kong and Singapore. Each POC lab can provide a
complete demonstration lab of the proposed solution with full fault and feature
testing and configuration. It can also provide interoperability with third party
products that are part of the solution or the client’s existing network. In each
case we carry a large volume of other vendors’ equipment to allow us to
simulate not only the Juniper network but also an existing customer network
to fully test prior to implementation.

The following areas are usually part of the validation process:

• Support of all required features, especially new features

• Ability to scale to the advertised or necessary degree
• Ability to sustain the necessary level of control and data plane
performance
• Ability to interoperate with other networking devices and/or support
systems

A POC test fits in between the conceptual work performed by the SE to

define the architecture of a Juniper solution and the implementation work
performed by Professional Services to realize that solution in the client’s
network.

The benefits of a Juniper based POC are as follows:

• A controlled, secure environment that minimizes interruptions,

delays, and risks
• Efficient use of Juniper resources
• Cost and time savings for the client who capitalises on Juniper’s
significant investment in their success
• Valuable hands-on experience
• Exposure to Juniper best practices regarding design, testing, and
analysis
• Close integration with the Executive Briefing Centre for achievement
of all meeting objectives
• Opportunity to see other technology and to talk to engineers within
Juniper who are developing the next generation of hardware and
software standards.

A typical Juniper POC involves:

• A client-defined test plan

• A specific test bed topology and hardware requirements defined in
the test plan
• Customized device hardware and software revisions and
configurations, matched as closely as 
possible to the client’s
devices
• Customized tester configuration regarding packet size/distribution,
packet rates, protocols, 
connection setup rates, etc.

Appendix C-72 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

• Validation of defined features/functionality based upon client-defined

test plan criteria
• Acceptance of performance, scale, and failover behavior based upon
client-defined test plan criteria
• One to four weeks of preparation, one to ten days of presentation
• The ability to accommodate change requests prior to the
commencement of staging
• The goal of showing the client we can meet their specific
performance/acceptance criteria

For an on-site POC, the principles are the same, but Juniper would be more
reliant on the customer’s lab environment. Juniper would supply the
necessary equipment from Juniper loans in Amsterdam and ship to site.
Juniper would then resource Juniper based SE’s and Professional Services
team to run the POC with the customer and replicate the same process that
Juniper would use in one of their dedicated POC labs.

It should be noted that a cost may be involved for the professional services
element of this scenario, where as a Juniper based POC would be free
except for travel related costs.

Environmental Requirements
Table 13.8: Environmental Requirements
Ref Requirement Weighting
R031 Please describe initiatives, both technology and methodology, your Mandatory
[6.9.1] organization is implementing to reduce the environmental impact of your
products and services in the following specific areas:
• Manufacture
• Power efficiency
• Disposal
Juniper Juniper's greatest impact on the environment is through our products, so
we're reducing our carbon footprint with products that are environmentally
responsible in all phases of their life cycles, a complex challenge that
demonstrates our commitment to protecting the environment.

We monitor compliance with local and international laws in all of our locations
worldwide, and work with governments, industry partners, and consortia, to
harmonize regulations with innovation. We collaborate with governments,
industry vendors, and customers, to develop and implement energy metrics
that measure the efficiency of networks.

Our product designers and suppliers identify and recommend environmental

improvements through a design for the environment (DfE) program based on
the New Product Introduction process. The priorities of the DfE initiative are
energy efficiency, materials innovation, and recyclability, including:

• Reduced CO2 footprint

• Reduced ozone-depleting materials and substances
• Compliance with legislated restrictions of hazardous substances

www.juniper.net Sample Request for Proposal • Appendix C-73

Juniper Networks Design Fundamentals

• Reduced fossil fuel consumption

Juniper follows EU Directive 2002/95/EC Restrictions of the use of Certain

Hazardous Substances in Electrical and Electronic Equipment. Juniper
Networks follows EU RoHS restrictions throughout all product series. We
have eliminated the use of all banned substances currently outlined in the EU
RoHS directive and reduced the usage of restricted substances to levels at or
below legal limits. And, we continue to improve product designs to meet the
changing environmental requirements though the implementation of the
Design for Environment (DfE) practices.

Juniper provides recycling support for our equipment in order to meet the
European Union's WEEE Directive. All of our products introduced after
August 13, 2005, are marked or documented with an icon depicting a
crossed-out wheeled bin with a bar underneath per the requirement.

The 80 PLUS initiative promotes energy efficiency in power supply units

(PSUs). 80 PLUS certifications are applied to products with greater than 80%
energy efficiency at 20%, 50% and 100% of rated load, and a power factor of
0.9 or greater at 100% load. The Juniper goal is to use PSUs that waste 20%
or less energy as heat loss at the specified load levels, reducing electricity
use and costs compared to less efficient PSUs.
For further details please go to
http://www.juniper.net/us/en/company/citizenship-
sustainability/green/#overview

Additional Requirements
Warranty/Support
Warranty/Support must be in place to cover these units for the period of their service life and
must commence from installation on site rather than from delivery to the bonded warehouse.
Please clearly specify warranty provided with each item/product proposed.
_____________________________________________________________________
Juniper: Read and Understood

Juniper’s Standard Warranty is applied to the QFX. Our Enhanced lifetime warranty is applied to
the EX range, so covering the EX9204 and the EX4300.
Standard warranty covers 1 year and has a start date within 90 days from the original shipment to
XYZ, Inc., please see appendix one, for complete details.
Enhanced Warranty covers 5 years and has a start date within 90 days from shipment date, please
also see appendix one
Juniper would be prepared to offer some flexibility, once we understand the installation schedule
and can seek VP approval for adjournment, within reason.

The Support and maintenance start date can be postponed for up to 6 months after purchase;
however, if the support is not procured within one year from the Hardware purchase date, then
Juniper have the right to impose a reinstatement fee after that time.

Appendix C-74 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Maintenance
During the migration XYZ, Inc. will have a number of existing support and maintenance contracts,
the vendor shall include in their responses how they plan to offset these costs
Regardless of existing XYZ, Inc. support and maintenance contracts with incumbent suppliers, any
response to this RFP MUST include full details of proposed support and maintenance contracts
(including costs). Details that must be included are as follows:
• Warranties
• Recommendations as to engineer support/location
• Type of cover proposed – field support or on-site support
• Direct access to the supplier technical support (people and documentation) for raising
cases and troubleshooting
• Cover periods proposed for type of cover as detailed above (XYZ, Inc. anticipate peak
period utilisation to be 7 day x 24 hour, low periods to be 5 day x 9 hour approx.)
• Annual charges for parts inclusive policy
• Pricing over a 5-year model
• Cost of hardware replacement if faulty unit cannot be returned – any additional cost
needs to be specified if this is not included in the support contract
• A 4 hours SLA for hardware support

Please describe any additional offerings that would include the support of the current switch
infrastructure including costs.
_____________________________________________________________________
Juniper: Read and Understood

With Reference to all of the above queries, they have been answered and incorporated within the
bid document.

References
Please provide two reference sites to support the information within your proposal. These should
include references that demonstrate the following:
• Experience in government accounts
• Interoperability with Cisco Catalyst/Nexus-based Data Centre network deployments
These references will be used to aid marking against the requirements described above.
_____________________________________________________________________
Juniper: Read and Understood

The Prime Minister’s Office, 10 Downing Street had a requirement

to replace their existing network infrastructure with a solution that
would provide a robust and resilient architecture to support the
next generation of applications and secure communications. Their
existing LAN had reached its end of life and support and would
not provide capability to support newer programs and stringent
security requirements.
The Prime Minister’s Office also necessitated an infrastructure so
if crisis hit, they could move the staff immediately to any of the
three sites the PM uses without downtime.

The Cabinet Office also uses Juniper Switches for its internal infrastructure.

www.juniper.net Sample Request for Proposal • Appendix C-75

Juniper Networks Design Fundamentals

The solution is divided between three sites, Prime Minister’s Office and two secure Data centres.
Within each location is a dual core layer connects to a series of spine and leaf virtual Chassis’s.
These three core locations are connected to each other via dual 10GE dark fibre to create a
resilient MPLS ring.

The core layer at each site is dual connected to form a Virtual Chassis. Due to the security
requirements at all sites, users PC’s connect to the network via direct fibre as such the access
layer of the solution consists of 1GbE Fibre switches acting as leaf nodes connecting back to a
spine layer of 10GbE switches to form a Virtual Chassis’s. This is then replicated to form a series
of virtual Chassis’s which make up the user connectivity at each site and is duplicated in to the
data centres for server connectivity

Intercontinental Exchange Group is the leading network of regulated exchanges and

clearinghouses for financial and commodity markets. Globally, ICE operates 23 regulated
exchanges, 5 central clearing houses, and more than 9,700 traded contracts and securities
across all major asset classes.
In November 2013, ICE completed its acquisition of NYSE Euronext.

• NYSE Euronext needed next-generation data centres, consolidating from 10 to 4, to meet its
stringent requirements for high performance, extraordinary reliability, low latency, scalability,
and trading predictability
•
• Juniper deployed EX Series Ethernet Switches (800+), QFX 3500 (125+) and MX Series 3D
Universal Edge Routers (40+)

• Juniper’s security presence at NYSE includes Remote Access Infrastructure, Site to Site
VPN, and Active Directory User Authentication

• “Juniper Networks’ simplified data centre approach allows us to deploy a complete 10

Gigabit Ethernet network with ultralow latency at substantial cost savings.” – Steve Rubinow,
EVP/CIO

Supporting Material
Vendors can include any other supporting material within their proposal that they feel adds value
to XYZ, Inc.’s strategic aims and brings innovation whether through technical capability,
professional services or commercial offerings. This material will be used to aid marking against the
requirements already defined.
_____________________________________________________________________
Juniper: Read and Understood. Please see Appendix 1 for supporting technical datasheets.

Appendix C-76 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Juniper would also like to offer XYZ, Inc. an ‘On boarding Package’. This is a program that
eliminates potential risk when migrating to Juniper
We offer it as a free of charge value add, when Juniper have no current estate in an end user
Customer, such as XYZ, INC. * The part number is within the Hardware Pricing as Zero

Please see Appendix Two for all details.

www.juniper.net Sample Request for Proposal • Appendix C-77

Juniper Networks Design Fundamentals

Commercial Offering
Please see Appendix Two, Pricing for Hardware, Support & Maintenance and
Professional Services, Value Add and TCO.

Appendix C-78 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

Legal
Please note that Juniper Networks is the manufacturer of the equipment proposed in this RFP.
Accordingly, Juniper Networks and XYZ, Inc. will not have a direct contractual relationship. Any
contract for purchase of hardware, installation and commissioning templates will therefore need
to be negotiated and agreed upon between XYZ, Inc. and ACME. Juniper Networks will not be
bound by the terms and conditions of such contract between XYZ, Inc. and ACME.

www.juniper.net Sample Request for Proposal • Appendix C-79

Juniper Networks Design Fundamentals

Appendix One - Appendices

• EX9204 datasheet and EX4300 datasheet

EX9200.pdf EX4300.pdf

• QFX5100 datasheet

QFX5100.pdf

• Junos Space datasheet

Junos Space.pdf

• Juniper Methodology for Transformation of Data Centre Networks

A Methodology for
Transformation of Data Center Networks.pdf

• JCare, JCare Plus and AS Credits datasheets

JCare.pdf JCare Plus AS Credits.pdf

datasheet.pdf

• JTAC Guide

Appendix C-80 • Sample Request for Proposal www.juniper.net

 Juniper Networks Design Fundamentals

JTAC Guide.pdf

• Standard and Enhanced Warranty Datasheets

Standard Product
Enhanced Limited
Lifetime Warranty on EX.pdfWarranty.pdf

NOTE: You can access the documents from the Resources section of the module.

www.juniper.net Sample Request for Proposal • Appendix C-81