I am quite interested in the notion of integrating IKE (or IKE-like) security and functionality into the SD-WAN controller messaging. My company does this now, though not in a standard way. All IPSEC key management comes from the SD-WAN controller. It is tricky to do this right, but it can be done and will continue to be done. It can be highly scalable. I'd like to see us work on doing this in a standard way and I'm happy to help out.
Several concerns were raised in the meeting, and unfortunately there wasn't time for all comments then. While I think the concerns raised are good concerns, I also believe they are demonstrably addressable. Yes, this needs to be done carefully!! Additionally to Yoav's point, yes there is additional information that SD-WAN controllers need to send. Some of this will be proprietary. Yet much of it will become standard over time. I don't think we can enumerate all of this now or even soon. It seems there are efforts underway to do this. But we can start with a flexible way to add this incrementally over time. Dave On Thu, Jul 21, 2016 at 6:33 PM, Yoav Nir <[email protected]> wrote: > Hi > > In addition to what we said at the meeting, I’d like to mention that what > the draft is proposing seems to be a subset of what SD-WAN vendors are > doing. I apologize in advance for using the terms NSF and SD-WAN gateway > interchangeably. > > For those not familiar, Wikipedia has a so-so article about it: > https://en.wikipedia.org/wiki/SD-WAN > > In an SD-WAN setup, the security function is configured by the SD-WAN > controller to have one or more virtual links for particular target > networks. As an example, the NSF might have three ways of getting to > subnet 192.0.2.0/24 > : > > 1. Using an MPLS link. This is the most expensive way > 2. Using the Internet through an LTE modem. This is moderately > expensive as well. > 3. Using the Internet through a DSL link. This is the cheapest way. If > at all possible, you would want to use this. > > > An SD-WAN gateway uses some measurement technique to evaluate some > properties of each one of these physical links: RTT, jitter, packet loss. > > The SD-WAN gateway receives policy from the controller. Such a policy may > require that VoIP traffic go over the cheapest link where RTT is no more > than 50ms and jitter is no more than 50ms. Video traffic might be more > stringent on jitter but less stringent on RTT. Web transactions are fine > with any RTT and jitter as long as packet loss is small. There’s more to it > and you can find more with a Google search and at the vendors’ websites. > One part is dynamic discovery of peers for large environments. > > Most of SDN started in academia and migrated to the “real world”. In this > particular case it seems that private industry is somewhat ahead. I don’t > think we’d want to standardize a partial solution here. It’s probably > better for us to try to get all of the functions that people expect under > the buzzword “SD-WAN”. > > I’m not sure either whether this is work for this working group or whether > it justifies its own working group. I’m also not sure how we can attract > the SD-WAN vendors to the IETF to participate. But I think we should be > “thinking big” on this. > > Yoav > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
