Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Robert Raszuk]

Hi Linda,

There are some key differences: Skype and CDN overlay companies don’t have
> any intension to interoperate, but networking needs interoperability.
>

There is no issue about interoperability. Observe that that each endpoint
can today seamlessly be a member of N different SD-WAN orchestration
systems. In fact wise deployment requires that to provide sufficient
robustness on a per site SD-WAN VPN basis.

 Adding a new BGP SAFI is 1% of implementation burden of adding a new
> protocol.
>

Look ... BGP RRs got loaded with carrying dynamic IGP data. Now we are
facing to load it with IPSec data. Where does this end ?

IMHO IDR WG should evaluate each proposal for extension in the view of what
elements of BGP protocol given extension attempts to augment. If this is
solely for transporting opaque data such proposal should be either denied
or ensured by MUST that is has to run on different instance of real BGP
(just to accomodate your 1% code extension) as proposed
in draft-raszuk-mi-bgp-00


4. Registry of Data on AWS etc...
>
> [Linda] sure if AWS is interested in participating to make the needed
> changes. More work is needed to make AWS Data registry to communicate our
> existing BGP?
>

AWS or Azure or GCP should not play any role in that. Those would be purely
compute infra providers taking no responsibility for what data is being
exchanged there. Obviously some vendor neutral entitiy should operate it.
Likely some ICANN analogy on how DNS is being run today.

But as mentioned above for SD-WAN I really do not see a problem. Any open
or closed SD-WAN orchestration with just few clicks of the mouse can add or
delete sites and such sites can participate in more then one SD-WAN. In
fact paying few dollars per month per site allows you to outsource your WAN
networking costs for peanuts as well as benefit from a lot of non limited
custom features between SD-WAN providers.

Do we really want now to limit that innovation by putting them onto IETF
tracks (regardless of WG chosen to own this) ?

Thx,
R.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Linda Dunbar]

Robert:

Thank you very much for the feedback.
Responses to your suggestions are inserted below:

I have one comment to proposed encoding and one overall observation. *Comment: 
* Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type. 
Possible values are: NAT Type.without NAT; 1:1 static NAT; Full Cone; 
Restricted Cone; Port Restricted Cone; or Symmetric. You very nicely listed all 
nat types except one: "unknown" :) Why - Let's notice that in the other part of 
the text you state that information of the NAT type may be obtained from STUN 
server "can inquire". So if use of STUN server is optional then there is 
possibility that there is none and end point would not know about the NAT type 
it is traversing.
[Linda] thank you for the suggestion. We can add this option.

. *Observation: * This seems to be yet one more time we see proposal of "let's 
ride on BGP as we need to exchange endpoint discovery data point to point in a 
realiable way". I see zero need in this proposal why BGP is required here as 
opposed to any piece of code which can deliver data between two or more 
endpoints. Seeing those proposals it puzzles me a lot why skype or hangout are 
not using BGP ... after all video or voice call setup does require exchange of 
endpoint data.


[Linda] you’re absolutely right about those overlay applications completely 
by-passing IETF using their proprietary protocols for end points to propagate 
their properties. Yes, there are many ways to propagate end points properties. 
BGP is just one way. For us, BGP is an easier way because our product base 
already have BGP. Just like address scheme: If we can start with a clean slate, 
we can have much better address schemes than IPv4 (yet, it took >20 years for 
IPv6 development, still not wide deployment yet).
There are some key differences: Skype and CDN overlay companies don’t have any 
intension to interoperate, but networking needs interoperability.

 Likewise another unknown mystery is why SMTP is not riding on BGP too ? Yes 
overall we are missing now pretty much every day a global distributed system to 
exchange endpoint data in a dynamic way. Before we proceed on this or any other 
similar BGP extension I would highly appreciate some discussion on why below 
alternatives or other new similar proposals can be used instead of BGP for the 
described applications.


 1. LISP mapping plane
