As SDN & NFV services become commercially available, the industry needs to approach once again the reach issue. There is not a single service provider with complete reach; that is why we build NNIs and need a wider SDN/NFV Ecosystem.

1. Colt SDN NNI
Inter-provider Standard
APIs BoF
MEF
Members Meeting – Q4 2016 Ottawa
Simon Farrell, Javier Benitez
Strategy & Architecture
25 October 2016 1

2. Agenda
A new Era in Networking: SDN & NFV 2
Colt Overview
On Demand Vision
SDN NNI PoC
API Evolution
MEF LSO & Next Steps
1
2
3
4
5

3. On-Net Fibre Coverage Network Reach Partner Coverage
• 24K + On-Net buildings
• 585+ 3rd-party data centres
• 29 Colt-owned DCs
• 2500 PAON buildings
• 205 city PoPs in 28 countries
• 49 MANs
• 49K+ km terrestrial network
• 130K+ km subsea network
• 919 COs (635 EFM)
• 390 E-NNIs in 180 cities to 146
countries

4. On Demand Services (Colt Novitas)
4
Changing the nature of today’s network services:
Self-
provision
Near
real-time
Interworking
with other
providers
Available
through portal
and APIs
Provides
performance
analytics
And delivering important benefits:
Supports
value added
services
Elastic
Topology
Elastic
Service
Deliver programmable flexible topologies
based on overlay and underlay networks.
Deliver virtualised off-net and on-net L2 and
L3 edge services on top of basic connectivity.
SDN
NFV
Elastic
Bandwidth
Deliver programmable elastic links with
variable bandwidth.

5. Available through the Colt portal or via API
Intuitive /
Human friendly
Enables automation /
Machine friendly
Standard HTTP based RESTful API
delivered with TLS over the internet
or
5

6. Problem Statement: the need for a wider SDN/NFV Ecosystem
• There is not a single SP with complete reach; that is why we build NNIs
• But, traditional NNIs have been bespoke, i.e., very expensive to implement
• Focused on replacing “electronic paper” and not the overall order/request
management
• As SDN & NFV services become commercially available, the industry needs to
approach once again the reach issue (customers already asking)
• Colt Novitas has been designed from day one with the vision to extend the new
OnDemand network capabilities beyond Colt’s footprint and into third-party
networks
• Colt has engaged with a number of SPs to discuss and plan for real SDN inter-
provider connections (consensus around the need to solve the reach issue)
• Colt jointly with a Tier 1 US SP successfully built a PoC last summer
demonstrating Ethernet on demand across the two networks, between US
and EU
• What now?: how do we drive the industry towards “agreed” APIs? And more
importantly, how do we do it quickly?
10/25/2016 6

7. 10/25/2016 7
SDN NNI PoC (July’16)
US Tier-1 SP
Network
US Tier-1
Service
Provider site
Colt London
Beaufort House
Colt Barcelona
Colt Frankfurt
US Tier-1
Service Provider
portal
Novitas portal
Novitas
engine
 Service Enquiry
 Service Activation
 Service modification
(Bandwidth Flexing)
 Service Cease
Novitas SDN API calls
SDN
E-NNI
Scope: ordering, delivery and in-life management of Ethernet services between the
east coast of the US and various locations in Europe using a live video stream to
visualize the actions taken: our partner could, through their own online portal which
communicated to the NOVITAS API, reserve ports, order a point-to-point Ethernet
service, flex the bandwidth up and down and cease the service.

8. SDN & NFV NNI Full Concept
Objective: drive the industry towards API “agreement” enabling scalable, simple,
fast and cost-effective SDN & NFV Network to Network Interconnections.
8
Backend
Access
Ring
3rd-party
Network
Colt
Network
Node
DC
NNI
3rd-party
portal
Novitas
portal
OSS/BSSOSS/BSS
SDN/NFV
Service Abstraction
Layer
API
Backend
Colt
SDN & NFV
Controller
3rd-party
SDN & NFV
Controller
API
VNF A
VNF B

9. APIs
25 October 2016 Presentation title 9

