Re: Across the Internet [was Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)]

[Robert Raszuk <[e-mail]>]

Hi Brian,

> For example, your comment recently about how many bytes of the packet
> header are within reach of the hardware protocol engine. Are you saying
> we should design much larger headers regardless of that limitation?

We should be realistic. It is wise to enforce progressing the protocol
extension
only where there is implementation proving it. And that should be
sufficient criteria
of course assuming that the proposal is wise.

So while I am not advocating XXL headers ... but even if someone comes with
brilliant
idea to have XXL header, but also in the same time documents and proves
that any
transit node in the end to end path needs to only read first N bytes of
such header
to claim full support of it I see no problem to standardize it.

Just look at proposals which dynamically grow test packets at every node
and do
require very flexible data planes to add a lot of forwarding and control
information
on the fly at line rate during packet's forwarding depending on operator's
or such
packet src included set of required fields.

Example: https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-00

Would that be included in the base line you are referring to ?  Clearly
very useful
for my end to end Internet wide v6 transit ! Even more attractive if those
probes
would be SRv6 enabled Internet wide.

//R.


On Sat, Apr 22, 2017 at 10:47 PM, Brian E Carpenter <
[e-mail]> wrote:

> Robert,
>
> I think we're well off the main topic by now...
> On 22/04/2017 19:28, Robert Raszuk wrote:
> > Hi Brian,
> >
> > In every other email I see a concern about "Internet" or "Internet-wide"
> > behavior.
> >
> > To me Internet is a collection of *independent* chain of Autonomous
> > Systems. As name indicates those domains are **autonomous** and can do
> > whatever they like to do with packets they carry. If they do not choose
> to
> > do right things customers will avoid them, there will be no revenue and
> > they will disappear from Internet map. Pure and simple.
>
> The trouble is, that doesn't work for second-order effects like dropping
> unknown IPv6 extension headers, IPv4 options or ICMP packets. The network
> learns to avoid those features, rather than avoiding certain paths.
>
> > I find it very bizarre that IETF is trying to be a judge or policer to
> > dictate on what each AS can or can not do in their own network.
>
> We're not. We're simply saying PIPO (packet in = packet out), except for
> any fields that are *explicitly* designed to change.
>
> > Moreover it
> > also apparently is putting least common denominator rule which states
> that
> > all 50000 ASes should do MUST only be limited to what the weakest AS can
> do
> > with either old or incapable vendors to support innovation.
>
> Yes, transmitting IP datagrams from source to destination is indeed the
> lowest
> common denominator that the Internet requires. And that sets a limit on the
> external behaviour of every AS.
>
> > I was apparently very wrong assuming for all those years that IETF focus
> is
> > to make sure that protocol extensions we define are as best as we are
> > collectively able to do .. rather then community to worry what hardware
> > vendors will manage to support or not support in what we define.
>
> I'm not sure I take your point. There's always been a tension between ideal
> notions of protocol design and the capability of actual hardware. For
> example, your comment recently about how many bytes of the packet header
> are within reach of the hardware protocol engine. Are you saying we should
> design much larger headers regardless of that limitation?
>
> > So what will happen ... we will either have waves of proprietary features
> > which will be hard to interoperate even within single AS or that
> definition
> > of such things will take a spin outside of IETF via various forums,
> > consortium, foundations etc ... Do we really all here endorse such
> > direction ?
>
> No. The third way: set a base line for the lowest common denominator and
> then extend from there. That is what we're trying to do here.
>
> Regards
>     Brian
>
> >
> > Have a great weekend,
> > Robert.
> >
> >
> >
> > On Sat, Apr 22, 2017 at 1:34 AM, Brian E Carpenter <
> > [e-mail]> wrote:
> >
> >> On 22/04/2017 08:09, Robert Raszuk wrote:
> >>> ​Hi Ole,​
> >>>
> >>>
> >>>> That does in no way stop anyone from proposing _new_ work. Of any
> sort.
> >>>>
> >>>> Best regards,
> >>>> Ole
> >>>>
> >>>
> >>> ​Very true ! Anyone can propose anything in IETF.
> >>>
> >>> But with the text additions which I have seen here recently the bar to
> >> move
> >>> from individual's draft proposal to WG doc then via all LCs to
> Standards
> >>> Track RFC just went up significantly higher especially for SRH and EH
> >>> elements. ​
> >>>
> >>> And that's my point.
> >>
> >> But *our* point, for some definition of 'our', is that by making the
> >> Internet-wide situation clear, we are in fact clearing the way for
> careful
> >> definition of local-use mechanisms. At the moment, as we've clearly seen
> >> from discussion of the SRH, we simply can't have that discussion because
> >> of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicker
> >> we get that settled and approved by the IESG, the quicker we can look
> >> seriously at draft-voyer-6man-extension-header-insertion.
> >>
> >> You might ask yourself why no IPv4 options have been defined since 2007
> >> (Quick Start) and before that, 1997 (Router Alert). The same reason:
> they
> >> don't survive a trip across the Internet.
> >>
> >>     Brian
> >>
> >>
> >
>
>