Keep it simple. That’s the recommendation of a technical talk that headlined IETF 96’s plenary session in Berlin.
Ross Callon, a long-time participant who has attended 89 IETF meetings, said the IETF is developing too many protocols that do the same thing, creating unnecessary confusion and complexity. He gave the same talk about protocol simplicity at the Routing Area meeting, but he said his message is applicable to all areas of the IETF.
“Additional options and additional capabilities are being added to our protocols. While diversity in approaches is inevitable and valuable, too many options damages interoperability,” Callon said. “We have to be a little concerned about creating too many options because some vendors implement some, while some vendors implement others, and suddenly we don’t have interoperability.”
As an example, he pointed out the many ways the IETF has developed to encapsulate communications for virtual private networks. He explained that encapsulation can be done with or without connections. With connections, it typically is done over Multiprotocol Label Switching.
“There are three ways to signal your labels: Label Distribution Protocol, Resource Reservation Protocol, and Border Gateway Protocol. And there are some subtle differences when you get a label. DefinedOperations and Management protocols (such as Label Switched Paths, Ping, and Bidirectional Forwarding Detection) are ways to manage things and measure performance,” he said, adding that MPLS is “widely deployed all over the world and making money for a lot of service providers.”
He continued by saying the IETF also offers connectionless encapsulation, and he listed many options.
“You can take an Internet Protocol (IP) packet and encapsulate it in an IP header. There are four options just for that: IPv4 in IPv4, IPv4 in IPv6, IPv6 in IPv4, and IPv6 in IPv6. So if a vendor wants to implement all possible options, it really is four options,” he explained. “Given all those options, it’s hard to get one of them implemented and deployed everywhere.”
Callon said there are anywhere from 20 to 40 approaches total for connectionless encapsulation.
“You’re not going to implement 40 different ways to do encapsulation in an application-specific integrated circuit,” he said. “You run the risk that in some places in the world one gets implemented, and then somewhere else another gets implemented. You can end up with a loss of interoperability.”
Callon emphasized that the Internet is the largest machine ever made, with billions of users and hundreds of vendors. He said the Internet exists because of its multivendor and multiservice provider interoperability.
“No one vendor could have done this,” he said. “No one vendor could have implemented it, and no one vendor could have thought of it… In order for this explosive growth to occur, we need real, effective, well-written interoperability standards that everyone can implement.”
Callon reminded the audience that the motivation for companies and individuals to focus on interoperability instead of standards proliferation is that so many of them have done well because of the explosive growth of the Internet.
“We’re all better off because of the growth of the Internet,” he said. “It wouldn’t have happened if we had not had choices to do something, but it also wouldn’t have happened if we had 20 or 30 ways to do something.”
Callon made a strong case for the IETF being wary of creating too many unnecessary standards, and he urged each individual participant to focus on this problem. He said this problem can’t be solved by the IETF leadership, but instead needs a bottom-up solution.
“The IETF needs to find a way to avoid frivolous standards,” he said. “It is to the advantage of all of our companies and all of our research organizations and all of our government agencies that the Internet continues to grow. I’m asking everybody to think about this when a Working Group is considering a protocol: Is it really needed or can we use an existing tool?”
