Some basic notes below...
On 8/11/2016 1:57 AM, Patrick Frejborg wrote:
> Hi Joe,
>
> think we are on the same page - your experience regarding OAM with
> X-bone seems to match what I think on how it should be used in NVO3.
> And if that is the case, then we have a need of a control protocol
> between the VTEPs, here we can then add different extensions and keep
> the overlay streams free from becoming cumbersome to implement for the
> hardware architects/designers.
>
> Continuing to think out of the box, exploring if we could make the
> ECMP underlay network less cloudy for the VTEPs and provide some more
> visibility of the paths within the underlay network by this overlay
> tunnel control plane protocol (OTCP).
...
Again, my basic rule is "nothing in the overlay that can't be done in an
underlay".
So I ask: where are the tools by which you can derive this information
for ECMP in the current Internet? If you don't already have them, there
are only two options:
1) ask the underlay to export that info (which IMO isn't going to
happen)
2) start some research on how to accomplish this.
I don't see this as a WG task either way.
My personal view is that trying to optimize the way in which overlays
use paths in an underlay is a lot like optimizing how virtual memory
uses physical memory. That was a very active area of research in the
1970s when VM was becoming more prevalent, and the community eventually
gave up - realizing that virtualization has its own merits, and that
optimizing the underlying physical system can be nearly impossible,
e.g., when you run software VM in as a virtual machine inside another, etc.
We decided to avoid that issue in the X-Bone for that reason - we chose
to focus only on "empirically visible path properties", e.g.,
reordering, loss, bandwidth, latency, and jitter. Everything else is a
matter of intent - and we didn't care what was intended, only what ended
up happening.
> ...
>
> It seems that it would be a good idea to separate the streaming
> overlay tunnel encapsulation, optimized for hardware offloading, so
> the stream can stay in the data plane (NIC, ASICs), have several
> encapsulation schemes supported so we are not closing the innovation
> door for forthcoming encapsulation schemes either.
I agree. I don't see a benefit to requiring a single particular
encapsulation.
> OAM needs to be in
> the control plane of the VTEPs, should be generic for all
> encapsulation schemes, here we could also add extensions and have
> other VTEP control plane innovations supported.
I agree.
Joe
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
