Not Your Father’s Internet

Not Your Father’s Internet

Bruce and I have been going back and forth—for weeks now—on whether to refer to packet forwarding devices in the 7th Edition as “switches” or “routers”. It sounds like a nit, but I know lots of students that have never been clear on the distinction. It’s also our experience that any issue that keeps coming up over and over is likely to be the tip of a deeper question, and so it’s best to not ignore it. I’m going to replay some of the highlights of our discussion, and then try to draw out that deeper explanation. A word of caution though. You will want to read to the end, since, like many discussions of this sort, we have ventured down a few dead ends.

We each ended up drawing a Venn diagram in an effort to isolate the source of our differences. I’ll start with Bruce’s, which in a nutshell, positions routers as the standard name for any switching device that forwards IP packets.

The following is my counter-diagram. A key difference is that I use “Packet Switches” as both a descriptive category and a configurable brick. I’m not sure how that dual meaning affects a Venn diagram, but framing switching devices as a programmable building block is an important theme of the book. That theme originates in the blog post that got the ball rolling on our decision to write a 7th edition, which is worth highlighting because we want to talk about L2/L3-agnostic features without necessarily using the term “router”. (I called the base system a “commodity Ethernet switch” in that post, which turned out to foreshadow the naming problem that was to come; it turns out the focus on L2 was a red herring.)

These diagrams do reveal the sticking point, which is how it could be that “Router” is contained inside “L3-Configured Switches”, rather than representing the exact same set. The onus was on me to justify L3-Configured Switches > Routers, and to define a rule that would guide deciding which term to use in each setting. Bruce’s skepticism is well-founded, based on his argument that “L3 Switch” is a vendor-invented marketing term. So the bar was pretty high, especially given that ”router” is not wrong (i.e., this is a question of whether there are circumstances where switch is the better wording choice).

We’re writing a textbook, so it might be as simple as starting with the textbook definition of router: it’s the enabling technology of internetworking, used to interconnect two or more networks. According to this way of thinking, we might reserve the term router for deployments in which, either (a) the device forwards packets between heterogeneous link technologies, or (b) the device interconnects two or more autonomous organizations. This is pretty much how we have always introduced IP and routers in our book, with a focus on heterogeneity and autonomy. This seems promising as a rule: deployments that use IP as a convenient addressing scheme, but have nothing to do with internetworking, can be called switches rather than routers. For example, in a network of point-to-point Ethernet links within a single organization—even when configured with an L3 data plane—we would elect to call the devices switches. 

That forces us to be careful to qualify L2-only switches, but maybe that’s OK since L3 data planes have become the dominant configuration. Why is that? Part of what makes IP addresses “convenient” is that they include a flexible subnetting scheme, making them easy to adapt to different networks. We also now have efficient forwarding pipelines for IP, including support for load balancing across multiple paths. Plus, IP comes with an impressive collection of control plane tooling. This might suggest that it’s the control plane, not the data plane, that tips the scales in favor of “switch” or “router”, or vice versa.

As a strawman, then, we could stipulate that any device that runs BGP should be called a router. This fails because home routers—which I’m happy to stipulate ought to be called routers—are an obvious exception to the “BGP rule”, but there’s a bigger reason the rule is not sufficient, which gets us closer to a resolution.

The best example I have of an L3-switch not being called a router is in a datacenter switching fabric. Such fabrics are often configured as a leaf-spine (Clos) topology. We refer to leaf (top-of-rack) and spine switches, even though they typically support an IP data plane. But switching fabrics do sometimes run BGP in the control plane. Without getting into a detailed explanation of how that works (you can read more here, here and here), the approach takes advantage of BGP being a natural fit for a hierarchical topology. BGP’s ability to scale is also an important factor.

If datacenters are clearly in the “switch camp”, then what about large ISP networks? Bruce is of the opinion that the refrigerator sized forwarding devices that ISPs deploy are clearly routers. I don’t disagree, but it is interesting to note that high-end routers frequently share the same internal design as data center switches. That cloud backbones call the resulting aggregate a switch (e.g., B4 switches) muddies the water.

Generational Change

