On 8/9/2016 11:19 PM, Patrick Frejborg wrote: > Hi Joe, > > I should have used Overlay Controller Schemes instead of OCP, all > current overlay solution do have some "signalling" mechanisms to setup > and tear down the tunnels, a bunch of protocols. Probably you could > make extensions to SIP as well and have that as an Overlay Controller > Scheme (OCS), that would be on standards tracks. > > You are right about RTCP, it is not in the data path/inside the stream > - it is between endpoints and de facto in the data path, otherwise it > would be useless collecting statistics for the codec to detect > transmissions faults and jitter etc. > > Why not do the similar for NVO3, design OTCP so that the OAM is active > on all ECMP paths between two VTEPs though there is only one active > end system stream between the VTEPs. ... RTCP needs a new separate mechanism because teleconferencing needs different measurements than would typically be gathered to run a net.
Overlays don't. Why not just run whatever measurement/monitoring that could run in the underlay? If you do have a need for a different mechanism, you need to decide how much is specific to what makes an overlay different and whether that belongs in the controller level or within individual tunnels (who would run automatically and be monitored as an entity). Finally, based on the design of our control protocol in X-Bone, I don''t think using SIP as anything but general inspiration is useful here. Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
