Jeff,
Comments In-Line..
Thanks,
Jim Uttaro
From: BESS [mailto:[email protected]] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica <[email protected]>
Cc: [email protected]; RTGWG <[email protected]>; Eric Rosen <[email protected]>;
Robert Raszuk <[email protected]>; Linda Dunbar <[email protected]>
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01
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.
[Jim U>] Is this specific to inter-operability with secure-l3vpn-01 or intended
as a general statement in re interoperability with the 2547 ?
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]<mailto:[email protected]>> wrote:
+1
Let’s follow up on this discussion in Montreal.
From: Linda Dunbar <[email protected]<mailto:[email protected]>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura <[email protected]<mailto:[email protected]>>;
Robert Raszuk <[email protected]<mailto:[email protected]>>
Cc: Ron Bonica <[email protected]<mailto:[email protected]>>; RTGWG
<[email protected]<mailto:[email protected]>>; Eric Rosen
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[email protected]>>
Cc: Ron Bonica <[email protected]<mailto:[email protected]>>; RTGWG
<[email protected]<mailto:[email protected]>>; Eric Rosen
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Linda Dunbar
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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:
[cid:[email protected]]
Do I explain well? If not, can we talk face to face in Montreal?
Thanks, Linda Dunbar
From: Ron Bonica [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar <[email protected]<mailto:[email protected]>>;
Eric Rosen <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[email protected]>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen <[email protected]<mailto:[email protected]>>; Ron Bonica
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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:
• 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=zU9RrstHx08_qwVE-_wbaPcJUwA0Cx7W9wg4K6cDAOs&s=1SH5CDBkEFKTyKPWRpPpy-dfxkl19-hrgXiR7nRkq50&e=>
Appreciate your comments and suggestions to our gap analysis.
Thanks, Linda Dunbar
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=-YF-QCTv5uEfMyt2Wc0PmtR67-K6YA_3N6rtLgrOn8s&s=SriB9BByrX7UeyUS1mlwSgHjqLf0roIqfTnM8SdQA7E&e=>
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=-YF-QCTv5uEfMyt2Wc0PmtR67-K6YA_3N6rtLgrOn8s&s=SriB9BByrX7UeyUS1mlwSgHjqLf0roIqfTnM8SdQA7E&e=>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
