What extension mechanisms are successful?

[tfpauly]

Most IETF protocols have some sort of extensibility, and these often are subject to ossification and loss of flexibility. Some extension mechanisms may intend to be used infrequently, but others are used less effectively than intended due to ossification.

• Which extension mechanisms in protocols you work with have proven to be flexible and successful? What made it work?
• Which extension mechanisms have ended up being hard to use? What went wrong?

[cabo]

Maybe the discussion should start with listing sources of ossification.
A leading implementation that is maintained in an irresponsible way is different from a situation where multiple stakeholders with different objectives must agree before evolution can occur. There may also be rather boring technical issues (a packet getting too big, a code point space running out). some of which inside the design of the protocol and some outside.

[mirjak]

There is already https://tools.ietf.org/html/rfc6709 however it does not talk about ossification. But I would say that the point https://tools.ietf.org/html/draft-iab-use-it-or-lose-it is also trying to address.

[martinthomson]

@britram asked another question: are there examples of where active use have failed?

[martinthomson]

@wbl mentioned that NTPv4 had extension codepoints that were defined over the course of 10 years. These were not widely deployed, so the extensions were not in active use over that time. Now that the extensions are being used actively, it's completely unreliable.

[cabo]

Extensibility is not just about being able to carry additional information in a PDU that wasn't originally planned for. It is also about planning the reactions of implementations that do or don't implement that extension, including preventing false interoperability if needed ("versioning") or ensuring interoperability so not to create an artificial obstacle to using the extension.

[martinthomson]

Yes. You can't just say "MUST send zero", you have to also say "MUST ignore a one if you don't know what that means". It's about being able to predict the effect of new behaviour. This can't be completely unexpected or you get unpredictable and unreliable reactions.

You can, with a lot of effort, eradicate unpredictability from the undefined regions of a protocol. That's how TLS grew its extension mechanism. But it costs an awful lot.

[obonaventure]

I think that it would make sense to collect a few examples of problems that have limited the evolvability of some protocols. Here are some examples:

• in TCP, the maximum length of the TCP extended header limits the ability to negotiate different options during the handshake
• in TCP (and many other protocols), extensions are only negotiated during the handshake, having the ability to support late negotiation could make sense
• the initial BGP specification did not support capabilities
• the initial BGP specification only support 4K long messages, it took 10 years before adopting rfc8654

[obonaventure]

We should probably distinguish between different classes of protocols that have different requirements in terms of extensibility.

A first class are the datagram protocols like IPv4, IPv6 or UDP. For these protocols, each packet is considered as independent are there is no negotiation mechanism to decide when/how to use a given extension.

A second class are the session based protocol like TCP, TLS, HTTP, and many others that open a session exchange data for some time and then close the session. For these protocols, the classical approach is to negotiate extensions during the session establishment and use the mutually agreed ones during the entire session.

A third class are the signalling/routing protocols such as BGP, LDP, ... These protocols use sessions that typically last until the next reboot. Several of these protocols include graceful restart mechanisms that allow to restart a session without impacting the FIB. This graceful restart capability is probably a unique requirement of such protocols.

A fourth class of protocols are the multicast protocols. When there are multiple receivers, the problem of negotiating protocol extensions becomes immediately harder.