[Linda] we don’t want the baggage of implementing the associated LISP features. 
Adding a new BGP SAFI is 1% of implementation burden of adding a new protocol.
 2. Products of IDentity Enabled Networks WG
[Linda] SDWAN Tunnels needs more than Identity. It needs to distribute IPSEC SA 
attributes, it needs to advertise SD-WAN related information.   If using ID 
entity, more changes are needed than BGP SAFI
3. DynamicDNS
[Linda] yeh dynamic DNS can be modified to replace entire BGP as well. But it 
will require much more implementation work. Will take years to mature.
4. Registry of Data on AWS etc...
[Linda] sure if AWS is interested in participating to make the needed changes. 
More work is needed to make AWS Data registry to communicate our existing BGP?


Linda


From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Sunday, November 04, 2018 10:36 PM
To: Linda Dunbar 
Cc: i...@ietf.org; bess@ietf.org
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

Hi Linda,

I have one comment to proposed encoding and one overall observation.

Comment:

Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type. 
Possible values are:  NAT Type.without NAT; 1:1 static NAT; Full Cone; 
Restricted Cone; Port Restricted Cone; or Symmetric.

You very nicely listed all nat types except one: "unknown" :) Why - Let's 
notice that in the other part of the text you state that information of the NAT 
type may be obtained from STUN server "can inquire". So if use of STUN server 
is optional then there is possibility that there is none and end point would 
not know about the NAT type it is traversing.

Observation:

This seems to be yet one more time we see proposal of "let's ride on BGP as we 
need to exchange endpoint discovery data point to point in a realiable way". I 
see zero need in this proposal why BGP is required here as opposed to any piece 
of code which can deliver data between two or more endpoints.

Seeing those proposals it puzzles me a lot why skype or hangout are not using 
BGP ... after all video or voice call setup does require exchange of endpoint 
data. Likewise another unknown mystery is why SMTP is not riding on BGP too ?

Yes overall we are missing now pretty much every day a global distributed 
system to exchange endpoint data in a dynamic way.

Before we proceed on this or any other similar BGP extension I would highly 
appreciate some discussion on why below alternatives or other new similar 

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Robert Raszuk]

Hi Linda,

I have one comment to proposed encoding and one overall observation.

*Comment: *

Proposed "EncapsExt sub-TLV" defines as mandatory indication on NAT type.
Possible values are:  NAT Type.without NAT; 1:1 static NAT; Full Cone;
Restricted Cone; Port Restricted Cone; or Symmetric.

You very nicely listed all nat types except one: "unknown" :) Why - Let's
notice that in the other part of the text you state that information of the
NAT type may be obtained from STUN server "can inquire". So if use of STUN
server is optional then there is possibility that there is none and end
point would not know about the NAT type it is traversing.

*Observation: *

This seems to be yet one more time we see proposal of "let's ride on BGP as
we need to exchange endpoint discovery data point to point in a realiable
way". I see zero need in this proposal why BGP is required here as opposed
to any piece of code which can deliver data between two or more endpoints.

Seeing those proposals it puzzles me a lot why skype or hangout are not
using BGP ... after all video or voice call setup does require exchange of
endpoint data. Likewise another unknown mystery is why SMTP is not riding
on BGP too ?

Yes overall we are missing now pretty much every day a global distributed
system to exchange endpoint data in a dynamic way.

Before we proceed on this or any other similar BGP extension I would highly
appreciate some discussion on why below alternatives or other new similar
proposals can be used instead of BGP for the described applications.

1. LISP mapping plane
2. Products of IDentity Enabled Networks WG
3. DynamicDNS
4. Registry of Data on AWS
etc...

Thx,
Robert.


On Tue, Oct 30, 2018 at 5:19 PM Linda Dunbar 
wrote:

