Colt SDN NNI Inter-provider Standard APIs BoFMEFMembers Meeting – Q4 2016 Ottawa

Simon Farrell, Javier Benitez Strategy & Architecture

1 May 2023 1

Agenda

A new Era in Ne twork ing : SDN & NFV 2

Colt Overview

On Demand Vision

SDN NNI PoC

API Evolution

MEF LSO & Next Steps

1

2

3

4

5

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

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.

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

01/05 /2023 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?  

01/05 /2023 7

SDN NNI PoC (July’16)

US Tier-1 SPNetwork

US Tier-1Service

Provider site

Colt London Beaufort House

Colt Barcelona

Colt Frankfurt

US Tier-1Service Provider

portal

Novitas portal

Novitas engine

Service Enquiry Service Activation Service modification

(Bandwidth Flexing) Service Cease

Novitas SDN API calls

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

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

AccessRing

3rd-party Network

Colt Network

Node

DCNNI

3rd-party portal

Novitas portal

OSS/BSSOSS/BSS

SDN/NFVService Abstraction Layer

API

Backend

ColtSDN & NFV Controller

3rd-partySDN & NFV Controller

API

VNF A VNF B

9

APIs

1 May 2023 Presenta t ion t i t l e

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

Under the hood

1 May 2023 Presenta t ion t i t l e 12

Evolution

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 innovationJust In Time design

Example: address book managementExample: automated route selection

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

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

1 May 2023 Presenta t ion t i t l e

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?

1 May 2023 Presenta t ion t i t l e

Thank youFor your time

Any questions?