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 <linda.dun...@huawei.com> 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 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 <linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> 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<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