> IDR group, BESS group,
>
>
>
> https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/
> specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s
> capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes
> through third party untrusted networks.
>
>
>
> draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes
> to exchange key and policy to create private pair-wise IPsec Security
> Associations without IKEv2 point-to-point signaling or any other direct
> peer-to-peer session establishment messages.
>
>
>
> I think those two solutions are not conflicting with each other. Actually
> they are compliment to each other to some degree. For example,
>
> -the Re-key mechanism described by
> draft-sajassi-bess-secure-evpn-00 can be utilized by
> draft-dunbar-idr-bgp-sdwan-overlay-ext
>
> -The SD-WAN Overlay SAFI can be useful to simplify the process on
> RR to re-distribute the Tunnel End properties to authorized peers.
>
> -When SD-WAN edge nodes use private address, or no IP address,
> NAT properties for the end points distribution described
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
>
> -The secure channel between SD-WAN edge nodes and RR described by
> draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
>
>
>
> Any thoughts?
>
>
>
> Thank you very much.
>
>
>
> 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

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Ali Sajassi (sajassi)]

Linda,

You should read my draft again as it explains IPsec tunnels needed at different 
level of granularity and how this can be achieved with existing routes. The 
traffic does not get sent till the IPsec tunnel is established between a pair 
of endpoints and the draft specifies 6 different types of endpoints for 
different level of granularity – i.e., per PE, per tenant, per subnet, per IP, 
per MAC, and per AC.

Cheers,
Ali

From: Linda Dunbar 
Date: Sunday, November 4, 2018 at 7:00 AM
To: Cisco Employee , "i...@ietf.org" , 
"bess@ietf.org" 
Subject: RE: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

Ali,

Your draft-sajassi-bess-secure-evpn-00 defines two new Tunnel Types along with 
its associated sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP].

[Tunnel-Encap] cannot be effectively used for SD-WAN overlay network because a 
SD-WAN Tunnel needs to be established before data arrival. There is no routes 
to be associated with the SD-WAN Tunnel.

How do you address those issues?

Linda

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, October 31, 2018 12:04 PM
To: Linda Dunbar ; i...@ietf.org; bess@ietf.org
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

Hi Linda,

I haven’t read your draft yet. I am traveling now but will plan to read your 
draft over next couple of days and respond to your questions.

Cheers,
Ali

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Linda Dunbar mailto:linda.dun...@huawei.com>>
Date: Tuesday, October 30, 2018 at 9:19 AM
To: "i...@ietf.org" 
mailto:i...@ietf.org>>, "bess@ietf.org" 
mailto:bess@ietf.org>>
Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages.

I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example,

  *   the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 can 
be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext
  *   The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers.
  *   When SD-WAN edge nodes use private address, or no IP address, NAT 
properties for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
  *   The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Ali Sajassi (sajassi)]

Just finished reading your draft and I don’t think the two drafts are 
complimentary. Frankly, I don’t see any advantages for using a separate SAFI 
for this purpose but many disadvantages such as:


  1.  Resurrecting the approach in RFC 5512 that is being deprecated – i.e., 
send a separate route for the tunnel and then color the other routes to 
associated with the tunnel (using indirection) and opposed the current common 
practice in Tunnel Encap attribute that sends the attribute directly with the 
corresponding route.
  2.  When establishing IPsec tunnel at a more granular level (e.g., per pair 
of VPN MAC or IP addresses), you need to advertise twice as many routes !!
  3.  The overhead associated with a new SAFI as opposed to use exiting 
attribute
  4.  NAT can be handled without the new SAFI

The secure tunnel between each PE and the RR (e.g., IPsec) for the BGP session 
is common between the two drafts as mentioned first by the controller-ike 
draft. This is needed because you want to make sure that the BGP session goes 
over a tunnel that is authenticated between the peers (and encrypted). 
Intuitively the use of tunnel encap attribute for IPsec should be clear as 
IPsec is another tunnel type and key exchange parameter, transfer function, DH 
groups, etc. are attributes/properties of such tunnel and thus to be advertised 
in this new tunnel type TLV.