It’s easy to see why students might leave a networking course without a clear understanding of when a forwarding device should be called a switch and when it should be called a router. Language matters! Both terms come with implications, but there is no clear-cut rule as to which is appropriate in a given situation. As our little back-and-forth demonstrates, the answer is context-dependent. For the book, we’ll let the “norms” decide, and go with whatever term is the consensus for the topic being covered (coupled with guidance to help navigate the varied interpretations).

What seems to be complicating the question—the reason we didn’t have this debate when writing earlier editions—is that we are experiencing a generational change. This is the deeper issue I mentioned above. One thing that’s happening is that yesterday’s Internet technology is being applied to use cases that were not imagined when the technology was first defined. Running BGP in a datacenter is a perfect example. That technology, which is often defined in RFCs written 20 or more years ago, is deeply rooted in an Internet that is qualitatively different from today’s. As we write new paragraphs for 7E, and more importantly, as we refresh old paragraphs to make them fit in the new (hopefully modern) narrative, we need to be sure to acknowledge that generational change. This goes beyond the switch-vs-router question. As a thought experiment, imagine how you would motivate and describe BGP as a datacenter routing protocol, independent of its original use case. Do the same for IP subnetting/supernetting.

Since we’re going to let context decide the switch-vs-router question, we can’t help but notice that the emergence of the cloud is shifting the “center of gravity” for the languages we use to talk about and describe networks. For 7E, datacenters and cloud backbones are the two contexts where switch seems to be an accepted alternative to router. That language comes primarily from research papers published by Google, Microsoft, Meta, and other cloud providers. In contrast, the first six editions of our book were heavily influenced by the language of RFCs, which were often written by network vendors. Those RFCs still serve a purpose, but the Internet’s continued evolution is no longer entirely gated by the IETF.  The cloud providers are supplanting the router vendors as thought leaders, and putting their stamp on today’s RFCs in the process. We might expect networking for AI applications to change the language yet again. I’m pretty sure we’ll continue to call it the Internet, but it won’t be the Internet your father (or Bruce and I) grew up with.

As usual, Scott Aaronson has a useful take on the latest breakthroughs in quantum computing and cryptography. He also wrote a good piece on how hard it is to get people to deal with the uncertainty of future quantum capabilities. (You can guess how many “jokes” he has to hear about uncertainty).

There is no shortage of hot takes on Mythos, but David Chisnall’s is one of the most enjoyable.

We realise that this week’s headline might only make sense to people of a certain age. Here is a link to one of the original ads we’re referencing and an explainer.

Preview image this week by Albert Stoynov on Unsplash

@llp85704
@SystemsAppr does it forward based solely on L2 headers? -> Switch
does it forward based on L2 (ethernet) but has knowledge of L3 (IP) -> L2 Switch
does it forward based on L3 (IP) -> IP router

Does it speak BGP? -> BGP Router; Speaks OSPF -> OSPF Router

Is it supposed to go to the customer who will not poke at it: CPE (Customer Premises Equipment).

Does it do NAT? -> NAT Box!

Though with the advent of IPv6 and ISPs properly routing subnets, even those are becoming routers.

@jeroen @llp85704 @SystemsAppr It's been a long time since I've had to utter the phrase a "bridge is a switch is a bridge." It's all just marketing now. At one time switch essentially implied faster, now all home CPE NAT/APs are usually called routers. Sometimes consumer bridges/switches are called hubs.

Maybe best to describe what is inspected, used, and or changed in a forwarding decision and talk about the evolution of terms?

@jeroen @llp85704 @SystemsAppr It's been a long time since I've had to utter the phrase a "bridge is a switch is a bridge." It's all just marketing now. At one time switch essentially implied faster, now all home CPE NAT/APs are usually called routers. Sometimes consumer bridges/switches are called hubs.

Maybe best to describe what is inspected, used, and or changed in a forwarding decision and talk about the evolution of terms?

Not Your Father’s Internet

