Re: Confirm consensus to adopt draft-hinden-6man-mtu-option

[Tom Herbert <[e-mail]>]

On Thu, Aug 1, 2019 at 5:23 PM Nick Hilliard <[e-mail]> wrote:
>
> Tom,
>
> just to follow up on a couple of your points:
>
> Tom Herbert wrote on 01/08/2019 22:21:
> > -  PMTU HBH is not the only use case of EH that is being proposed,
> > there are actually several and some of which are being proposed by the
> > router vendors themselves (e.g. IOAM, APN6, SRv6, SRv6+). Segement
> > routing is particularly interesting given the amount of investment and
> > effort being exerted make it happen-- I believe that we will see
> > significant deployment of that. SRv6 is at least an order of magnitude
> > more complex than something like the PMTUD option, so if SR is
> > feasible then PMTUD (IOAM and the rest) are feasible.
>
> I agree that if SRv6 takes off, it could possibly push better support
> for EHs in ipv6.
>
> > - There is a strong trend in the industry towards programmble devices
> > with P4 (routers), eBPF (hosts, SmartNICs), etc. This faciliates fast
> > development and bug fix turn around compared to fixed function ASIC
> > solutions.
> > - The complexity of the "fast path" has grown by several orders of
> > magnitudes. Routers, especially those on the edge, commonly perform
> > DPI, connection tracking, ACLs, etc. For the complexity to process EH
> > is incremental to existing complexity, and in fact may reduce
> > complexity in long (e.g. EH may obviate need for DPI in some cases).
>
> IPv6 was defined in an era when software forwarding was mostly handled
> on generic CPUs, i.e. there was plenty of scope even at the time for
> writing code to perform arbitrary packet mangling operations.  We may
> have more complexity now, but it would have been arguably easier to
> program that complexity in forwarding engines of the 1990s because they
> were generally CPU based rather than today's mix of CPU forwarding, NPU
> based routers, programmable ASICs and simplistic ASICs.
>
> The issue here is that everything has a cost - nothing is free. The
> costs associated with EHs are what have caused them not to be supported
> properly over the last 20 years. Even the requirement to support v6
> frags wasn't enough to overcome the historical reticence to implement
> proper EH support in many cases.  Looking at this from a pseudo-economic
> model, the cost drivers haven't changed much, so it's hard to see how
> the outcome is going to be much different in years to come.
>
Nick,

>From a macro viewpoint of the Internet that is true to some degree,
but unlike twenty years ago we now have huge providers and data center
operators that have significant leverage with vendors to support
features they find useful, and they are starting to run IPv6. These
are where the first serious deployment of EH will occur. Providers
like this don't necessarily need ubiquitous support for EH across all
possible vendors, just the ones they deploy. So assuming such
deployment happens then it becomes a competitive disadvantage not
support EH so the economic motivations are resolved. I do believe that
both segment routing and IOAM will be sufficiently compelling to
operators and providers so that it's pretty likely this will play out.

Making EH ubiquitous over the Internet is still relevant and a little
more challenging. Since there's no controlling entity, we have to deal
with incremental adoption and do things like "happy eyeballs" for EH.
In reality though, there's nothing special about EH in this regard,
there's a lot of protocols we might want to use over the Internet that
might not work consistently (e.g. SCTP, DCCP, but even QUIC and IPv6
still don't have ubiquitous support).

Tom

> Nick