Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

[Brian E Carpenter <[e-mail]>]

On 18/10/2017 07:16, Toerless Eckert wrote:
> As mentioned in my prior mail: RSVP-IP deployments got killed by SPs that filtered
> packets with router-alert because common network devices punted packets because of
> the presence of router-alert. 

Router alert in IPv6 *is* a hop-by-hop option [RFC2711], so the
code path for this proposal starts exactly the same as the code
path for processing an RSVP message.

> Instead of punting them because of presence of
> RSVP-router-alert option. And of course you can blame IP multicast: every router
> started to punt router-alert because of MLD (and of course us multicast folks
> missed the chance to fix this in MLDv2 because it only tried to duplicate IGMPv3),
> but no RFC told developers to punt because of router-alert + value in the router alert.
> AFAIK, the same applies to hop-by-hop option in general. Alas, even rfc7045 did not discuss
> this issue.
> 
> IMHO we need a mechanism that specifies: devices MUST NOT punt/slow down packets
> because of the presence of this mechanism, but only because of presence of
> (mechanism,value) where value is intended to be supported by device. If the device
> can not do this, then it MUST IGNORE this mechanism and forward packets with the mechanism
> as if the option was not present.

That's pretty much what RFC7045/RC8200 say, except that they
say it as a warning.

As Ole said - within a domain where hop-by-hop option X is
supported, you can reasonably expect that all routers process X.
But (excuse me repeating myself), whether X is worth doing is not
really a question for 6man. In this case, it belongs where QoS is
discussed, which is TSVWG.

    Brian

> One simple way to do this is to define hop-by-hop-fixed that does say exactly this
> and then hopefully allow all existing hop-by-hop TLV to live underneath that
> fixed hop-by-hop-fixed option. But i would certainly suggest to review processing
> complexity and extensibility before such a conclusion.
> 
> Personally i prefer inband UDP layer signaling, not because i do not like IPv6
> option headers but because there is just no ubiquitous API to allow apps
> independent of OS enhancements to set arbitrary options headers, especially ones
> that are not yet defined (allow apps to fully defined the whole header bit by bit).
> Lets say from a javascript app in a browser. And i am more interested in ease of
> adoption than in architectural cleanlyness. But of course its perfectly valid to
> do the architectural clean appraoch and then prove me wrong and get that option
> adopted more ;-))
> 
> Cheers
>     Toerless
> 
> On Tue, Oct 17, 2017 at 09:54:52AM -0700, Tom Herbert wrote:
>> On one hand, IETF defined extension headers as the extensibility
>> mechanism of IPv6, but yet on the other hand the message seems to be
>> to not use them because deployed devices don't correctly support the
>> protocol. The upshot is that we see proposals in other WGs of stuffing
>> network layer information into transport protocols (options or
>> payloads) with the full expectation that intermediate nodes will parse
>> into the transport layer, process the embedded information, and
>> possibly even overwrite transport layer information. IMO that is an
>> architectural abomination and further abandonment of the end to end
>> model!
>>
>>> While the 6man working group can certainly help the authors with those considerations, I believe the work would have to be owned somewhere else.
>>> And it might be a little too early to go into the details of packet formats etc.
>>>
>> Agreed, but I do think the 6man working group has a vested interest to
>> make sure that network layer information stays in the network layer.
>> At some point the information needed is going to be so complex that it
>> won't be able to be conveyed in any fields of the IP header.
>>
>> Tom
>>
>>> Best regards,
>>> Ole
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>