Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[John Scudder <[e-mail]>]

Hi All,

I support adoption of this document.

Much of the discussion up to this point has focused on some variation of “we’ve already got one, it’s very nice”. And it’s true that we’ve already got more than one way to do source routing, so I think it’s reasonable to address why I think the WG should spend our time on yet another one.

First, it’s self-evident at this point that source routing is of interest. This has always been true to some extent of course, that’s why we had RH0, and before that IPv4’s LSRR. But it’s increasingly true now. 

Second, there appears to be no serious dispute that doing source routing with big ol’ 128-bit IPv6 addresses in the source route is problematic, at least for some deployments. 

So that brings us to the “we’ve already got one” part. It’s true that there are proposals for more-or-less compact source routes. In all cases I’m aware of these bring with them a considerable amount of additional architectural and deployment baggage (uSID, for example) and may also drag along some extra layers of cruft that were introduced for expedient deployment (SRoMPLSoUDPoIPv6, say). CRH, by contrast, seems to me to be a minimalist building block; it does one thing, it’s small enough to spec on a napkin (well not quite) and describe in a short, simple, slide deck. Possibly most important for this WG, it’s a from-the-ground-up IPv6 design. It fits comfortably and naturally into the IPv6 paradigm. To me, none of the other solutions quite do this. Is it a complete architecture for deploying a service? Nope, and that’s fine. Neither is IPv6 itself.

I don’t mean to turn this into a beauty contest, either, despite having mentioned certain examples above. You think your baby is beautiful? Stipulated, your baby is beautiful. But that doesn’t mean it should be the only baby the WG works on. Different tools for different problems.

In short I think IPv6 should have a native, natural, minimal, composable way of doing packet steering. This document is a good starting point. Let’s do it.

—John

P.S.: Yes, I expect to actively participate in the development and review of the document.