00:00
This is the art of network engineering,  where technology meets the human side of IT.  Whether you're scaling networks, solving problems, or shaping your career, you've got the insights, stories, and tips to keep you ahead in the ever evolving world of networking.  Welcome to the Art of Network Engineering podcast.  My name is Andy Lapteff,  and  I don't even have the words to describe  our guest tonight. So  I won't do that yet.

00:24
I'm going to introduce my co-host, Lexi. Hi, Lexi. How are you? I'm way less impressive. So this is a a good segue. Hello, Andy. I'm great. I've had quite the day. I'm excited for our conversation tonight. How are you doing? I am nervous and I'm usually not on this show. And you'll understand why in a moment when I introduce our guest, our guest on this episode is the one, the only, there aren't any superlatives left to give to you. Ms. Radia Perlman. How you doing Radia? Great. Thank you. I'm so happy you're here.

00:54
And we're going to talk so much trash  on the networking industry. No,  I saw one YouTube video you did at a college and I just,  I don't want to, I don't want to say I fell in love with you, but like, oh my God, you're just snark and you're, I'm  like,  oh, now I get it. Like, Radia is awesome. You said the things. And that's part of why I've always  loved Lexi over the years is she'll like read a standard or a book and just talk so much trash  on it as a human. And to hear you do that with protocols and things, I just, love it so much.

01:24
So, all right, so let me get started here before I get all fanboy and just blab like an idiot. You said that a lot of people believe about networking, like what they believe isn't actually true or isn't the whole story. What I mean is when you look at how networking is taught in practice today, they're the biggest things that we get wrong. So nobody would have designed what we have today. And if you're trying to understand it as if everything should make sense, you'll just kind of drive yourself crazy. So the way networking is often taught.

01:52
is  to just memorize what happens to be deployed today. That's not very interesting,  and there's no way to really understand it without looking at the history of the mistakes and the egos and the whatever that got us to where we are today. So I much prefer when I teach to say, here's a generic problem. You need to get a unique  address when you plug into a network.

02:18
How do you get that address? And here's seven different ways I could imagine doing it.  And this is how IPv4 does it. This is how Novell's IPX,  or  yeah, whatever it was called,  did it,  how DECnet did it and so forth. And  my publisher said that some people say the book is out of date because why is it talking about Apple Talk when nobody is using it anymore? But there were some incredibly

02:47
cool ideas there. And if all you care about is IPv4 or whatever, you'll have a much deeper understanding if you can look at alternatives. And then if you ever need to design something else, it would be nice to actually understand other things which might actually be better than what we have mainly deployed. But you should steal all the good ideas you can.

03:09
Oh my gosh, I can't agree more. I love hearing that from you, Radia, because I don't know. I feel like I hear a lot of other network engineers, especially the least less experienced ones, granted, but like a lot of network engineers say like, why would you bother learning that? That's old. That's from the  90s. Well, because there's good ideas from back then.  And, you know, people were maybe thinking a little bit differently. They didn't have the same stuff we have to build upon. And so they were thinking of things in entirely new ways.  It's always worth learning about.

03:37
past, I think just because we don't use it today doesn't mean the ideas can't be recycled into something new.  I studied my CCNA in 2011 and frame relay was in the blueprint at the time.  then and now people will yell that these certifications is ridiculous. And then my first job in production, had to migrate 75 bank fractional T1 lines off a frame relay onto you know, BGP MPLS. So and even when you said Apple talk, I'm guessing

04:04
There's Apple talk running somewhere in the world. Like we think we're all modern and everything's great. But when I decomm the data center in Philly, you know, five or six years ago, we had a token ring switch. We took out like the stuff is out there. You know, it, might be running. Did you say five or six years ago, token, right? Whenever it was. I have the memory of a goldfish. We weren't running token wing, like it was in the rack. It was plugged in like, right. Like we  pulled it out. You know, it was still there. One thing I wanted to ask you about radio and

04:31
Going back to my studies, I always learned that there was a very clear distinction between layer two and layer three. So, you know, the OSI model, right? And please do not throw sausage pizza away. And I found that to be a helpful mechanism to understand the different things that the network  was doing. And you've said that the distinction between layer two and layer three isn't as clear as you might think  or as it's taught. What do you mean by that? What are we getting wrong about layer two and layer three as we're taught? Okay. So the layers.

04:59
is an excellent way to think about networking, but nobody actually does that. They take a layer and they subdivide it. And in theory, layer N is not supposed to look at any headers except for layer N. But, you know, for instance, a router is going to look at layer four, the TCP ports and this and that. But in particular, layer three and two is extremely messed up. So if you ask people, why do we have both IP and Ethernet, they will confidently tell you

05:29
Well, IP is layer three and Ethernet is layer two. Now let's think about that. What is layer two? Layer two is only supposed to be for neighbors to talk to each other on the same wire. And Ethernet, as originally invented, was just a bunch of things connected to the same wire to be able to talk to each other. Now, the header looks very similar to a layer three header. There's a destination and a source, but the layer three header has

05:58
a hop count in there. And the reason you have that is that there's no way to snap your fingers and have everybody change their forwarding tables simultaneously to the new topology. So in the meantime, packets are going to be all confused and going around in loops. And the hop count is a way to say, hey, let's just put you out of your misery until the topology settles down. Now Ethernet doesn't have a hop count. it wasn't that the people... Why?

06:26
Right. It makes me crazy. It wasn't that the people who invented Ethernet didn't know about Hopkins. It never occurred to them that anyone would be foolish enough to forward based on that header. So it was not intended to be forwarded.  Why are we forwarding Ethernet packets? And that's  sort of the whole story  of  how spanning tree came about and so forth. I could go into that if you want.

