On Wed, Sep 12, 2018 at 7:42 PM, Brian E Carpenter
<brian.e.carpen...@gmail.com> wrote:
> Just picking on one part of Tom's excellent note:
>
> On 2018-09-13 11:14, Tom Herbert wrote:
> ...
>> IMO, IETF's strength and advantage is that it focuses on standardizing
>> protocols without standardizing network architecture. This provides
>> all the necessary freedom for to build networks as appropriate and
>> encourage innovation on many fronts. For the most part this model
>> seems to haved worked well.
>
> Well, I think we have counter-examples. PMTUD failure for one. Opaqueness
> of the Internet to new IPv6 extension headers for another. The strong
> desire from some operators to deploy locally-significant extensions
> in a standardized way for another.

Okay, some operators want such things. However, the specifics of what
they're requesting are pertinent as to whether these should be
undertaken in IETF. In particular, each request should be evaluated
against the "necessary and sufficient" test. It might be good to
discuss in some detail a few specific locally-significant extensions
in the draft, particularly those that fall into the category of "not
correct" when used on the Internet.

I will give one example. The draft mentions extension header insertion
(I-D.voyer-6man-extension-header-insertion). Some operators want it as
unabashedly indicated by the first line of the abstract in that draft:
"The network operator and vendor community has clearly indicated that
IPv6 header insertion is useful and required.". There was quite a bit
of discussion of this draft on 6man list. I believe the (current)
consensus is that it's neither necessary nor sufficient protocol. It's
not necessary because IP/IP encapsulation can be used to achieve the
same effect. It's not sufficient because it makes several requirements
on the network that are outside the specification of the protocol.

Tom


> And we've developed solutions
> already, dating back at least to SOCKS. So haven't we been implicitly
> pretending that this elephant wasn't in the room?
>
>     Brian

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to