Re: [Spud] New Version Notification for draft-kuehlewind-spud-use-cases-00.txt

[Tom Herbert <[e-mail]>]

On Wed, Jul 8, 2015 at 1:07 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 7/8/2015 9:27 AM, Brian Trammell wrote:
>>> This is the appropriate
>>> > place for the policy/QoS information information described in the use
>>> > cases, and there are already facilities for both hop-by-hop options
>>> > and allowing middle boxes to modify options inflight.
>>
>> Indeed. This presumes that new IP options are more realistically
>> widely deployable in the Internet than a new protocol over UDP. I would
>> need to see some data to back that up (indeed, this would fit nicely in
>> a measurement study we're running right now so we may well end up
>> generating that data. :) )
>
> Check the discussions over in v6ops.
>
> There has been a lot of work there trying to deprecate all IPv6 options,
> which has at least been successful in limiting the length of the option
> chain.
>
Looking at the 6man documents, it seems like there is still an active
interest in IPv6 options. I know there is currently work being done on
implementing the segment routing option.

> One challenge is that IPv6 options are processed differently than IPv4 -
> there's no way to "jump" straight into the transport header to find
> ports (for port-based load balancing, e.g.).
>

The IPv6 label flow can be used to provide the entropy needed for ECMP
(like in RFC6438). With flow labels, devices would not need to do DPI
for purposes of ECMP. This solves the issue not only for devices that
don't want to parse over extension headers, but also allows flow-based
ECMP with protocols other than just UDP and TCP. Several vendors are
already providing support for flow labels and ECMP, and we intend to
start setting flow labels by default in end hosts (Linux at least).

Tom

> I suspect you'll find that IP options are basically a non-starter except
> for research purposes.
>
> Joe