Bruce and I have been going back and forth—for weeks now—on whether to refer to packet forwarding devices in the 7th Edition as “switches” or “routers”. It sounds like a nit, but I know lots of students that have never been clear on the distinction. It’s also our experience that any issue that keeps coming up over and over is likely to be the tip of a deeper question, and so it’s best to not ignore it. I’m going to replay some of the highlights of our discussion, and then try to draw out that deeper explanation. A word of caution though. You will want to read to the end, since, like many discussions of this sort, we have ventured down a few dead ends.

We each ended up drawing a Venn diagram in an effort to isolate the source of our differences. I’ll start with Bruce’s, which in a nutshell, positions routers as the standard name for any switching device that forwards IP packets.

The following is my counter-diagram. A key difference is that I use “Packet Switches” as both a descriptive category and a configurable brick. I’m not sure how that dual meaning affects a Venn diagram, but framing switching devices as a programmable building block is an important theme of the book. That theme originates in the blog post that got the ball rolling on our decision to write a 7th edition, which is worth highlighting because we want to talk about L2/L3-agnostic features without necessarily using the term “router”. (I called the base system a “commodity Ethernet switch” in that post, which turned out to foreshadow the naming problem that was to come; it turns out the focus on L2 was a red herring.)

These diagrams do reveal the sticking point, which is how it could be that “Router” is contained inside “L3-Configured Switches”, rather than representing the exact same set. The onus was on me to justify L3-Configured Switches > Routers, and to define a rule that would guide deciding which term to use in each setting. Bruce’s skepticism is well-founded, based on his argument that “L3 Switch” is a vendor-invented marketing term. So the bar was pretty high, especially given that ”router” is not wrong (i.e., this is a question of whether there are circumstances where switch is the better wording choice).

We’re writing a textbook, so it might be as simple as starting with the textbook definition of router: it’s the enabling technology of internetworking, used to interconnect two or more networks. According to this way of thinking, we might reserve the term router for deployments in which, either (a) the device forwards packets between heterogeneous link technologies, or (b) the device interconnects two or more autonomous organizations. This is pretty much how we have always introduced IP and routers in our book, with a focus on heterogeneity and autonomy. This seems promising as a rule: deployments that use IP as a convenient addressing scheme, but have nothing to do with internetworking, can be called switches rather than routers. For example, in a network of point-to-point Ethernet links within a single organization—even when configured with an L3 data plane—we would elect to call the devices switches. 

That forces us to be careful to qualify L2-only switches, but maybe that’s OK since L3 data planes have become the dominant configuration. Why is that? Part of what makes IP addresses “convenient” is that they include a flexible subnetting scheme, making them easy to adapt to different networks. We also now have efficient forwarding pipelines for IP, including support for load balancing across multiple paths. Plus, IP comes with an impressive collection of control plane tooling. This might suggest that it’s the control plane, not the data plane, that tips the scales in favor of “switch” or “router”, or vice versa.

As a strawman, then, we could stipulate that any device that runs BGP should be called a router. This fails because home routers—which I’m happy to stipulate ought to be called routers—are an obvious exception to the “BGP rule”, but there’s a bigger reason the rule is not sufficient, which gets us closer to a resolution.

The best example I have of an L3-switch not being called a router is in a datacenter switching fabric. Such fabrics are often configured as a leaf-spine (Clos) topology. We refer to leaf (top-of-rack) and spine switches, even though they typically support an IP data plane. But switching fabrics do sometimes run BGP in the control plane. Without getting into a detailed explanation of how that works (you can read more here, here and here), the approach takes advantage of BGP being a natural fit for a hierarchical topology. BGP’s ability to scale is also an important factor.

If datacenters are clearly in the “switch camp”, then what about large ISP networks? Bruce is of the opinion that the refrigerator sized forwarding devices that ISPs deploy are clearly routers. I don’t disagree, but it is interesting to note that high-end routers frequently share the same internal design as data center switches. That cloud backbones call the resulting aggregate a switch (e.g., B4 switches) muddies the water.

Generational Change

It’s easy to see why students might leave a networking course without a clear understanding of when a forwarding device should be called a switch and when it should be called a router. Language matters! Both terms come with implications, but there is no clear-cut rule as to which is appropriate in a given situation. As our little back-and-forth demonstrates, the answer is context-dependent. For the book, we’ll let the “norms” decide, and go with whatever term is the consensus for the topic being covered (coupled with guidance to help navigate the varied interpretations).