Let’s start with EVPN because that is the technology/solution being used 
predominately in DCs, DCIs, and enterprise inter-site connectivity. I listed 
the disadvantages of using a separate SAFI above, can you list the advantages 
of using a separate SAFI for EVPN?

Cheers,
Ali

From: BESS  on behalf of Linda Dunbar 

Date: Tuesday, October 30, 2018 at 9:19 AM
To: "i...@ietf.org" , "bess@ietf.org" 
Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages.

I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example,

  *   the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 can 
be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext
  *   The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers.
  *   When SD-WAN edge nodes use private address, or no IP address, NAT 
properties for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
  *   The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Linda Dunbar]

Ali,

Your draft-sajassi-bess-secure-evpn-00 defines two new Tunnel Types along with 
its associated sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP].

[Tunnel-Encap] cannot be effectively used for SD-WAN overlay network because a 
SD-WAN Tunnel needs to be established before data arrival. There is no routes 
to be associated with the SD-WAN Tunnel.

How do you address those issues?

Linda

From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com]
Sent: Wednesday, October 31, 2018 12:04 PM
To: Linda Dunbar ; i...@ietf.org; bess@ietf.org
Subject: Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

Hi Linda,

I haven’t read your draft yet. I am traveling now but will plan to read your 
draft over next couple of days and respond to your questions.

Cheers,
Ali

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Linda Dunbar mailto:linda.dun...@huawei.com>>
Date: Tuesday, October 30, 2018 at 9:19 AM
To: "i...@ietf.org" 
mailto:i...@ietf.org>>, "bess@ietf.org" 
mailto:bess@ietf.org>>
Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages.

I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example,
-the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 
can be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext
-The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers.
-When SD-WAN edge nodes use private address, or no IP address, NAT 
properties for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
-The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Ali Sajassi (sajassi)]

Hi Linda,

I haven’t read your draft yet. I am traveling now but will plan to read your 
draft over next couple of days and respond to your questions.

Cheers,
Ali

From: BESS  on behalf of Linda Dunbar 

Date: Tuesday, October 30, 2018 at 9:19 AM
To: "i...@ietf.org" , "bess@ietf.org" 
Subject: [bess] Comparing using the SD-WAN Overlay SAFI specified by 
draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by 
draft-sajassi-bess-secure-evpn-00

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages.

I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example,

  *   the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 can 
be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext
  *   The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers.
  *   When SD-WAN edge nodes use private address, or no IP address, NAT 
properties for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.
  *   The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Comparing using the SD-WAN Overlay SAFI specified by draft-dunbar-idr-bgp-sdwan-overlay-ext with the EVPN approach described by draft-sajassi-bess-secure-evpn-00

[Linda Dunbar]

IDR group, BESS group,

https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ 
specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node's 
capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes 
through third party untrusted networks.

draft-sajassi-bess-secure-evpn-00 describes an EVPN solution for PE nodes to 
exchange key and policy to create private pair-wise IPsec Security Associations 
without IKEv2 point-to-point signaling or any other direct peer-to-peer session 
establishment messages.

I think those two solutions are not conflicting with each other. Actually they 
are compliment to each other to some degree. For example,

-the Re-key mechanism described by draft-sajassi-bess-secure-evpn-00 
can be utilized by draft-dunbar-idr-bgp-sdwan-overlay-ext

-The SD-WAN Overlay SAFI can be useful to simplify the process on RR to 
re-distribute the Tunnel End properties to authorized peers.

-When SD-WAN edge nodes use private address, or no IP address, NAT 
properties for the end points distribution described 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

-The secure channel between SD-WAN edge nodes and RR described by 
draft-dunbar-idr-bgp-sdwan-overlay-ext is necessary.

Any thoughts?

Thank you very much.

Linda Dunbar
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess