rade
commented
9 years ago IMO it is reasonable to limit ourself to data plane topology being a sub-graph of control plane topology. I cannot think of a realistic scenario where that would be inadequate.
In which case our current representation of topology is in fact sufficient; the 'established' flag on a connection indicates presence of udp connectivity.
Things that are missing / would need changing:
- presently we only include 'established' connections in topology communication. This would need to change, and we'd also need to include the flag itself.
- we need to consider the mere adding of a connection as a topology change, in addition to a connection getting marked as established (as happens currently).
- we need a different mechanism to deal with asymmetric udp connectivity than tearing down the entire connection (including tcp)
- gossip takes place over the control plane and therefore needs to calculate routes based on tcp connectivity, not the udp connectivity as happens now.
bboreham
At the moment (modulo #372 and #373), the tcp control plane topology and udp data plane topology are synchronised, except for transitory conditions; we can only have udp connectivity between peers if we have tcp connectivity and vice versa.
That is unnecessarily limiting. In particular, it rules out deployments where udp connectivity is somewhat more broken than tcp connectivity. This will become even more of an issue once we consider alternative data path implementations.