by Linda Dunbar, Huawei
SD-WAN Exchange Workshop
Feb 15 2017 11am ~ 4pm EST.
Location: BNY Melon office New York.
On-site people (30~40);
WebEx: Cabe Cole; George Zhao (Huawei); Jem Pagan; Kevin Vachon (MEF); Linda Dunbar (Huawei); Michael Bugehagen (CenturyLink); Pascal (MEF); Paul Barrett; Randhir Chawda; Ray Lovett; Robin Mersh; Snehal Patel; Stephen Collin; Steve Woo (Cisco); TZ
Nick started the introduction:
ONUG != Standard.
Workshop goal: OSE to focus on demo or Spring meeting. (using Spring & Fall meeting to drive progress).
SD-WAN: has been dominated by vendor community. 60% are in development stage.
Pascal gave the introduction of MEF SD-WAN relevant work
Pascal (previous 10 years with Microsoft working on Skype Link) presented the MEF’s SD-WAN Project briefing
CPE has MPLS & BGP peering with provider’s VPN. Using internet to carry light traffic.
Questions: the APIs you developed available for non-members?
Pascal: only for the members now.
Questions: how do you make sure if enterprise can use those APIs?
Pascal: we only worked with service providers, that is why we come to ONUG, hoping to get Enterprise feedback.
Q: can you describe some APIs? All you have shown are connectivity
Pascal: get the information model correct. We also have SD-WAN vendors joining MEF, intend to have the API correct.
Michael Bugenhagen (from Century Link) presented the BBF work on SD-WAN
Any services require multi-operator across the network. This group is trade organization to define contracts among operators. CenturyLink has to deal with multiple trading partners.
CenturyLink is already using Portal to partner with Microsoft and Amazon.
Strategy Discussion for the ONUG SD-WAN Exchange WG.
Comparing MEF reference model with the ONUG S
Is the customer side only the portal?
On-site: there is motivation for APIs.
Steve Woo: what we see most SD-WAN deployment is from single vendor. The API should focus on the interface to the orchestration and to users.
On-site: we should work on our interfaces (APIs) for enterprises. Let other bodies (like MEF) work on the service providers interface.
Steve Woo: define APIs not only to other vendors, but mainly to multiple operators.
On-site: between CSP (connectivity Service Provider), we might need to look at it.
On-site: I don’t want service providers to dictate our interface for enterprises. For NNI, I would rather go to SD-wan provider to take care of.
The solution that MEF provide is from connectivitiy point of view. But didn’t address how to interact from Tool vendors perspective.
For the picture above, the Gc/Gm/Go/Gx/Gy are the interfaces MEF want to address. ONUG also intend to address.
Steve Woo: MEF’s Single SP version is more like ONUG’s framework.
On-site: it would be clearer if ONUG don’t dive into the underlay layer. Let other parties to take care of the underlay.
ONUG use case:
On-site: even with MPLS, it is largely one vendor solution. Our focus should be NOW. Quick way is to focus on single domain. Carrier has been slow in adopting SD-WAN. Only recently they start to look at it.
We need clean demarcation, use portal to interconnect multiple SP domains. We can focus on the internal one.
From Liaison perspective: we can simply ask MEF to give connectivity.
From Analytic perspective: we can work on the detail. We can work on common APIs in this area. Multi-vendors interoperability among multi-vendor analytics.
Our focus should be on Enterprise Control.
We should also work on the interface of multi-vendor SD-WAN.
Summary: our group should focus on the Enterprise Control. Collaborate with other SDOs (MEF) for the underlay network connectivity.
One important thing for us: Key management. For encrypted traffic. How to do it end to end. We really don’t want the encryption to be within one single domain (then the encryption to be decrypted between domains).
Which is more important: Demo? Or specification?
Should work on the specification first, and then on the demo
Demo could be using the APIs to trigger some actions. Each vendor can do their own.
As a group, we need to deliver architecture specification, we still have authentication and service chaining on the To-Do list.
Ideally, have a video.
Nick: on the dropbox,
Linda: the dropbox is currently empty.
Nick: correct link will be sent out later.
Our charter is not to do standard. So having focus on API is good.
Summary: Lot of overlap with MEF and BBWF.
Motivation is different. MEF can focus on the underlay orchestration.
ONUG: focus on the service APIs – liaison with MEF to compare.
Deliverables for ONUG:
- Service Specs and API definitions for path service.
- Show API operation across vendor controllers (controller correctly programed),
- show multi-vendor agg into a DC with common policy.
- Service : Hybrid Cloud Access service considerations
Task Force: Scott van de Houten (Cisco), Al Brosius (First Data), Toshal D (Nuage).
- Cloud service homologation
- SD-WAN edge in Cloud service – DC side interface standand
- Underlay only access
- Service Chaining:
Linda: ONF L4-L7 WG (with Linda Dunbar being the Chair) not only has specified Service Chaining architecture and technical specification, but also conducted 9 vendor PoC for NFV demonstrating service function chaining using the OpenStack Orchestration Service Function chain. IETF SFC has work item on standardizing the data plane (NSH header) and control plane requirement.
What is the goal of SF in SD-WAN domain?
There are at least two aspects to SFC: one is chaining a set of service functions together (treating all the SF as black boxes); another is dynamically sending the appropriate rules/policies to the SF (especially virtual SF), so that they can perform the needed functions.
Chair: well, we try to sort out what is needed.