colt inter-provider sdn nnis and apis
Post on 12-Jan-2017
285 Views
Preview:
TRANSCRIPT
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
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
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
top related