06:53
Can I pause you there for one second? I'm just thinking it through. mean, ethernet frames are forwarded hop by hop, right? Absolutely. Now you might say,  oh, but layer three is being forwarded with a router, whereas layer two is being forwarded with a bridge or a switch. And  yeah, it doesn't matter what you call the thing. If you have this thing that looks at the header and sees the destination address and then

07:22
looks at some forwarding table and decides where to forward it, it's exactly the same thing. With layer 3, it was always designed to assume that there's lots of links and you have a hop count as well. You assign addresses in a way that you can summarize a portion of the network with a prefix so you don't have to keep track of absolutely everything. But Ethernet was not intended.

07:50
to be that way. It was only supposed to be on a single link. think my brain just kind of broke in like a good way  when you said that forwarding and routing are like, basically, you're looking at a table to find out where to send it. It's like the same thing. That's something I feel like a lot of people are afraid to say, but we're all thinking of it.  So thank you  for setting that. Ethernet was supposed to be point to point when you say like a single link. Is that what you mean? Just from one end?

08:19
to the other because I'm having a hard time and I wasn't there, right? So I don't know that context, but layer two loops are so obvious to me now. And I'm amazed that the brilliant people who created this stuff didn't foresee  layer two loops and didn't put that TTL in, you know, but to your point, guess ethernet, the way it was designed and thought of, it wasn't going to go anywhere else. It was just going to go from A to B and be done. Was that kind of the right, right. And  usually when you say point to point, you think about two guys ethernet was kind of multi-access link.

08:48
which means you could have hundreds of nodes all on the same link, but anyone speaking could be heard by anybody else.  It didn't involve being forwarded. That beautiful half duplex conversation.  So do I have this right? Layer two and ethernet and frames are all the same thing. Is that correct? Like when ethernet was invented, frames were created and we put them in layer two of OSI. I'm going somewhere with this. Is  that all synonymous? I'm not sure what your definition of frame is.

09:18
Really?  ethernet packet. DataGrim? A data link. Yeah, like the data link. Right.  Cause I guess what I'm trying to figure out is when this was all invented, the layer two,  where I'm going is spanning tree. Eventually I'm assuming ethernet layer two frames, whatever the hell I'm trying to articulate here, it was invented and they never thought that it could loop in a topology. And it shouldn't have, because no one should be forwarding it. And if you don't forward it, it doesn't loop.

09:44
Oh, so this is good. So it almost sounds like they were going outside of the standard and doing things they shouldn't have and then created loops. Is that correct? Yes. So the story of how spanning tree came about  was  I was doing layer three. So, you know, routers and routing algorithms and all that. And then along came ethernet with great fanfare. And so everyone was saying, oh, great, this is the new way of doing networking. And they should have called it an ether link.

10:13
instead of an Ethernet. And so then they were building applications. They took layer three out of their network stack because they didn't need it anymore. The applications would work directly on Ethernet. And I tried to argue with them. And I said, no, you still need layer three. And they said, oh, Radia, you're just upset because no one needs your layer anymore. And I said, well, you may want to talk from one Ethernet to another. And they said, our customers would never want to do that.

10:41
So um no  one talks to me, no one believes me. So I was in a bad mood about all this. The things they built were making lots of money for the company because they were good things, but they would have been just as good had they done it properly on top of layer three. So the way Spanning Tree came about was years later when I was kind of bitter about the whole thing, my manager said, Radia.  Well, my manager realized that customers didn't want to talk.

11:09
from one ethernet to another. So he said, radio, we need to design a magic box that lets someone on this ethernet talk to someone on that ethernet, which is like what my stuff did. But my stuff required the end nodes to be aware of it and to put in a layer three header. So the constraint was figure out a magic box that  works.

11:34
even  without changing the existing endnotes that we've deployed that believe the entire universe is a single Ethernet, and there's no spare fields in the Ethernet header, and there's a hard size limit. They had actually already figured out that if this thing that they called a bridge just listened promiscuously to every port, and whenever they received something on this port, they forward it to the other ports, and that was fine, except

12:04
that it doesn't work with loops. So  that was something that late on a Friday, my manager said, know, Radia, you do these distributed algorithms things, figure out a way for no topology restrictions. So allow drunken monkeys to plug it together  with the constraint that we don't change what we have deployed. Oh, and also make it zero configuration. Then to make it a little bit more challenging, he thought he was being witty, I think he said,

12:33
make its scale as a constant. So no matter how many bridges and links there are in the network, the amount of memory necessary to run this thing should be a constant. And nothing's a constant. So linear might be  the best you can expect. It's probably n squared. And then he was away the following week. This was before email or cell phones.

12:54
So there was no way to get in touch with him. And that night I realized, oh my goodness, it's trivial. I can prove it works. It was such a trivial algorithm that by the end of Tuesday, I had the spec finished. It was 25 pages. And when the implementers started working on it, it just took them under two months to get it working without asking me a single question. So the spec was complete. And then I couldn't concentrate on anything else because my manager wasn't around and I had to show off.

13:21
That's when I spent the remainder of the week working on the poem. That was the abstract of the paper in which I published it. So I officially spent more time on the poem than I did on inventing the algorithm and writing the spec. I'm hoping you'll grace us at the end of the episode with Algorheim. So you created Spanning Tree in a weekend? Did I hear that correctly? Yep. Friday night I knew.

13:46
just had to do it and Monday and Tuesday I'd written the spec. Now that's unusual, correct? Like do you see, do you solve all problems that quickly and easily? Like are you just a genius and cause it took me  so much longer to learn spanning tree and lab it and see the ports doing a thing and buying the switches.

