ietf
[Top] [All Lists]

Re: Overlays and encapsulations (was Re: Engineering discussions )

2014-03-09 17:32:54
Hi Brian,

On Sun, Mar 9, 2014 at 6:08 PM, Brian Trammell <ietf(_at_)trammell(_dot_)ch> 
wrote:

On 09 Mar 2014, at 22:33, Alia Atlas <akatlas(_at_)gmail(_dot_)com> wrote:

In the last few years, there seems to be a drive towards overlays and
additional
packet encapsulations.  What problems do you see these as solving?  Is
there a
more focused way to consider the drivers and downsides?

Thoughts?

Oh. Could we have an easier one to start with? Especially on the Sunday
after an IETF? Because my response to this one right now would be to say
lots of terribly unkind things about dodgy middleboxes, which is not a very
balanced approach to the issue and unlikely to be very helpful in steering
the list toward more productive conversation. But let me try.


Oh, but this is exactly the type of Sunday-after-IETF discussion when one
can think about big picture wide-ranging ideas without needing to think
about the practical implications for a while!

So - to your point about middleboxes (minus the unkind things), would it be
fair to say:
   a) middleboxes serve to restrict what kind of traffic is perceived to
flow freely to TCP/UDP?
   b) middleboxes impact security by acting as an unknown MITM

we also need to add:
   In most modern networks, it is important to have microflow diversity.
 When IPv6 and flow-labels aren't an option, this frequently defaults to
UDP or TCP 5-tuples (src/dest IP, protocol, src/dest port)

For instance, how many issues would be solved if there were a well-known
meta-data header that an application could use to describe itself to the
network and middle boxes?

It's hard to say anything in general about what "overlay x on y" solves in
detail (I'll consider encapsulation an implementation detail of overlay for
now) for all x and y, other than (1) somebody thought that it would provide
a service that y doesn't on its own that (2) they locally thought they
needed at the time, and (3) they might actually have been right about (1)
and (2).


Ah - I don't think that encapsulation is an implementation detail of
overlay.   But I'm willing to be persuaded - I think it is more about
carrying additional information; frequently that is done as an overlay
because it isn't possible to carry it otherwise.


The upside is that overlaying allows us to use the abstractions from the
higher layer of the overlay when all we have is the lower layer.

The downside is that x over y might not really be the same as x, because
you miss some assumption inherent in either x or y about the corresponding
y or x, and you end up breaking something end-to-end. This gets more
complicated when years later, after all the bugs are worked out, somebody
notices the shiny new x and decides to overlay z on top of it.


Are you thinking of this as something more than foo over IP or over MPLS?
 I, of course, tend to think of it at that level and find it interesting to
learn whether similar issues are appearing at other layers?



I don't see a more focused way to consider this at this (ridiculously
high) level of abstraction. A good general considering-the-downsides
question might be "how well can I run NNTP, SSH, DNS, World of Warcraft,
BitTorrent, Windows file sharing, and WebRTC over it at the same time in an
airplane at rush hour on Mars next to my microwave while randomly
unplugging stuff?"


Hmm, I was thinking more of things like MTU, implications on increased DPI,
etc.



Admittedly this is a rather higher-layer viewpoint. On preview, I suspect
you might get a more useful (and more concrete) thread out of Eric's
response.


The point of a general discussion is to get perspectives other than just
those who play at the same layer.  That said, of course, Eric is very
familiar with some of the drivers behind NVO3.

Regards,
Alia



Cheers,

Brian

On Sun, Mar 9, 2014 at 5:29 PM, heasley <heas(_at_)shrubbery(_dot_)net> 
wrote:
Sun, Mar 09, 2014 at 11:10:27AM +0000, Dave Crocker:
The phrasing of your suggestion presumes that you are currently
prevented from having those discussions.  But of course you aren't.

I believe the point is to separate general technical discussion from the
general everything else discussion, such as the draft-how-not-to-be-a-
wanker discussion, so that those here just for the technical aspects of
IETF need not wade through it.  Which I support.