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 protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
