There are also many companies using EVPN as the control plane. It is important to find a “golden middle” where on one side we achieve interoperability but on another don’t hinder the innovation in that, fast growing space. Data planes are a jungle and would not be standardized any time soon. However - an abstraction on top would be very useful.
Regards, Jeff > On Jul 6, 2018, at 14:23, Ron Bonica <rbon...@juniper.net> wrote: > > +1 > > Let’s follow up on this discussion in Montreal. > > From: Linda Dunbar <linda.dun...@huawei.com> > Sent: Friday, July 6, 2018 4:33 PM > To: Jeff Tantsura <jefftant.i...@gmail.com>; Robert Raszuk <rob...@raszuk.net> > Cc: Ron Bonica <rbon...@juniper.net>; RTGWG <rt...@ietf.org>; Eric Rosen > <ero...@juniper.net>; bess@ietf.org > Subject: RE: [bess] comments and suggestions to > draft-rosen-bess-secure-l3vpn-01 > > Jess, > > Great Action! There are much more than the Data modeling. > A lot to be done in Control Plane. Many SD-WAN deployment (ours included) use > NHRP/DMVPN/DSPVN to manage routes via internet. But NHRP being developed > decades ago (for ATM) just doesn’t scale to support Managed Overlay network > of 100s or 1000s CPEs. > > Linda > > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura > Sent: Friday, July 06, 2018 3:20 PM > To: Robert Raszuk <rob...@raszuk.net> > Cc: Ron Bonica <rbon...@juniper.net>; RTGWG <rt...@ietf.org>; Eric Rosen > <ero...@juniper.net>; bess@ietf.org; Linda Dunbar <linda.dun...@huawei.com> > Subject: Re: [bess] comments and suggestions to > draft-rosen-bess-secure-l3vpn-01 > > Robert/Linda, > > RTGWG chairs have been thinking of starting SD-WAN discussion in RTGWG. > Service data modeling(data modeling in general)is an obvious candidate (at > ONUG we started, there’s some early effort, but IETF help is needed). > Control plane interworking is another interesting topic. > Please bring your ideas, I’m still working on agenda > > > Regards, > Jeff > > On Jul 6, 2018, at 13:12, Robert Raszuk <rob...@raszuk.net> wrote: > > Hi Linda, > > What you are expressing is very clear and in fact happens today on any good > SD-WAN controller. > > But in the context of this discussion are you bringing it here to suggest > that draft-rosen-bess-secure-l3vpn should have such functionality build in ? > > Personally I don't think it really belongs in this draft as perfect sweet > spot for it still IMHO resides on a SD-WAN controller. Pushing all that logic > into BGP may be a bit excessive ... > > Many thx, > R. > > > On Fri, Jul 6, 2018 at 9:32 PM, Linda Dunbar <linda.dun...@huawei.com> wrote: > Ron, > > This is referring to a Managed Overlay WAN services with many CPEs (large > scale SD-WAN) and where > - there are many CPEs at each location and multiple WAN ports on each > CPE > > - SD-WAN Controller needs to detour a path between Site -A-& Site-B > via another site (e.g. Site-C) for reasons like Performance, Regulatory, or > others. Instead of designating to specific CPE of the site-C. > > > It is preferable to partition CPEs to clusters, as shown in the figure below: > > > > Do I explain well? If not, can we talk face to face in Montreal? > > Thanks, Linda Dunbar > > From: Ron Bonica [mailto:rbon...@juniper.net] > Sent: Friday, July 06, 2018 1:25 PM > To: Linda Dunbar <linda.dun...@huawei.com>; Eric Rosen <ero...@juniper.net>; > bess@ietf.org > Subject: RE: comments and suggestions to draft-rosen-bess-secure-l3vpn-01 > > Hi Linda, > > I’m not sure that I understand what you mean when you say, “aggregate > CPE-based VPN routes with internet routes that interconnect the CPEs”. Could > you elaborate? > > Ron > > > From: Linda Dunbar <linda.dun...@huawei.com> > Sent: Thursday, July 5, 2018 11:53 AM > To: Eric Rosen <ero...@juniper.net>; Ron Bonica <rbon...@juniper.net>; > bess@ietf.org > Subject: comments and suggestions to draft-rosen-bess-secure-l3vpn-01 > > Eric and Ron, > > We think that the method described in your draft is useful for CPE based > EVPN, especially for SD-WAN between CPEs. > But, it misses some aspects to aggregate CPE-based VPN routes with internet > routes that interconnect the CPEs. > > Question to you: Would you like to expand your draft to cover the scenario of > aggregating CPE-based VPN routes with internet routes that interconnect the > CPEs? > > If yes, we think the following areas are needed: > > • For RR communication with CPE, this draft only mentioned IPSEC. Are > there any reasons that TLS/DTLS are not added? > > • The draft assumes that C-PE “register” with the RR. But it doesn’t > say how. Should “NHRP” (modified version) be considered? > > • It assumes that C-PE and RR are connected by IPsec tunnel.. With > zero touch provisioning, we need an automatic way to synchronize the IPSec SA > between C-PE and RR. The draft assumes: > > p A C-PE must also be provisioned with whatever additional information is > needed in order to set up an IPsec SA with each of the red RRs > > • IPsec requires periodic refreshment of the keys. How to synchronize > the refreshment among multiple nodes? > > • IPsec usually only send configuration parameters to two end points > and let the two end points to negotiate the KEY. Now we assume that RR is > responsible for creating the KEY for all end points. When one end point is > confiscated, all other connections are impacted. > > > If you are open to expand your draft to cover SD-WAN, we can help providing > the sections to address the bullets mentioned above. > > We have a draft analyzing the technological gaps when using SD-WAN to > interconnect workloads & apps hosted in various locations: > https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/ > Appreciate your comments and suggestions to our gap analysis. > > > Thanks, Linda Dunbar > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
