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

[Toerless Eckert <[e-mail]>]

On Wed, Oct 18, 2017 at 08:57:35AM +1300, Brian E Carpenter wrote:
> > 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.

It does not analyze the fact that the existing hop-by-hop option (and options
carried via it like router alert) are burned because existing router imple entations
punt packets with hop-by-hop options even though they do ultimately not
need to process the packets (hop by hop option they don't do or router-alert
protocol they don't do). 

And IMHO the existing hop-by-hop option is burned because the architecture
RFCs did not well enough express in MUST statements that you must never
speed down packets because of hop-by-hop/router-alert unless you really know
you will support/do-something with that option. And that you achieve this eg.:
by filtering/punting based on option/protocol. And that you can NOT do anything else.

This is also the root cause why in our analysis a hacky extraction by
eg: STUN signature inside UDP is a lot safer for existing networks than relying
on any hop-by-hop option. Badly standardized, badly implemented.

> As Ole said - within a domain where hop-by-hop option X is
> supported, you can reasonably expect that all routers process X.

Ask an enterprise operator with 10 different router models from 3 vendors ;-)

Cheers
    Toerless

> 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
> >> --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]