14:06
I it took me so long. And I often say this when I talk to networking people, as I'm learning things and they're so difficult, then I pop up a level and I'm like, but there's people who invented this out of thin air.  Like, how did you do this in a weekend? You just, was it like the beautiful mind movie? You just saw, you just saw it clearly? Yeah, kind of. I just look at things from different angles when then  the solution is kind of obvious. So in my book, interconnections, I have these.

14:33
little boxes to illustrate with a real world example, the point I'm trying to make. One of the points is scalability. And so the example I use is the wine glass clicking protocol, which works fine with maybe four or five people. But when you have 11 people and everyone has to click everyone else's things, it gets unwielding. But the example that is everybody's favorite, and it's 100 % true, is when I'm trying to illustrate that you should know what

15:01
problem you're solving before you try to solve it. So some people are like so excited about solving things that when they kind of vaguely understand something, they start writing code and then it turns out not to work in all cases, they write extra stuff and they come up with this monstrosity. So that's a real problem in this industry. So the example  that I give that will make people understand, think about the problem first before you try to solve it is that when my son was three,

15:31
He ran up to me crying, holding up his hand saying, my hand, my hand. So I took it and I kissed it a few times. What's the matter, honey? Did you hurt it? And he said, no,  I got pee on it.  Perfect. Perfect analogy.  So yeah, so anyway, this whole spanning tree stuff.

16:00
I thought of it  as  something that would last for a few months until we could fix the end notes to put in layer 3, because spanning tree is not a very good layer 3 protocol. It doesn't give you optimal paths.  Certain links don't get used at all. I mean, it's a very cute, simple algorithm, and that's nice, but it would be much better to do it with a true

16:26
routing protocol. That's what they ask you. Like back then too, I know that bandwidth was expensive, right? They were trying to get protocols to be less chatty because the links were so bandwidth constrained and you're shutting down entire interfaces, right? And spanning tree to kill loops. And I'm surprised the problem must have been big enough that they were willing to just shut down entire interfaces on devices  to prevent these loops. Cause that's a big cost associated with. Right. Well, it's the only way  if you're working with this header that was not intended to be

16:55
forwardable and yet you want to glue together various links. So  if we have a destination and a source address,  like MAC addresses as opposed to IPs, mean, to me,  I'm a simpleton, it seems forwardable. So why wasn't it forwardable? Well, for instance, it didn't have a hop count.  It's not really like Ethernet could replace a layer three protocol in the internet. There's sort of no way to summarize addresses. Everybody kind of has their own.

17:25
unique permanent address no matter where you're plugged in. It's not how you would design a true network. It's a fine way to design a single link. But yeah, like within a year after the spanning tree stuff happened, CSMA-CD, which was the original ethernet, died out. It doesn't exist anymore except, you know, on wireless. What an ethernet is today is just all point-to-point links.

17:52
with switches running the spanning tree, which is um not  ideal. Now I could explain an alternative that is like much better. Should I get into that? Yes, please. I'm going to say yes. I'm super curious.  Right.  So  there was a competitor to IP called CLNP. It was ISO's version.

18:14
And like, what is there to a layer three protocol? There's a header with a source and a destination and a hop count. Well, CLNP had a 20 byte address. Now, not only was the address bigger, but it had this subtle property that I wish everybody understood and they don't,  you know, even people that work in networking forever. The way the CLNP address worked is that there was a 14 byte prefix.

18:41
that worked like IP, where you could have as many levels of hierarchy as you want. But in IP, an IP router thinks that the  end is a single link. If you move from one side of an IP router to another, you have to change your layer three address. This was not true with CLNP. With CLNP, everybody in a large cloud with lots and lots of links all shared the same 14 byte prefix. So routing on the

19:10
14 byte thing would get you to  a cloud. And once you were in the cloud, you would inject it, but inside the cloud you would route based on the bottom six bytes. So, you know, in the end nodes within the cloud would let the routers know where they were. So this makes everything so much simpler. You don't need ARP  in IP. Once you get to the link, you need to do this ARP.

19:34
thing to find out what your address is on that link. But with CLNP, it's right there. But also, you can have a cloud with a flat address space where you could move around within the cloud and keep your layer three address. Also, within a cloud, there was zero configuration. You just plug it together and everything works. Whereas with IP, you have to configure everybody to know what addresses are on which ports. But here, you just

20:02
plug it together and you have to tell everybody what the 14,  tell one person what the 14 byte prefix is. And that just was, you know, it is so superior to IPv4 or IPv6. Is the prefix the destination address? Like if I want to send you something and I go over a CL, so it's connectionless,  what's it called? Connectionless network protocol or whatever, yeah. Yeah, yeah. So how,  how do it know?

20:30
Yeah, what is a, is there a lookup table associate, I assume of some kind? How does it find you without a destination address? Is that in the prefix? There is a destination address, you know, through DNS or whatever, or more likely kind of an end node would be the first one to make a connection to somebody else and they would just reply it. But the rule of a router is, hey, if the 14 byte prefix is not me, then I will.

20:59
use that 14 byte prefix to get down to the cloud. And once I get to the cloud, then everybody shares the same prefix and I'm routing based on a different field, which is the unique ID within the cloud.  of sounds like, I don't know, I'm kind of too inexperienced to really it sounds like routing within routing almost.

21:19
Well, it was kind of two levels of routing. One was the 14 byte prefix where you could have as many levels of hierarchy as you want, because you're doing it based on prefixes. And then once you get to the cloud, you're routing based on the bottom six bytes. So with IP, instead you have to have cluges like spanning tree or VXLAN or whatever to disguise a cloud to look like a single link to IP. Whereas here,

21:47
layer three was doing the whole thing. so it's a single protocol essentially doing the job of what we right now have like multiple protocols doing. Absolutely. So  people actually suggested in 1992, they said, you know,  IP, the addresses are too small. Hey, why don't we  use

22:07
CLNP, which actually we had adopted for DECnet. So there were very large deployed networks out there. All the vendors had implemented it, so they were all in favor of it. Someone figured out how to port TCP to work on CLNP, in which case all of the internet applications automatically worked because they all hooked onto TCP. And if there hadn't been silly resistance, the world would have been working

22:35
on 20 byte addresses in 1992. That was what people were suggesting. But then some very vocal people were saying, no, no, we can't do that.  in CLNP, replacing IP with CLNP would be ripping the heart out of the internet and putting in a foreign substance. And it's not like CLNP is any less compatible with IPv4 than IPv6 is.  Another thing they complained about was they didn't like ISOs layer six.

23:03
And it's like, fine, we're not talking about that. We're talking about the layer three packet format. And there were other silly reasons. yeah, standards bodies always have incredible egos. So they say, oh, we're all geniuses  and we shouldn't even waste our time learning what other standards bodies are doing because they're all idiots.  they said- Have you been in those meetings? Have you had to argue for different protocols? I gave up. It's just too ugly.

23:32
Yeah. That's awful. I have, yeah. And they don't listen probably, right? So, so I want to ask a radio type question. I'm trying to pop up a level and thinking like systems and problems we're solving. Cause I really like how you talk and like what problem are we trying to solve? So I think correct me if I'm wrong, CLMP, IP, the problem they were trying to solve was layer three, I guess, which is how to get LANs talking to other LANs. Cause you had to connect them with IP layer three. that, is that correct? IP was always intended and CLMP was always intended to create an entire path.

24:02
You go from link to link to link. The links don't have to be ethernet. They could be point to point links. They could be token rings. The issue with spanning tree though, was that people didn't have a layer three protocol in their network stack. They thought, you know, the applications were assuming the entire universe was a single ethernet. um What problem does CLNP solve for better than IP solves for? Cause I think we went to IP because humans are goofy.

24:31
So what is that problem that we're solving? I mean, in my simple brain, it's layer three, right? It's routing, but I guess you guys didn't go to the table and say, let's solve routing. What was that original problem IP and CLMP were designed to solve? Routing.  to be able to create an entire path. But the thing was that  IP didn't allow for having a cloud.

24:51
with a flat address space with a lot of links in it that you could like a data center where you could move around and keep your address.  But CLMP did because it had this bottom  level of routing that routed within a cloud based on the bottom six bytes. So that would give you the MAC address mobility. Not having to do all the VXL and EVPN nonsense that we do now. CLMP would do that for you. Right.  So yeah, let me rant a bit. Why is it called an address?

25:18
this MAC address thing. Like an address should be something that changes if you move. It really should be called an ID because it's kind of wired in. But then what's a MAC?  Everyone sort of talks about MAC addresses though MAC means something. And I even know what it means that, you know, it's sort of weird standards gobbledygook, but it doesn't make it any more descriptive to humans to call it a MAC address.  Anyway, yeah.

25:47
Media access control doesn't mean anything to anyone.  Nobody knows. for me. Nobody knows. You know what's great? You know, know, I love these conversations, Lex is,  you know, radio is talking about a time that like routing didn't exist. Like my brain, I can't even get my head around. Right. Because you, yeah, because you learn the prescribed stuff in CCNA. No, you know, shade to CCNA, Cisco, Net-a-Cad. But like as a beginner, you learn like this is how it is. This is how it's going to be. This is how it is.

26:14
for you, like this is how you learn, know, and then you slowly gain experience and then when you start hearing from, you know, geniuses like Radia, like the people who are actually there, who had to think about it, it's super mind blowing. um And because of how I was taught, I think in part, I can't even imagine a world,  like how could you even call it a network if you didn't have layer three? I think it's because it was all layer two, right? I think that, I mean, I kind of got lost in the sauce like earlier, I wanted to ask you, but I didn't want to you down.

26:43
I was aware of, you know, Ethernet's history a little bit as far as like it wasn't made to be point to point, but it still is hard for me and they still have, you know, like. uh

26:53
What is it 10 based TL one L or something, you like they've got some like newer ethernet flavors, right? That are like still a common bus and everything, but it's not super common. Like if you just like anybody with their CCNA probably doesn't work on like a random industrial network that has like, you know, common bus or whatever  for a bunch of nodes. So we still like to think of it as like point to point ethernet and like layer two,  layer three. And I don't know, it's, it's mind blowing to get out of that space, but I'm convinced that that is where innovation.

27:23
So, you know, where I started, I was the one doing layer three for digital equipment corporation for, for Jacknet. There was, I think only one other network that I was familiar with, which was the ARPANET. So they originally had a protocol like RIP and that was called the old ARPANET algorithm. Then  they had replaced it with what they called the new ARPANET algorithm, which was more like link state. So.

27:51
I told my manager, I mean, this was a great time for me because I didn't have to fight with standards bodies or anything. I just kind of got to design it. I said, I like the new ARPANET algorithm. I'd like to use that. And he said, well, he was never convinced that was stable. If I could prove it was stable.

28:09
He would let me replace our algorithm, which was very similar to RIP with this new thing. And I'm always better at counter examples than proofs. And I realized, oh my goodness, it's not actually stable. Yeah, a few mangled packets and the network would be down forever. So like if your PC gets into a wedge state, you reboot it. But how do you diagnose and fix a network? Well, you send network management messages on the broken network.

28:36
Well, if the network is broken,  I realized the problem with the ARPANET algorithm. know, pretty much my first paper said networks have to be way more resilient than like a PC because you're trying to use it  to fix it. This is the problem with the ARPANET algorithm that you just throw a few bad packets in there and it will never recover. And so I said you have to design it to be what I called self-stabilizing.

29:05
Which means that once you get rid of whoever's injecting bad packets, the network should return to normal operation. That was one of the innovations that I did was making things far more resilient. Now, would I be able to understand the why? Because one of the questions I wanted to ask you when you design routing for what were you trying to improve over the ARPANET algorithm? guess resiliency is the quick answer, but, I probably wouldn't understand the minutia that you would try to explain to me right on.

29:31
what you fixed. This is like algorithm stuff, math I'd never understand probably. Well,  it isn't heavy math or anything like that, but you know, without a picture, it's probably not as, but I mean, just sort of trust me on that. The other thing I did was that before that, the assumption was that anyone involved in routing, of which there were maybe three people in the world, were these incredibly  genius people.

29:56
and they had to be the ones that design it and manage the network and write the code and all that and configure everything. So  at Digital, we were trying to sell networks to actual people that should be able to manage it and all that. I also made it far more easily  and safely configurable and also much more scalable. So I did some things like that that improved it. I mean, I have a story I could tell about configuration.

30:26
If you have to configure things, first of all, try to make everything not need configuration, but sometimes you need configuration. At least make it so that you can't set something to a bad value. So if the only legal values are between 20 and 30, don't let somebody set it to 791. So that makes sense, and that's easy to do. But sometimes you have a perfectly legal value here and a perfectly legal value here.

30:54
but they can't interoperate. And so a great example of that is a  protocol I was never  able to explain to my otherwise bright college-aged son, which is that there's no such thing as a reliable, I am dead now message. So you have to periodically call your mother. And there's an opportunity for a parameter mismatch,  which is how often you call your mother.

31:20
and how long she waits before calling the police.  So that was like a little thing that I put into ISIS, which I didn't think was profound enough to be patented or write a paper, which is that in the keep alive message, which I call the hello message, I say, Hi, I'm radio, expect to hear hellos from me every 30 seconds. And so the neighbor says,

31:48
Okay, I'll multiply that by three  and assume that the link is down or you're down if I don't hear from you for that amount of time. Now, it must not have been  that obvious because OSPF basically tried to copy ISIS and make it like way more complicated for no good reason. They noticed  in the hello message,  you stated what your hello timer was.

32:15
But what they did with it, it says that  if you receive a hello from your neighbor that says it's going to send hellos every 30 seconds, you compare that value with your own configured hello. And if they're not identical, you refuse to talk, which is just, makes it work really brittle. And why shouldn't you be allowed to have different timers on different things? And I've been sort of nagging them about that for years  and uh people cannot.

32:43
possibly ever admit that they didn't  find out everything from tablets in the sky and it's awesome perfection.  I always wondered what the reason was for things like that, uh where timers need to exactly match or like, I can't remember exactly off the top of my head, the EIGRP stuff, but I remember EIGRP also has some things like that where if we don't match in our configuration, we're just not, it's just not going to work. That always did bother me, but I never understood.

33:12
why, you know, like I assumed there was a good reason, but you seem to be like, maybe there wasn't a good reason. Radia says there are no good reasons for any of those rules they make us learn. Right? That's kind of the take away. So the OSPF people said they think their way is simpler was their excuse for not sort of adjusting your listen timer to your neighbor's hello timer. So OSPF, they said, okay, we kind of like ISIS.

33:40
We want our own protocol.  Then people said, excuse me,  just use ISIS. It doesn't care whether you're rooting German or Italian or whatever. It can root anything. Again,  was like, well, we think if we design our own thing, we'll get the Nobel Prize for routing or something.  We want to design our own thing.  OSPF basically said,  okay, we know that addresses are four bytes long. It was hard-coded.

34:08
to IP, whereas ISIS was you can put in any size thing you want. And then they did all this other stuff that made it way more complicated. But the basic bones of it are the same. So if you say, well, I haven't heard of ISIS, I've heard of OSPF, it's really the same  protocol. At what point do you say this is a totally different thing, rather than it's just a  modification of the other one?

34:37
Andy, did you learn about ISIS when you  took the CCMP? remember?  I never heard of ISIS until Russ White said it for the millionth time somewhere. And then I had him on the show. So I learned about it a few weeks ago, talking to Russ, oh which is part. Yeah. So then it was kind of a connection to radio because I think radio that what is it that the DECnet algorithm kind of became ISIS or some kind of connection, right? Yes. I so adopted it.

35:03
as their routing algorithm, we adopted ISO's packet format, the CLNP thing. so ISO, unfortunately, renamed it ISIS, which stands for Intermediate System to Intermediate System Protocol. And then, I don't know, probably 11 years ago or so, Trump said that Hillary and Obama invented ISIS. And a bunch of my friends noted the and formatted it to me and said, you need that credit.

35:33
You know what cracks me up is these kind of these little nerd wars, right? Like you had ISIS and then somebody said we need OSPF and you had like it just seems to I've been taking notes throughout. You know, there's these little kind of no, it must be my protocol and this one's better. It's more simple. And like what drives that? Is that just human kind of silliness? Because there's no I don't think there's any monetization tied to it. Right. I can see like a networking vendor pushing for their thing because they want to sell it.

35:59
That's right. Why would governing bodies- Is it not, at least?  Sure, But is there money behind? It's ego, right? Yeah. Absolutely. We want to win. Our thing is the best and we want to win. My name will be on it.  So an example, I wasn't hanging out at IAAA and they adopted the spanning tree algorithm. They took the 25  page extremely  clear spec and turned it into this like 300 page monstrosity.

36:28
that was really hard to read and it  didn't change the algorithm in any way, which just made the spec really long. Then I guess years later, I found out that the people on that committee, mostly the chair,  really hated me. I'd never met him because I got credit for having invented the spanning tree algorithm when all I had done was invent the algorithm, whereas he's been chair of this committee all this time.

36:55
So they made little changes to it that any, any sane universe wouldn't even be called another version.  And, know, some of the changes were good, you know, little fiddling with the timers, other changes I'm very suspicious of it makes it very complicated or whatever. You know, they say, Oh, we don't use that horrible legacy spanning tree thing anymore. Instead, we use this fantastic rapid spanning tree protocol.

37:25
And  it uses all the same packet formats and all that. So it's wonderfully compatible. Yeah, that's just sort of an example of these standards. But I don't get the impression that you're the type of person that sits around worrying about this nonsense, but do you have any theories on why they would try to undermine your contributions and take them for themselves? Andy.  Yeah, I mean, that's that's very hard to answer. I mean, it's it's all  ego. It's so gross.

37:53
Yes, it really is. I'm enamored by your brilliance and what you've contributed to our industry and to think that I could spend my days then going and trying to steal your stuff and make it my own by adding nonsense. just I don't know how some of these people sleep at night. Right. Yeah, that's fair. OK. Yeah. Do we want to beat up on BGP? I hear you don't like BGP and I actually like BGP, but I'm not about to have a routing protocol. I'll join the BGP hate train. Let's do it. Let's go.

38:22
So you said you don't like it, right? Let me say something that, for instance, if you're designing something, you should steal all the good ideas you possibly can. It's even better to attribute them to who did it. But it's  very silly to invent in a vacuum without understanding this stuff. At one point, someone oh mentioned to the OSPF people, oh, this is derived from ISIS. And they said,  no, it isn't. We didn't get a single idea.

38:52
from ISIS. All the ideas in there are completely ours alone. We didn't even look at ISIS. And that's a terrible way to do engineering. You shouldn't brag about how you purposely remained ignorant. And it wasn't true either, but you should really understand alternatives rather than saying you want to start from scratch. Right. And they weren't like, you know, I don't like it. I don't want to hear it. It's not, you're right. What a strange way to

39:20
move things forward by ignoring what came before.  friend, So you want me to talk about VGP? Yeah, let's, let's talk about VGP. But it also reminds me of that, uh, oh my God, I'm blanking on her name. You have me so nervous. I can't remember my very good friend's names, but she talks about,  there's this  parable or something about a fence. People just come and rip out a fence without thinking maybe there is a reason for it. So like just tearing things out without thinking of why they were, or trying to invent something new without seeing, you know, what was there before. It's just, I don't know. It's, it's a very odd way to...

39:50
to go about  the world. You don't like BGP. Ross told me you don't like BGP and I needed to ask you about it. Okay. Well, BGP is incredibly fragile, incredibly  configuration intensive, very slow. But let me give you sort How dare you?  Let me kind of give you  how it came about. Originally, there was EGP and that was just like RIP, but without-

40:17
any metrics. so you had to be very careful not to have any loops in the Internet and people would configure,  would plug the Internet wrong and the entire Internet would be down. So I actually asked the person who had designed it because it was after RIP. Now he believed that routing was  so incredibly arcane that you couldn't possibly be able to specify it well enough to have multi-vendor implementations.

40:47
So within  a domain,  all of the routers would come from the same vendor, but then they needed a way to talk between domain. And so  that was why he came up with EGP. So I said, but, but EGP is a routing protocol. And thinking to myself, it's just a really not good one,  but I didn't say that aloud. And he said, no, it's not a routing protocol because there's no metrics in it. So in his mind, he had this  belief

41:17
that you couldn't specify a routing protocol to be inter-vendor. If you wanted to hook together domains, this would have to be something that you specified and have different vendors. If he designed something that was so broken, nobody would call it a routing protocol anymore, then it didn't violate his axiom. EGP was just this  ridiculous thing  made with this weird assumption that

41:46
It couldn't be a true routing protocol or something. don't know. reasons people make decisions.  just can't. Absolutely.  Then  they wanted to have something better  than EGP. They had to. mean, the internet would... I'm sorry, quick interruption. What was running before EGP? Like what was ARPANET, TECHNET? how were they... Was BGP invented for the internet? Like did it predate the internet? Like why did we need BGP?

42:13
What problem was that solving? EGP was there first, right? was a replacement to EGP.  what was... And is that what the internet was running on first, EGP? Yes, EGP was the first thing. Now, ISIS could have done it all because you could have as many levels of hierarchy as you want with ISIS. You know, that's another thing. Why do we need BGP? Well, people will say for scalability. No, you can just have yet another layer of link state routing.

42:41
where you draw bigger circles so that the people at this layer don't have to know what's inside that layer. And you could make the internet as big as you want. So the only excuse for BGP is policies. So  what are policies exactly? So when I complain about BGP, people say, well, could you come up with something better? And what I say is...

43:05
I'm sure  it would be possible to come up with something better, but I don't like solving things unless I know what problem I'm solving. Can you please write down what these policies are that you can't live without? Which ones are sort of  nice, but you could live without it? And their minds are so polluted with BGP, they just talk about which knobs in

