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

[Toerless Eckert <[e-mail]>]

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

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

-- 
---
[e-mail]