-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-protocol-diversity.xml
290 lines (196 loc) · 19.5 KB
/
draft-protocol-diversity.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.tools.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-xml2rfc-template-05" ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Protocol Diversity">The Internet of Three Protocols: Diversity in Networking Protocols</title>
<author fullname="Jared Mauch" initials="J.M." role="editor"
surname="Mauch">
<organization>Netflix</organization>
<address>
<postal />
<phone />
<email>[email protected]</email>
</address>
</author>
<author fullname="Russ White" initials="R.W." role="editor"
surname="White">
<organization>Juniper Networks</organization>
<address>
<postal />
<phone />
<email>[email protected]</email>
</address>
</author>
<date year="2021" />
<!-- Meta-data Declarations -->
<area>Not Certain</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>The Internet began with a clear 'waist' at layer 3 in the form of the Internet Protocol. Above IP there was a suite of protocols, each of which was designed to carry a different kind of information. Below IP was a wide range of physical transport protocols such as Ethernet, Token Ring, and SONET. In recent years, however, the diversity of the protocol stack has been dramatically reduced, especially above IP. While protocols still exist for transporting various kinds of information, in practice only three are widely used: the Border Gateway Protocol (BGP), the HyperText Transfer Protocol (HTTP), and the Domain Name System (DNS). These protocols, and their attendent systems, have been expanded to take on virtually every role in the networking space.</t>
<t>This draft examines the phenomena and consequences of the dwindling diversity in internet protocols.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Sample Reference <xref target="RFC2629">RFC 2629</xref>.</t>
<t>Protocols were once designed to serve a narrow range of well-defined purposes, such as setting up a voice session, moving voice traffic, moving a file between systems, computing interdomain loop-free paths, etc. Recently, however, the IETF has been adding new functionality to existing protocols rather than creating new ones in response to increasing use cases and user requirements. Over time, the "interesting" protocol space has narrowed from hundreds to tens, and now to less-than-ten.</t>
<t>Three protocols, and their attendent systems, now dominate the Internet ecosystem: BGP, HTTP, and DNS. Each of these three protocols have been expanded to support an ever-increasing array of use cases.</t>
<t>This document begins by considering the increasing reliance on these three protocols to solve a wide array or use cases. Examples will be given of each protocol assuming more capabilities that would have traditionally been provided by creating a new protocol. The second section of this document considers the harms resulting from this lack of protocol diversity, including the impact on network operations, complexity, and the possible support this lack of diversity gives to the centralization of Internet infrastructure and services.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section> <!-- end of requirements language -->
</section> <!-- end of introduction -->
<!-- WORKING HERE -->
<section anchor="EXAMPLES" title="Examples of Protocol Concentration">
<t>The HyperText Transfer Protocol (HTTP) was originally designed to transfer text (as its name implies) formatted in the HyperText Markup Language (HTML). When HTTP was designed, separate protocols were available for file transfer (FTP), voice (RTP), and encrypted transport (TLS and IPsec). Over time, HTTP has been extended to transport virtually every kind of media, minimizing (or even eliminating) the usage of specialized content protocols. The HTTPS extensions eliminate the use of specialized secure transports.</t>
<t>More recently, HTTPS has been extended to carry DNS as well as content, moving the transport of naming information from TCP and UDP into the HTTP transport. This change also moves the primary responsibility for name resolution from the operating system into the web browser. Thus, a modern end-host can be completely contained within a web browser, reducing the diversity of applications and functionality on an end point.</t>
<t>The Border Gateway Protocol was originally designed to provide interdomain routing information. To this end, the protocol was designed with transit operations in mind, including policy instruments (such as local preference, multiple exit discriminator, etc.). The first set of extensions added to BGP were for building and supporting overlays, such as MPLS and eVPN; while these do increase the complexity of the protocol, they appear to be closely related to the original purpose of the protocol.</t>
<t>Another recent development, however, is the use of BGP to replace Interior Gateway Protocols (IGPs), such as OSPF and IS-IS, in campus and data center fabric protocols. These extensions lie outside the original purpose of BGP.</t>
<t>The Domain Name System (DNS) was originally designed to translate hostnames to IP addresses via a protocol and a distributed database system. New functionality is constantly added to the DNS, including ... </t>
</section> <!-- end of examples -->
<section anchor="COMPLEXITY" title="Complexity and Lack of Protocol Diversity">
<t>The increasing complexity of networks is widely recognized. Some of this complexity is driven by the ever-increasing requirements placed on networks. Poor design also drives complexity in modern networks. One example is the increasing belief that reducing the number of protocols necessarily decreases network complexity, making a network easier to design, operate, and manage. The "single protocol network" is an important factor in the increasing use of BGP as an interior gateway protocol.</t>
<t>Moving towards a single protocol to solve "all problems," however, ignores a basic tenent of complexity: local and global optimization are often orthogonal. Decreasing complexity in one area of a network inevitably increases complexity in some other area, even if the operator is not immediately aware of the suboptimal results on the system as a whole.</t>
<t>One example of this tradeoff is the increasing use of BGP as an IGP. In its original, interdomain, role, the operator is required to configure BGP peering sessions rather than relying on an automated discovery process. The intentional configuration of peering between networks in different administrative domains provides a layer of protection against accidental peering, and a layer of security (peers cannot be formed without both sides taking intentional action). To use BGP as an IGP, however, some form of peer autodiscovery must be added to the protocol--adding lines of code, new configuration knobs, and increasing the complexity of the peering state machine.</t>
<t>Any single piece of complexity might seem trivial in the abstract, but the continuing addition of new features to a protocol can increase complexity to the point that its difficult for an operator to know what to expect when the protocol is deployed in the field unless they have deep expertise in every options each implementation offers. Further, eatch new feature represents new lines of code and paths through the code that each developer must understand and work around. The sheer number of lines of code in an implementation of BGP has grown from tens of thousands to hundreds of thousands within the last few years.</t>
<t>While operating a network with more than one routing protocol may be more complex (in some sense) than operating a network using a single control plane, the complexity is transferred to a higher level of expertise on the part of the operator, a higher level of expertise in the protocol developer, and a more complex implementation code base. In essence, the operator is outsourcing complexity into the protocol. This is hardly a sustainable model.</t>
</section> <!-- end of complexity -->
<section anchor="OPHARMS" title="Operational Harms of Lack of Protocol Diversity">
<t>Two broad forms of harm from a lack of protocol diversity: those related to observabliity, and those related to the correct operation of a network.</t>
<section anchor="OBSHARMS" title="Lack of Protocol Diversity and Observation">
<t>The use of a few protocols to carry "everything" impacts operator's ability to correctly monitor and manage different traffic types. For instance, because video, files, hypertext, voice, and--more recently--DNS queries are all carried in the HTTPS protocol, there is no differentiation, from an operator's perspective, between these different kinds of traffic. This lack of differentiation makes it impossible for operators to accurately measure and understand the traffic flowing through their network.</t>
</section> <!-- end of observational harms -->
<section anchor="OBSHARMS" title="Lack of Protocol Diversity and Correct Operation">
<t>While most operators are familiar with the Mean Time Between Failures (MTBF), a measure of operational harm that is more approriate for measuring network outages is the Mean Time Between Mistakes (MTBM). Research has shown that operator mistakes are the primary cause of large-scale network outages in the real world (need a reference here). Each new feature added to a protocol represents a new opportunity for mistakes. Features orthogonal to the original intent and scope of the protocol represent greater opportunities for catastrophinc mistakes.</t>
<t>The BGP peering process considered in a prior section provides several good examples. When used as an Exterior Gateway Protocol (EGP), BGP should not automatically discover speakers reachable through connected interfaces, nor should it advertise routes unless some policy is configured. These two defaults protect an operator from accidentally connecting to a network in another administrative domain, peering, and accepting or advertising routes representing a breach of security, risking a routing loop, or otherwise causing a problem.</t>
<t>The defaults for a BGP implementation designed or deployed as an IGP, however, should be precisely the opposite in these two cases. BGP speakers should auto-discover potential peering speakers, and should advertise all routes with no configuration. Deploying a set of configurations designed for use with BGP as an IGP in an external peering situation can cause network outages.</t>
<t>Of course, network operators should be aware of these kinds of problems, and configure their BGP speakers defensively--but this makes the job of the operator more complex, and makes it possible to cause catastrophic failures with simple configuration options. The solution is always "be careful," but humans make mistakes.</t>
<!-- probably need an example from DNS here -->
</section> <!-- end of correct operation -->
</section> <!-- end of operational harms -->
<section anchor="CENTRALIZATION" title="Protocol Diversity and Centralization">
<t>As a protocol becomes more complex, the body of operational and development knowledge around that protocol is fragmented, with each fragment being thinner. This fragmentation and thinning encourages the centratlization of expertise, operations, and ultimately encourages the centralization of the global Internet. For instance, in the case of BGP being used both as an IGP and an EGP, the number of engineers capable of understanding both use cases equally well is likely to be vanishingly small. Engineers and developers will necessarily specialize in one use case or the other. Each of these use cases will, over time, become increasingly complex.</t>
<t>As the number of engineers and developers who understand the "whole protocol," or even understand any single use case in great depth, falls, they will tend to gravitate to larger operators. Larger operators will also have a better platform on which to teach engineers and developers the "whole protocol" and each narrow use case. This concentration of qualified personnel will, in turn, tend to centralize the development and operation of large-scale services.</t>
</section> <!-- end of centralization -->
<section anchor="RECOMMENDATIONS" title="Recommendations">
<t>Encourage declaring the purpose or scope of a protocol when it's being designed</t>
<t>The IESG, IAB, WG chairs, etc., should seriously question the extension of a protocol beyond this scope</t>
<t>Encourage the creation of new protocols to solve new problems, rather than constantly adding to existing protocols</t>
</section> <!-- end of recommendations -->
<!-- working here -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
<t>This document is part of a plan to make xml2rfc indispensable <xref target="DOMINATION"></xref>.</t>
</section> <!-- end of acknowledgements -->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section will
be removed during conversion into an RFC by the RFC Editor.</t>
</section> <!-- end of IANA considerations -->
<section anchor="Security" title="Security Considerations">
<t>All drafts are required to have a security considerations section.
See <xref target="RFC3552">RFC 3552</xref> for a guide.</t>
</section> <!-- end of security considerations -->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<reference anchor="min_ref">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&I-D.narten-iana-considerations-rfc2434bis;
<!-- A reference written by by an organization not a person. -->
<reference anchor="DOMINATION"
target="http://www.example.com/dominator.html">
<front>
<title>Ultimate Plan for Taking Over the World</title>
<author>
<organization>Mad Dominators, Inc.</organization>
</author>
<date year="1984" />
</front>
</reference>
</references>
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>