43:28
BGP they're currently using. couldn't articulate the problem they were trying to solve to you, they?  They don't know what problem they're solving.  Yeah. For instance, there's a perfectly reasonable routing policy that BGP doesn't do, which is giving  me as a source a different path than you as a source. Basically, if we both have to go through some router 12 hops away, we're stuck with whatever that router chooses.

43:58
to get to the destination. We don't even find out about the other paths. So it could be that  I really want my data routed according to NATO countries  and you want it routed according to  non-NATO countries or whatever. BGP doesn't do that. So that's certainly a very plausible policy that you can't do with BGP. obviously BGP doesn't- When you say policies, we're talking about route filtering, is that-

44:27
correct what prefixes you're gonna let in and not basically? Well, yeah, and also which route you choose. So with BGP, all of your neighbors specify what path they use to get to the destination. And you based on your own policies, choose a path to the destination. And then everybody on the other side is stuck with what you chose. That never occurred to me. Right, unless you manipulate prepends and stuff like that, right? Is that true? Like I'm thinking in my WAN days, we used to...

44:56
add AS prepends to certain paths to move traffic to where we wanted it. Right. So you could tunnel things over if you really needed it.  That gets really complicated. So what was so bad about EGP?  I know you said it was awful, but... EGP just had no metrics.  All it said was, these are the destinations I can reach.  And so  if there were loops in the internet, they would never go away.

45:24
And you couldn't specify what path you would like to take. Nope.  They were just out there. That was added for BGP. So what happened was that it was clear that the world needed something better than EGP. So the BGP people were implementers and they threw it together and they deployed it. And now we're kind of stuck with it forever. Whereas... Well, we could have used ISIS, right? Is that what you said? We could have used  an existing protocol. So there was a different working group in IATF called

45:54
IDRP, Inter Domain Policy Routing. And  they were doing what I kind of would expect to do, which was a link state thing where maybe you would say, this link has this property. So if you want to create a path that is all NATO links,  you'd find a path. You could use whatever the internet just happened to choose as a default, or you could set up your own.

46:21
path  if your policies didn't like it or whatever. That's what I preferred. And so I would tell the BGP people, actually, this other way of doing it is better. And they said, fine. Now,  unfortunately, the  IDPR people were academics. And so they had  all the time in the world. And they were occasionally writing papers. They were distracted with other things. And the BGP people, when I said that was better, they said,

46:51
fine if they ever get their act together and have something  that can be implemented, we could step aside, but they sort of never  got their thing  to a point where it could actually be deployed. And that's kind of why we wound up with BGP. That's so funny. Sorry. Learning the history is cracking me up because it's like,  this group and this group and they just, you know, just that we're all humans.

47:19
You never know unless you are friends with radio, right? This stuff isn't published. You should write a book, radio, or maybe this is what you're doing by talking about it now. about the internet and protocols that were invented just because someone else beat someone to it. That's wild. I mean, it doesn't surprise me, but it is crazy to learn still. We're running out of time with you, radio, and I want to be respectful of your time and not keep you up all night. So I don't know if we have time or if you want to save it for another time, but uh you mentioned you're working a lot on

47:48
cryptography security. And I don't know if you wanted to touch on any of that if we if we have enough time, really what I want to know is what are we going to do about what's it called quantum day or Q day or God, I don't understand I don't understand cryptography enough to even be able to like explain it. So this could probably be 50 minutes from you explaining it. But cryptography is everywhere. We need it for all the things. And I think quantum computers are going to break it all soon and all hell is going to break loose. So I hand that mess to you. What do we say about all this?

48:17
Okay, so there is a bunch of misconceptions about quantum and I always,  you know, hate to see people wandering around with misconceptions. I sort of want to grab them and say that. So one misconception is that a quantum computer is just bazillions of times faster than a classical computer and any program that runs on a classical computer would run  jillions of times faster on a quantum computer. This is absolutely false.

48:47
A quantum computer is not faster, it's different. And there's only a very small uh set of problems that a quantum computer could do any better than a classical computer. Another thing that people say is that a quantum computer will break all of cryptography. And that's not true.  It will only break the public key algorithms that are currently deployed, like RSA and elliptic curves and Diffie-Hellman.

49:15
And that's because of a particular algorithm that would run on a quantum computer called Shor's algorithm. Now, we're not uh really near to having a quantum computer that's big enough to break our current public key sizes of RSA. But just because we might, the world needs to  replace those with other algorithms, which have the unfortunate name of

49:42
post-quantum algorithms. So you hear post-quantum as like, oh, quantum is so complicated. Post-quantum,  post-quantum algorithms are just normal algorithms that run on normal computers. They're incredibly cool. Yeah, actually in our security book  called  Network Security, Private Communication in a Public World, in the third edition, we actually um describe what a quantum computer is, how Shor's algorithm works, and what some of these new

50:12
algorithms look like. At any rate,  long before there will be a quantum computer capable of looking at someone's RSA public key and figuring out their private key, which is what it means to break it, we will  no longer be  using those algorithms and we'll be using perfectly reasonable other algorithms that run on

50:34
Classical computers  that they're just based on different names. I didn't realize that yet. It's almost like a doom and gloom Oh, no, once that happens,  everything's gonna stop working. But folks are working on the new algorithms that don't require quantum computers. Okay. Yeah, my my bias was like, oh, quantum is gonna break everything and and that'll be it. What's up? Right. People believe eventually, you know, all your laptops will be quantum computers or something, you know,  classical computers are not going to be replaced.

51:04
There might be a few quantum computers in a cloud that you could rent time on or something, but they're not going to be ubiquitous. guess I don't fully, sorry, I'm a little slow with this, what makes,  I guess the post quantum  algorithms  uncrackable by quantum computing? Like what is it that makes them different than our classic ones that we have today? What makes the new algorithms?