What seems to be complicating the question—the reason we didn’t have this debate when writing earlier editions—is that we are experiencing a generational change. This is the deeper issue I mentioned above. One thing that’s happening is that yesterday’s Internet technology is being applied to use cases that were not imagined when the technology was first defined. Running BGP in a datacenter is a perfect example. That technology, which is often defined in RFCs written 20 or more years ago, is deeply rooted in an Internet that is qualitatively different from today’s. As we write new paragraphs for 7E, and more importantly, as we refresh old paragraphs to make them fit in the new (hopefully modern) narrative, we need to be sure to acknowledge that generational change. This goes beyond the switch-vs-router question. As a thought experiment, imagine how you would motivate and describe BGP as a datacenter routing protocol, independent of its original use case. Do the same for IP subnetting/supernetting.

Since we’re going to let context decide the switch-vs-router question, we can’t help but notice that the emergence of the cloud is shifting the “center of gravity” for the languages we use to talk about and describe networks. For 7E, datacenters and cloud backbones are the two contexts where switch seems to be an accepted alternative to router. That language comes primarily from research papers published by Google, Microsoft, Meta, and other cloud providers. In contrast, the first six editions of our book were heavily influenced by the language of RFCs, which were often written by network vendors. Those RFCs still serve a purpose, but the Internet’s continued evolution is no longer entirely gated by the IETF.  The cloud providers are supplanting the router vendors as thought leaders, and putting their stamp on today’s RFCs in the process. We might expect networking for AI applications to change the language yet again. I’m pretty sure we’ll continue to call it the Internet, but it won’t be the Internet your father (or Bruce and I) grew up with.

As usual, Scott Aaronson has a useful take on the latest breakthroughs in quantum computing and cryptography. He also wrote a good piece on how hard it is to get people to deal with the uncertainty of future quantum capabilities. (You can guess how many “jokes” he has to hear about uncertainty).

There is no shortage of hot takes on Mythos, but David Chisnall’s is one of the most enjoyable.

We realise that this week’s headline might only make sense to people of a certain age. Here is a link to one of the original ads we’re referencing and an explainer.

Preview image this week by Albert Stoynov on Unsplash

@llp85704 As someone who occasionally buys these things: at the enterprise level, "router" today means "extremely expensive on a per-port basis, but probably supports weird interface types you don't have" and "switch" means "reasonably priced ports based on commodity silicon". I only buy switches (and that includes for my BGP-eVPN data center fabrics) because there's simply nothing in our environment that could justify a 10x-100x premium.

Not Your Father’s Internet

Bruce and I have been going back and forth—for weeks now—on whether to refer to packet forwarding devices in the 7th Edition as “switches” or “routers”. It sounds like a nit, but I know lots of students that have never been clear on the distinction. It’s also our experience that any issue that keeps coming up over and over is likely to be the tip of a deeper question, and so it’s best to not ignore it. I’m going to replay some of the highlights of our discussion, and then try to draw out that deeper explanation. A word of caution though. You will want to read to the end, since, like many discussions of this sort, we have ventured down a few dead ends.

We each ended up drawing a Venn diagram in an effort to isolate the source of our differences. I’ll start with Bruce’s, which in a nutshell, positions routers as the standard name for any switching device that forwards IP packets.

The following is my counter-diagram. A key difference is that I use “Packet Switches” as both a descriptive category and a configurable brick. I’m not sure how that dual meaning affects a Venn diagram, but framing switching devices as a programmable building block is an important theme of the book. That theme originates in the blog post that got the ball rolling on our decision to write a 7th edition, which is worth highlighting because we want to talk about L2/L3-agnostic features without necessarily using the term “router”. (I called the base system a “commodity Ethernet switch” in that post, which turned out to foreshadow the naming problem that was to come; it turns out the focus on L2 was a red herring.)

