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

[Joe Touch <[e-mail]>]

On 7/9/2015 2:04 PM, Tom Herbert wrote:
> 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.

Yes - that's one of my concerns with the rush to deprecate them ;-)

>> 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. 

While I agree with your logic, the other issue is that the flow labels
aren't set properly AND existing ops is based on port-directed forwarding.

I'm not suggesting I agree with this; IMO, anything that digs into a
packet deep enough to find the transport header is acting like an
endpoint and ought to expect to do the work needed to find that header.

Joe