10. APIs - Technical detail
• RESTful API
• Username/password + persistent
session
• Simple domain model, initially
Standard HTTP based
RESTful API delivered
with TLS over the
internet
using
Object
Create
Read
Update
Delete
Port    
Connection    
Request  
Product / Price 
• Partner = customer
• One set of APIs for all clients

11. Under the hood

12. Evolution
25 October 2016 Presentation title 12
API Functionality
•EPLs
•Existing DCs
•Single ME domain
•Soft provisioning
• EVPLs
• Existing on-net
with CPE
• NNIs
• CSP access
• Long-running
(hard provisioning)
• EPNs
• Multi-vendor CPE
• Multiple ME
domains
• L3 services
•Port
•Connection
•Request
•Pricing
• RBAC
• Bill prediction
• Intelligent
route selection
• Address book
• Cloud resilience
• Chain long-running
requests
• Performance
Reporting
• L3 services
Ethernet Functionality
Premature standardisation can hold back innovation
Just In Time design
Example: address book management
Example: automated route selection

13. API Swagger example
PUT /api/connection/<connection id>
A HTTP PUT request to the /api/connections
resource initiates the process of modifying an
EVC. The body of the request must be a JSON
object containing details of the EVC to be
modified and its target specification.
There are two forms of request. The first
requests a commercial change of some kind –
e.g. a change to the commitment period or a
bandwidth change; this is uniquely specified by
a price ID and takes the first form shown.
The second form requests a change to non-
commercial attributes, currently VLAN
configuration.
This operation requires a session token
provided in the auth-token HTTP header.
The response to this call is a HTTP 200
response code and a JSON object containing
the URL of the trackable request that
represents the EVC modification.
{
"price_id": "11",
"coterminus_option":"true“
}
}
{
"a_end_vlan_mapping":"F",
"b_end_vlan_mapping":"F",
"a_end_vlan_type":"C",
"b_end_vlan_type":"C",
"a_end_vlan_ids":[
{
"from_id_range":23,
"to_id_range":23
}
],
"b_end_vlan_ids":[
{
"from_id_range":23,
"to_id_range":23
}
]
}
{
“response_url": “https://ondemand.colt.net/api/requests/4662"
}
Request Object – commercial change
Request Object – VLAN change
Response Object

14. API technical evolution – under consideration
HATEOAS?............many standards for JSON support
 Redesign API responses?
SAML/Oauth…… “Nice to have” initially, now becoming
important for UI & therefore APIs
 Redesign Authentication?
Multi-language APIs?.....probably not
Reconsider Swagger….does not easily support overloaded
methods
Websockets…. mainly for UI support & to eliminate API polling
 Eliminate or restrict polling?
Proper semantic versioning…...big mistake not to include this
from the start
Developer sandbox with stateful model behind the APIs

15. Lessons learned
Premature design stifles innovation
- Use cases (and therefore APIs) are still evolving:
add attributes, add query parameters, add new
services
Domain Objects vs Data Model
- Data Model approach requires a crystal ball and an
extremely generic model, which is harder to code
against, not self-explanatory and easy to
misinterpret
- The same comment applies to API functionality
No difference between customers and partners
- (and salesmen!)
80/20 rule and YAGNI apply to API design exactly as they do
to application design
25 October 2016 Presentation title 15

16. Thoughts on Standardisation
Simplicity – juggle completeness of vision with ease of adoption
Start small – Minimum Viable Product
- Wait for adoption before extending
- How many adopters constitute a critical mass?
- The bigger the API, the harder it is to adopt: discuss!
Post-adoption – what frequency is best to revise & extend?
- Juggle requests for enhancement with stability/ ease of adoption
- Providers will enhance the APIs themselves, anyway
- How to adopt best practise as defined by what enhancements get
used?
Open source model – is forking good or bad?
- Decentralised by its nature
- Software is judged by number of pull requests, number of forks
- But standards need stability! How to resolve this tension?
25 October 2016 Presentation title 16

17. Thank you
For your time
Any questions?