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

From: Robert Raszuk <[email-masked]>
Date: Sun, 4 Nov 2018 16:35:47 +0100

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 <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 5 Nov 2018 06:23:12 +0000

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:[email-masked]]
Sent: Sunday, November 04, 2018 10:36 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
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,

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

Thx,
Robert.

On Tue, Oct 30, 2018 at 5:19 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 5 Nov 2018 19:04:27 +0100

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

>
> [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.