Jeff, In this space there are two ways the below topic could be addressed:
• try to standardize control plane and data plane (or force everyone to use one of already available ones ex: LISP) • accept that it is to our common advantage to have different control planes, use different wire encapsulation between edges and edges to control plane and only focus on building the standard interconnects With the above let's also keep in mind that what we are putting under sd-wan umbrella are quite often very different use cases and solutions to address them: - L3vpn/l2vpn replacement - easy secure access to public clouds - light CPE + cloud based application execution - IoT sensor placements and their central mgmt I am not sure if putting all of those under the same control and data plane is actually a good thing to any of the above. Cheers, R. On Nov 14, 2016 02:07, "Jeff Tantsura" <[email protected]> wrote: Hi Linda, Thanks for the slides! 2nd slide needs to be fixed. In my earlier feedback I asked you to add more slides to expand on generic issues is the space, such as jungle of on the wire encaps, lack of standardized control plane to mention just a few. I’d appreciate if you could add those to facilitate the discussion. There are number of front runners on this space, startups such as Versa, Viptela, VeloCloud, etc, more established companies such as Citrix, Cisco, Juniper, Nokia and Riverhead. Most of them have people who used to participate in IETF work and could be approached for collaboration. Personally, during the panel at SD-WAN summit in Paris I brought up set of issues described above and there seems to be willingness (and push from their customers) to work together on data models, standardized encodings and potentially control plane. Thanks! Cheers, Jeff *From: *Linda Dunbar <[email protected]> *Date: *Sunday, November 13, 2016 at 12:45 *To: *Chris Bowers <[email protected]>, "[email protected]" < [email protected]>, Alia Atlas <[email protected]> *Cc: *"<[email protected]>" <[email protected]>, RTGWG <[email protected]>, Lucy yong <[email protected]>, Songxiaolin <[email protected]>, "Chenrui (Richard)" <[email protected]> *Subject: *presentation slides for SD-WAN (Overlay VPN) at the RTGwg meeting in IETF97 RTGwg Chairs, Attached is our presentation slide for Tuesday RTGwg session. Thank you very much for giving us the slot. Linda *From:* Linda Dunbar *Sent:* 2016年11月3日 11:43 *To:* '[email protected]' <[email protected]>; '[email protected]' <[email protected]>; Alia Atlas <[email protected]> *Cc:* '<[email protected]>' <[email protected]>; '[email protected]' < [email protected]>; Lucy yong <[email protected]>; Songxiaolin < [email protected]>; Chenrui (Richard) <[email protected]> *Subject:* request a presentation slot at the RTGwg meeting in IETF97 Chris, Jeff, and Alia: We would like a 10-minutes slot at the RTGwg meeting in IETF97 to describe a new type of private network service: * https://datatracker.ietf.org/doc/draft-dunbar-opsawg-private-networks-over-thin-cpe/ <https://datatracker.ietf.org/doc/draft-dunbar-opsawg-private-networks-over-thin-cpe/>* In a nutshell, this new type of private network service - is like SD-WAN in the way that IP tunnels are automatically established from a thin-CPE at customer site, - but different from SD-WAN because there are interactions with the underlay network (even though the interaction to underlay network is transparent to users), and there are gateways (for private networks) instantiated in the underlay network to establish secure connections between Thin-CPEs and the gateways, and guaranteed QoS from the underlay networks. The draft was submitted to opsawg. But after discussing with several IETF veterans of the draft, we have been told that the RTGwg is more suitable, as the new type of service described in the draft will need some protocol work. Some of the protocol work needed are documented in https://datatracker.ietf.org/doc/draft-templin-aerolink/, such as Interface Characteristics, Relay Behavior, Interface Forwarding Algorithm, Router Discovery, Prefix Delegation and Autoconfiguration, Interface Route Optimization, etc. (not to say the protocols described are 100% correct & applicable). Some items listed in "draft-kanugovi-intarea-mams-protocol-01" are applicable too, such as - Access technology agnostic interworking - Independent Access path selection for Uplink and Downlink - IP anchor selection independent of uplink and downlink access - Adaptive network path selection - Configuring network middleboxes based on negotiated protocols The draft describes a private network laid over multiple Thin CPEs (or Overlay VPN for easy of description). "Overlay VPN" is a type of private networks that interconnect thin CPEs at multiple client sites by IP tunnels, or more specifically, lay over multiple client sites’ Thin CPEs via IP tunnels. Those private overlay networks not only interconnect those sites by secure IP tunnels but can also enforce the client specified policies to govern how applications or hosts within those sites communicate and how to access public internet. Thank you very much. Linda Dunbar _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
