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

[Brian E Carpenter <[e-mail]>]

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