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

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