Hi Joe, I have not stated that we should use RTCP/SIP as such, as you said "using SIP as anything but general inspiration is useful here" is totally correct. The VTEPs will more and more be deployed inside hypervisors, hence running only this RTCP stylish monitoring protocol (or other underlay monitoring solutions) only inside the underlay is not good enough - it has to be deployed between VTEPs. If you integrate that inside overlay tunnels and there are a lot of tunnels between the VTEPs, then you most likely have a lot of OAMs going between the VTEPs, doing the duplicate job for the same path because they are integrated into the streams. That OAM has to be managed by the VTEPs - I have no idea how much that will burden the VTEP's resources. Would it be more resource efficient to figure out a mechanism so that you can setup OAM sessions between the hypervisor VTEPs, covering all possibly ECMP paths through the underlay and no more, regardless of how many overlay tunnels exists between the VTEPs? And if that can be done, then you could add mandatory and optional TLVs for other functions that can not be handled by the overlay controller to be sent between the VTEPs - all this shouldn't interfere hardware offloading for the end system streams between the VTEPs.
Regards, Patrick On Wed, Aug 10, 2016 at 6:15 PM, Joe Touch <[email protected]> wrote: > > > 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
