On Wed, Sep 12, 2018 at 7:42 PM, Brian E Carpenter <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/int-area
