Whoa! Will indeed have a look on URL you posted, thanks! RTP is perhaps the wrong reference, I should have referred the different overlay tunnels as NVO3 "codecs", the payload inside the RTP, the audio/video profile identifier. Then these overlay tunnel protocols can evolve, as the DSPs evolved/evolving in the communication systems. What do we gain here then? - no forklift of the whole network when a new NVO3 "codec" is introduced - use the best "codec" for your VTEP tunnel adjacencies, e.g. between computer nodes GUE, Geneve whatever provides the best performance in that version of the hypervisor/NIC combination. If you are connected to the "PSTN" and your external network is based on MPLS, then go for MPLS over UDP or your external network is LISP capable then go for VXLAN - these gateways will most likely do their NVO3 encaps in hardware. Hopefully one day, the hypervisors would support MPLS (two labels) and the OCP can setup the LSP between the hypervisor and underlay network without running LDP between the hypervisor and underlay network. With that we could avoid the "transcoding" scenarios described in this draft, e.g. VXLAN-MPLS-VXLAN https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-03 And having different extension versions to get translated between those different NVO3 "codecs" will create some hurdles with upgrades, most likely :-).
Thus I think it would be better to keep the different NVO3 codecs as simple as possible, optimized for the NVO3 "DSPs", and have then the NVO3 extensions in a common sister protocol, which can evolve in its own pace; those extensions shouldn't need hardware support anyway. That will depend on the OCP of course, but if there is some feature that is broken in the OCP and would require extension on every packet (and hence changes to the NVO3 "DSP"), but there are other OCPs that can get around this - should we allow that then, choose a single OTP that gets us into hardware dependencies on the NVO3 "DSP" design and requires a forklift upgrades every time a new version is released? I don't know if this kind of scenario is possible with the three tunnel proposals, this is a hypothetical question without any research behind - but I am worried that we are only focusing on the overlay tunnels and not questioning what should go to via the overlay controller protocol, how can we have several version of hardware supported overlay tunnels, how can these evolve and should we then decouple the VTEP control messages from the hardware dependencies and those control messages should be able to support several overlay tunnel protocols? The difference between SIP messages and RTCP is that SIP messages between a SIP UA and a SIP proxy/registrar do take a different path in the network what the RTP messages are using - the SIP messages are off the data path (the signalling path) and the RTCP messages are on the data path. Regards, Patrick _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