These diagrams do reveal the sticking point, which is how it could be that “Router” is contained inside “L3-Configured Switches”, rather than representing the exact same set. The onus was on me to justify L3-Configured Switches > Routers, and to define a rule that would guide deciding which term to use in each setting. Bruce’s skepticism is well-founded, based on his argument that “L3 Switch” is a vendor-invented marketing term. So the bar was pretty high, especially given that ”router” is not wrong (i.e., this is a question of whether there are circumstances where switch is the better wording choice).

We’re writing a textbook, so it might be as simple as starting with the textbook definition of router: it’s the enabling technology of internetworking, used to interconnect two or more networks. According to this way of thinking, we might reserve the term router for deployments in which, either (a) the device forwards packets between heterogeneous link technologies, or (b) the device interconnects two or more autonomous organizations. This is pretty much how we have always introduced IP and routers in our book, with a focus on heterogeneity and autonomy. This seems promising as a rule: deployments that use IP as a convenient addressing scheme, but have nothing to do with internetworking, can be called switches rather than routers. For example, in a network of point-to-point Ethernet links within a single organization—even when configured with an L3 data plane—we would elect to call the devices switches. 

That forces us to be careful to qualify L2-only switches, but maybe that’s OK since L3 data planes have become the dominant configuration. Why is that? Part of what makes IP addresses “convenient” is that they include a flexible subnetting scheme, making them easy to adapt to different networks. We also now have efficient forwarding pipelines for IP, including support for load balancing across multiple paths. Plus, IP comes with an impressive collection of control plane tooling. This might suggest that it’s the control plane, not the data plane, that tips the scales in favor of “switch” or “router”, or vice versa.

As a strawman, then, we could stipulate that any device that runs BGP should be called a router. This fails because home routers—which I’m happy to stipulate ought to be called routers—are an obvious exception to the “BGP rule”, but there’s a bigger reason the rule is not sufficient, which gets us closer to a resolution.

The best example I have of an L3-switch not being called a router is in a datacenter switching fabric. Such fabrics are often configured as a leaf-spine (Clos) topology. We refer to leaf (top-of-rack) and spine switches, even though they typically support an IP data plane. But switching fabrics do sometimes run BGP in the control plane. Without getting into a detailed explanation of how that works (you can read more here, here and here), the approach takes advantage of BGP being a natural fit for a hierarchical topology. BGP’s ability to scale is also an important factor.

If datacenters are clearly in the “switch camp”, then what about large ISP networks? Bruce is of the opinion that the refrigerator sized forwarding devices that ISPs deploy are clearly routers. I don’t disagree, but it is interesting to note that high-end routers frequently share the same internal design as data center switches. That cloud backbones call the resulting aggregate a switch (e.g., B4 switches) muddies the water.

Generational Change

It’s easy to see why students might leave a networking course without a clear understanding of when a forwarding device should be called a switch and when it should be called a router. Language matters! Both terms come with implications, but there is no clear-cut rule as to which is appropriate in a given situation. As our little back-and-forth demonstrates, the answer is context-dependent. For the book, we’ll let the “norms” decide, and go with whatever term is the consensus for the topic being covered (coupled with guidance to help navigate the varied interpretations).

What seems to be complicating the question—the reason we didn’t have this debate when writing earlier editions—is that we are experiencing a generational change. This is the deeper issue I mentioned above. One thing that’s happening is that yesterday’s Internet technology is being applied to use cases that were not imagined when the technology was first defined. Running BGP in a datacenter is a perfect example. That technology, which is often defined in RFCs written 20 or more years ago, is deeply rooted in an Internet that is qualitatively different from today’s. As we write new paragraphs for 7E, and more importantly, as we refresh old paragraphs to make them fit in the new (hopefully modern) narrative, we need to be sure to acknowledge that generational change. This goes beyond the switch-vs-router question. As a thought experiment, imagine how you would motivate and describe BGP as a datacenter routing protocol, independent of its original use case. Do the same for IP subnetting/supernetting.