51:29
unbreakable. Now, first of all, nobody really knows whether something is unbreakable. You just sort of have faith.  But they're based on different math problems. So the particular math problem that Shor's algorithm does is that it can factor numbers. And it's like, who cares? I don't need to factor numbers. But  the security of RSA requires that it be hard to factor numbers.

51:55
So if there were way to factor numbers, I would be able to figure out your private key from your public key. So if we kind of waited around until some nation state or whatever had algorithms for that, that would be a disaster because  when you use HTTPS, everyone is authenticating themselves by proving they know the private key associated with the public key and their certificate. But these new algorithms give the same

52:23
purpose, the ability that you can sign things  and authenticate using a private key. But Shor's algorithm will not allow them to break it like it would with  RSA. Now you think, well, maybe there's some other algorithm, but the kind of math they're doing, they're sort of hoping that there wouldn't be any way of breaking it. Now, as it turns out, a lot of these algorithms that were submitted did get broken, but they weren't broken with weird

52:52
quantum algorithms. were  broken based on classical algorithms. So at any rate, we kind of trust the cryptography community to stare at these algorithms long enough, have proofs and whatever that we can feel reasonably secure with them. Okay. Got it. That's so interesting. Wow. So, okay. I feel better, Andy, about the end of the world, at least in that.

53:17
specific regard. Well, there's a million dollar scenario.  It's funny you say that because my last question to Radia is,  will AI kill us all, Radia? No. Is this the end of humankind?  We made it to the end and didn't say AI, but I can't get off  with Radia not saying something about AI. Is this the end of us? Are we all out of  jobs here?

53:41
The end of us in terms of like the terminator movies and I'm not worried about that. But in terms of putting us all out of jobs, I feel really bad for  young people in this industry because it will cause a lot of jobs not to exist anymore. So the AI people say,  oh, don't worry about it.

54:04
It's just that the people will still have their jobs, but they'll be able to work smarter because they'll have AI. I don't believe that. Yeah.  So that's  really, really scary. Now other people say, oh, well, with AI, you could inject fake news and stuff like that. And in terms of videos and all that,  we already could do that, you know, with people just saying something on the internet.

54:31
and the way the internet, the bots try to keep you engaged. So they figure out what you want to hear and they'll feed you more and more of that. So I think that's sort of what the end of civilization is going to be, which is the way that the internet divides us and the  absolute hate and the  end of truth. So like if I'm giving a talk and I...

54:57
talk about the doom and gloom of, you know, it's the end of the world because there's just no such thing as truth and, you know, whatever.  I say, but, you know, I'm speaking, I'm usually speaking to students, but you guys are students. Wouldn't it be terrible if I told you, we're leaving you this perfect internet and there's nothing more for you to do. This way, we're doing you an incredible favor, which is, it's,  it's horrible. And there's all these things that you can work out.

55:28
It's troubleshooting task.  Let's do it. The title of the episode will be, Radia Pearlman says computers were a mistake. uh Radia, this has been lovely. I could talk to you forever. I really appreciate you coming on. I have a million things  I could keep asking you. Is there anything that I should have asked you that I didn't? Anything, any parting thoughts from you? No, I don't think so. This was really fun. How did I do? How was it? How did we do? Did you enjoy?

55:57
Did you enjoy your time with Lexi and I? hope it was okay. Yes.  Thank you so much. It's been such an honor. You know, you're a hero of mine. I don't know.  I know it's weird to hear that. And I've heard you talk about, you know, people saying stuff to you about like being a woman in tech. And I know that that gets super old, but thank you for being here and thank you for existing and talking to students and everything that you've done. Thank you for continuing to put yourself out there. I know that takes like a lot out of a person and I don't know.

56:27
It means a lot. thank you. Thank you for being here. Yeah, thank you. I had a great time.  Yay. I'm going to do my silly little sign off. uh When I'm finished, would you bless us with a reading of Algarime? Or are you like, I want nothing to do with that, buddy.  I don't like spanning tree. I don't like what they did to it. The stupid rhyme. I love your poem, but would you like to read it or is that not something that would interest  So um I don't have it in front of me. Hopefully I remember it. So yeah, that poem is called Algarime.

56:56
As in every algorithm should have an algorithm. So as I think that I shall never see a graph more lovely than a tree, a tree whose crucial property is loop-free connectivity, a tree which must be sure to span so packets can reach every land. First, the route must be selected. By ID, it is selected. Least cost paths from route are traced. In the tree, these paths are placed.

57:24
A mesh is made by folks like me, then bridges find a spinning tree.  Thank you.  Radia, you're a treasure. Thank you so much for being here. Lexi, always fantastic seeing you for all things Art of NetEng. You can check out our link tree, linktree.org slash art of NetEng. It has all the things, including our Discord community call it's all about the journey. No, it's all about the journey.  Discord server, thousands of folks in there helping each other.

57:50
Pass exams, study things, do home lab stuff. If you don't have a community, you can check it out there. Do not trudge this road alone. You don't have to, it's better with friends. As always, thank you so much for watching and listening, and we'll catch you next time on the Art of Network Engineering podcast.  Hey folks,  if you like what you heard today, please subscribe to our podcast and your favorite pod catcher.  You can find us on socials at Art of Net Eng, and you can visit linktree forward slash artofneteng  for links to all of our content.

58:16
including the A1 Merch Store and our virtual community on Discord called It's All About the Journey.  You can see our pretty faces on our YouTube channel named the Art of Network Engineering.  That's youtube.com forward slash art of net edge.  Thanks for listening.