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
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;
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
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
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
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
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:
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.