Since we’re going to let context decide the switch-vs-router question, we can’t help but notice that the emergence of the cloud is shifting the “center of gravity” for the languages we use to talk about and describe networks. For 7E, datacenters and cloud backbones are the two contexts where switch seems to be an accepted alternative to router. That language comes primarily from research papers published by Google, Microsoft, Meta, and other cloud providers. In contrast, the first six editions of our book were heavily influenced by the language of RFCs, which were often written by network vendors. Those RFCs still serve a purpose, but the Internet’s continued evolution is no longer entirely gated by the IETF.  The cloud providers are supplanting the router vendors as thought leaders, and putting their stamp on today’s RFCs in the process. We might expect networking for AI applications to change the language yet again. I’m pretty sure we’ll continue to call it the Internet, but it won’t be the Internet your father (or Bruce and I) grew up with.

As usual, Scott Aaronson has a useful take on the latest breakthroughs in quantum computing and cryptography. He also wrote a good piece on how hard it is to get people to deal with the uncertainty of future quantum capabilities. (You can guess how many “jokes” he has to hear about uncertainty).

There is no shortage of hot takes on Mythos, but David Chisnall’s is one of the most enjoyable.

We realise that this week’s headline might only make sense to people of a certain age. Here is a link to one of the original ads we’re referencing and an explainer.

Preview image this week by Albert Stoynov on Unsplash

@llp85704 imho the terms switch and router should be seen as a function, not as a hardware device (much like server vs client computers). Historically, the terms switch, bridge, and hub have been used for Ethernet level (i.e. historically L2} connecting functions, whereas the term router has been used for IP level (i.e. historically L3) connecting functions. With proxy ARP, SDN, route/switch combo devices, VMs, and the Linux bridge function, things got rather muddy.

Not Your Father’s Internet

Bruce and I have been going back and forth—for weeks now—on whether to refer to packet forwarding devices in the 7th Edition as “switches” or “routers”. It sounds like a nit, but I know lots of students that have never been clear on the distinction. It’s also our experience that any issue that keeps coming up over and over is likely to be the tip of a deeper question, and so it’s best to not ignore it. I’m going to replay some of the highlights of our discussion, and then try to draw out that deeper explanation. A word of caution though. You will want to read to the end, since, like many discussions of this sort, we have ventured down a few dead ends.

We each ended up drawing a Venn diagram in an effort to isolate the source of our differences. I’ll start with Bruce’s, which in a nutshell, positions routers as the standard name for any switching device that forwards IP packets.

The following is my counter-diagram. A key difference is that I use “Packet Switches” as both a descriptive category and a configurable brick. I’m not sure how that dual meaning affects a Venn diagram, but framing switching devices as a programmable building block is an important theme of the book. That theme originates in the blog post that got the ball rolling on our decision to write a 7th edition, which is worth highlighting because we want to talk about L2/L3-agnostic features without necessarily using the term “router”. (I called the base system a “commodity Ethernet switch” in that post, which turned out to foreshadow the naming problem that was to come; it turns out the focus on L2 was a red herring.)

These diagrams do reveal the sticking point, which is how it could be that “Router” is contained inside “L3-Configured Switches”, rather than representing the exact same set. The onus was on me to justify L3-Configured Switches > Routers, and to define a rule that would guide deciding which term to use in each setting. Bruce’s skepticism is well-founded, based on his argument that “L3 Switch” is a vendor-invented marketing term. So the bar was pretty high, especially given that ”router” is not wrong (i.e., this is a question of whether there are circumstances where switch is the better wording choice).

We’re writing a textbook, so it might be as simple as starting with the textbook definition of router: it’s the enabling technology of internetworking, used to interconnect two or more networks. According to this way of thinking, we might reserve the term router for deployments in which, either (a) the device forwards packets between heterogeneous link technologies, or (b) the device interconnects two or more autonomous organizations. This is pretty much how we have always introduced IP and routers in our book, with a focus on heterogeneity and autonomy. This seems promising as a rule: deployments that use IP as a convenient addressing scheme, but have nothing to do with internetworking, can be called switches rather than routers. For example, in a network of point-to-point Ethernet links within a single organization—even when configured with an L3 data plane—we would elect to call the devices switches. 

