Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

IMO, there is going to be a need for that the various flavors 
of SD-WAN to inter-operate with the current suite of network services with an 
emphasis on 2547.  May be best to approach this as we did with EVPN and create 
a requirements draft detailing what the need is.

Thanks,
Jim Uttaro

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com]
Sent: Tuesday, July 10, 2018 10:11 AM
To: UTTARO, JAMES ; Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
Subject: Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Hi Jim,

This is a general statement applicable to overall SD-WAN effort.

Cheers,
Jeff

From: "UTTARO, JAMES" mailto:ju1...@att.com>>
Date: Tuesday, July 10, 2018 at 05:22
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Ron Bonica mailto:rbon...@juniper.net>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, RTGWG 
mailto:rt...@ietf.org>>, Eric Rosen 
mailto:ero...@juniper.net>>, Robert Raszuk 
mailto:rob...@raszuk.net>>, Linda Dunbar 
mailto:linda.dun...@huawei.com>>
Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica mailto:rbon...@juniper.net>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; Linda Dunbar 
mailto:linda.dun...@huawei.com>>
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 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto: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 mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto: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 
mailto: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 
mailto: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 sit

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

Hi Jim,

 

This is a general statement applicable to overall SD-WAN effort.

 

Cheers,

Jeff

 

From: "UTTARO, JAMES" 
Date: Tuesday, July 10, 2018 at 05:22
To: Jeff Tantsura , Ron Bonica 
Cc: "bess@ietf.org" , RTGWG , Eric Rosen 
, Robert Raszuk , Linda Dunbar 

Subject: RE: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

 

Jeff,

 

Comments In-Line..

 

Thanks,

Jim Uttaro

 

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
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  wrote:

+1

 

Let’s follow up on this discussion in Montreal.

 

From: Linda Dunbar  
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura ; Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; 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 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org; Linda Dunbar 
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  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  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 ; Eric Rosen ; 
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  
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen ; Ron Bonica ; 
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 

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[UTTARO, JAMES]

Jeff,

Comments In-Line..

Thanks,
Jim Uttaro

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, July 06, 2018 8:16 PM
To: Ron Bonica 
Cc: bess@ietf.org; RTGWG ; Eric Rosen ; 
Robert Raszuk ; Linda Dunbar 
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 
mailto:rbon...@juniper.net>> wrote:
+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar mailto:linda.dun...@huawei.com>>
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto: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 mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto: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 
mailto: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 
mailto: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:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto: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 mailto:linda..dun...@huawei..com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto: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 inter

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

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  wrote:
> 
> +1
>  
> Let’s follow up on this discussion in Montreal.
>  
> From: Linda Dunbar  
> Sent: Friday, July 6, 2018 4:33 PM
> To: Jeff Tantsura ; Robert Raszuk 
> Cc: Ron Bonica ; RTGWG ; Eric Rosen 
> ; 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 
> Cc: Ron Bonica ; RTGWG ; Eric Rosen 
> ; bess@ietf.org; Linda Dunbar 
> 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  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  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 ; Eric Rosen ; 
> 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  
> Sent: Thursday, July 5, 2018 11:53 AM
> To: Eric Rosen ; Ron Bonica ; 
> 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 a

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Ron Bonica]

+1

Let’s follow up on this discussion in Montreal.

From: Linda Dunbar 
Sent: Friday, July 6, 2018 4:33 PM
To: Jeff Tantsura ; Robert Raszuk 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; 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 mailto:rob...@raszuk.net>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>; RTGWG 
mailto:rt...@ietf.org>>; Eric Rosen 
mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto:bess@ietf.org>; Linda Dunbar 
mailto: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 
mailto: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 
mailto: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:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto: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 mailto:linda..dun...@huawei.com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto: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:

•  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 
confiscate

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Linda Dunbar]

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 
Cc: Ron Bonica ; RTGWG ; Eric Rosen 
; bess@ietf.org; Linda Dunbar 
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 
mailto: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 
mailto: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:

[cid:image001..png@01D41536.30DC7AC0]

Do I explain well? If not, can we talk face to face in Montreal?

Thanks, Linda Dunbar

From: Ron Bonica [mailto:rbon...@juniper.net<mailto:rbon...@juniper.net>]
Sent: Friday, July 06, 2018 1:25 PM
To: Linda Dunbar mailto:linda.dun...@huawei.com>>; 
Eric Rosen mailto:ero...@juniper.net>>; 
bess@ietf.org<mailto: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 mailto:linda..dun...@huawei.com>>
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen mailto:ero...@juniper.net>>; Ron Bonica 
mailto:rbon...@juniper.net>>; 
bess@ietf.org<mailto: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:

•  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-2Dnet2clou

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Jeff Tantsura]

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  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  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 ; Eric Rosen ; 
>> 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  
>> Sent: Thursday, July 5, 2018 11:53 AM
>> To: Eric Rosen ; Ron Bonica ; 
>> 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

Re: [bess] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Ron Bonica]

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 
Sent: Thursday, July 5, 2018 11:53 AM
To: Eric Rosen ; Ron Bonica ; 
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] comments and suggestions to draft-rosen-bess-secure-l3vpn-01

[Linda Dunbar]

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