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 <[email protected]> wrote: > > +1 > > Let’s follow up on this discussion in Montreal. > > From: Linda Dunbar <[email protected]> > Sent: Friday, July 6, 2018 4:33 PM > To: Jeff Tantsura <[email protected]>; Robert Raszuk <[email protected]> > Cc: Ron Bonica <[email protected]>; RTGWG <[email protected]>; Eric Rosen > <[email protected]>; [email protected] > 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:[email protected]] On Behalf Of Jeff Tantsura > Sent: Friday, July 06, 2018 3:20 PM > To: Robert Raszuk <[email protected]> > Cc: Ron Bonica <[email protected]>; RTGWG <[email protected]>; Eric Rosen > <[email protected]>; [email protected]; Linda Dunbar <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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:[email protected]] > Sent: Friday, July 06, 2018 1:25 PM > To: Linda Dunbar <[email protected]>; Eric Rosen <[email protected]>; > [email protected] > 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 <[email protected]> > Sent: Thursday, July 5, 2018 11:53 AM > To: Eric Rosen <[email protected]>; Ron Bonica <[email protected]>; > [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
