Hi Brian,
On Sun, Mar 9, 2014 at 6:08 PM, Brian Trammell <ietf@xxxxxxxxxxx> wrote:
On 09 Mar 2014, at 22:33, Alia Atlas <akatlas@xxxxxxxxx> wrote: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.
> 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, 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@xxxxxxxxxxxxx> 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.
>
>