That forces us to be careful to qualify L2-only switches, but maybe that’s OK since L3 data planes have become the dominant configuration. Why is that? Part of what makes IP addresses “convenient” is that they include a flexible subnetting scheme, making them easy to adapt to different networks. We also now have efficient forwarding pipelines for IP, including support for load balancing across multiple paths. Plus, IP comes with an impressive collection of control plane tooling. This might suggest that it’s the control plane, not the data plane, that tips the scales in favor of “switch” or “router”, or vice versa.

As a strawman, then, we could stipulate that any device that runs BGP should be called a router. This fails because home routers—which I’m happy to stipulate ought to be called routers—are an obvious exception to the “BGP rule”, but there’s a bigger reason the rule is not sufficient, which gets us closer to a resolution.

The best example I have of an L3-switch not being called a router is in a datacenter switching fabric. Such fabrics are often configured as a leaf-spine (Clos) topology. We refer to leaf (top-of-rack) and spine switches, even though they typically support an IP data plane. But switching fabrics do sometimes run BGP in the control plane. Without getting into a detailed explanation of how that works (you can read more here, here and here), the approach takes advantage of BGP being a natural fit for a hierarchical topology. BGP’s ability to scale is also an important factor.

If datacenters are clearly in the “switch camp”, then what about large ISP networks? Bruce is of the opinion that the refrigerator sized forwarding devices that ISPs deploy are clearly routers. I don’t disagree, but it is interesting to note that high-end routers frequently share the same internal design as data center switches. That cloud backbones call the resulting aggregate a switch (e.g., B4 switches) muddies the water.

Generational Change

It’s easy to see why students might leave a networking course without a clear understanding of when a forwarding device should be called a switch and when it should be called a router. Language matters! Both terms come with implications, but there is no clear-cut rule as to which is appropriate in a given situation. As our little back-and-forth demonstrates, the answer is context-dependent. For the book, we’ll let the “norms” decide, and go with whatever term is the consensus for the topic being covered (coupled with guidance to help navigate the varied interpretations).

What seems to be complicating the question—the reason we didn’t have this debate when writing earlier editions—is that we are experiencing a generational change. This is the deeper issue I mentioned above. One thing that’s happening is that yesterday’s Internet technology is being applied to use cases that were not imagined when the technology was first defined. Running BGP in a datacenter is a perfect example. That technology, which is often defined in RFCs written 20 or more years ago, is deeply rooted in an Internet that is qualitatively different from today’s. As we write new paragraphs for 7E, and more importantly, as we refresh old paragraphs to make them fit in the new (hopefully modern) narrative, we need to be sure to acknowledge that generational change. This goes beyond the switch-vs-router question. As a thought experiment, imagine how you would motivate and describe BGP as a datacenter routing protocol, independent of its original use case. Do the same for IP subnetting/supernetting.

Since we’re going to let context decide the switch-vs-router question, we can’t help but notice that the emergence of the cloud is shifting the “center of gravity” for the languages we use to talk about and describe networks. For 7E, datacenters and cloud backbones are the two contexts where switch seems to be an accepted alternative to router. That language comes primarily from research papers published by Google, Microsoft, Meta, and other cloud providers. In contrast, the first six editions of our book were heavily influenced by the language of RFCs, which were often written by network vendors. Those RFCs still serve a purpose, but the Internet’s continued evolution is no longer entirely gated by the IETF.  The cloud providers are supplanting the router vendors as thought leaders, and putting their stamp on today’s RFCs in the process. We might expect networking for AI applications to change the language yet again. I’m pretty sure we’ll continue to call it the Internet, but it won’t be the Internet your father (or Bruce and I) grew up with.

As usual, Scott Aaronson has a useful take on the latest breakthroughs in quantum computing and cryptography. He also wrote a good piece on how hard it is to get people to deal with the uncertainty of future quantum capabilities. (You can guess how many “jokes” he has to hear about uncertainty).

There is no shortage of hot takes on Mythos, but David Chisnall’s is one of the most enjoyable.

We realise that this week’s headline might only make sense to people of a certain age. Here is a link to one of the original ads we’re referencing and an explainer.

Preview image this week by Albert Stoynov on Unsplash