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