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

Thanks. I think we should get some useful discussion over there.

Regards
   Brian

On 20/10/2017 05:53, Lin Han wrote:
> Hi, Brain
> 
> I have forwarded the draft to TSVWG for further discussion and review.
> 
> Thanks
> 
> Lin
> 
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Tuesday, October 17, 2017 12:58 PM
> To: Toerless Eckert <tte@cs.fau.de>; Tom Herbert <tom@herbertland.com>
> Cc: 6man WG <ipv6@ietf.org>
> Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt
> 
> 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
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
> 