S1E6_Radia_Perlman Spanning Tree Protocol SharkFest 2023 Network Security Quantum Blockchain

Welcome to an exclusive interview with a true networking pioneer and Visionary Radia Perlman, the renowned computer scientist and inventor of the spanning tree protocol. Keynote speaker for the upcoming Shark Fest Conference, Radia Perlman has made invaluable contributions to the field of computer networking.

We have the privilege of diving in on her remarkable journey and gaining insights from her wealth of knowledge. Let's dive in to the interview. Hello. Hello. It's nice to see you and thank you for indulging me with this interview today. If there was someone. That was the president and chief executive of your fan club.

I would be that person. There you go. So I just got finished talking to a group and many of them were women. And so I took this as a little something to share with them. The book on the profiles of amazing Women. And of course I pulled out. You're amazing woman profile here, and I share this. I have four daughters, so I am very interested in helping women find their place and voice in the technical world.

And you have done such an exemplary job of paving the way for female technologists in the industry. And so we are all very thankful that you have paved that way. Some of the things that I just kinda like to know is, of course we know that you invented the spanning tree protocol. And I just recently diagnosed a big problem with about 50 different data centers where they did not have spanning tree configured in the core of their network well, and it was causing loops, and it was causing their entire data center to be slow for several years and went and found the source of the problem.

And it really is an epidemic that people don't really know how to set the priorities. They don't know how it breaks the ties of Spanning Tree. And it's actually brilliantly designed and quite elegant. And so I wonder why people don't embrace it more. But after we found these loops, I asked them, I said, because they fixed it.

They cleared the loops. And I said, How did you do that? Did you reconfigure spanning trees? So they block their correct paths , and they wouldn't answer me. So I knew what they had done. They had just removed the loops. They just turned off those circuits. So it still is something that.

Although it's automatic, people don't really understand some of the elements of it, but they, nevertheless, that protocol is incredibly necessary for every type of network at layer two to utilize. And I'm just wondering, what do you hear about something that you developed out there and people have been using it successfully for?

Dozens of years now. Do you have any thoughts about how people are using it or not using it, and what are some of the thoughts that you have or maybe recommendations for the industry when they talk about spanning tree? Okay. Spanning Tree was a hack that was a short intended to be a short term fix for the fact that when Ethernet came along, people thought this was the network.

Instead of what my career had been all about, which was what people refer to as layer three. Now, what layer three of the networking stack is, you put your data in an envelope and you say who the source is, who the destination is, and a Hop count. And then the layer three switches, people call them routers.

It doesn't matter what you call them, have a forwarding table and they forward it. But given that you can't have a topology, that instantly changes in case there are changes. You need to have the Hop count because there might be temporary loops. So temporary loops are not that bad with layer three because there's a Hop count

Now, nobody Ethernet was intended to be layer two. Now, what layer two really is supposed to mean is you send a message to your neighbor. You're not supposed to have a device that forwards it from link to link. Yeah, so that the problem was that people built applications directly on Ethernet without layer three, and I was alarmed by that.

Ethernet came along with such big fanfare and I was saying, no, you still need layer three, and people said, Oh Radia, you're just upset cuz no one needs your stuff anymore. And I said, but you may wanna talk from one Ethernet to another. And they said, our customers would never wanna do that. Their stuff was good and they made lots of money for the company.

They would've made just as much money had they done it properly, which was on top of layer three. But it's hard to explain to managers why this group that was making money for the company had done something bad. That was how the spanning tree thing came about, which my manager said, oh, Radia, you do distributed algorithm stuff and we need to have Oh, yeah.

And surprised. Some customer said, Hey, we really would like this application to work across more than a single Ethernet. And a single Ethernet could be within a single building, support a few hundred nodes. So the constraint was design something that will work even though the end nodes don't have layer three implemented and there's no extra fields in the Ethernet header.

And there was a hard size limit. So that was the concept of just having these devices mindlessly forwarding from port to port, which of course doesn't work if there's loops that was just mindlessly forward, but have some sort of algorithm that figures out a loop free subset of the topology. And I thought this was a bad idea because you really shouldn't be forwarding a header that doesn't have a Hop count.

It's irresponsible, but whatever. It didn't really matter, even though it was a dangerous kluge because it was only going to last for a few months until people fixed the index and put, and so here we are today and spanning Tree is everywhere, on every network, on every little switch that we buy for our home.

It's. Everywhere. Did you ever, obviously, you just said that you didn't think it was gonna need to be lived longer than a few months, but now did you ever dream that it would be so ubiquitous? Not at all, nor did I yearn for that. Yeah, as I said, the proper solution would be a layer three thing, but for subtle reasons, which I think I'll get into at Shark Fest, IP is not the ideal layer three protocol.

People don't think about that. The way networking is taught is as if TCP/IP arrived on tablets from the sky, and it's awesome perfection doesn't occur to anyone that things could work any differently. And the problem with IP is that if you move from one side of an IP router to another, you have to change layer two address.

And that's not inherent to layer three. It's inherent to ip and there was a competitor to ip. At the time, which was done by ISO and it was called CLNP stands for Connectionless Network Layer Protocol, and that had a 20 byte address. And what's really a subtle but extremely important advantage of that was that.

There were sort of two forms of addressing. You could have a large cloud with lots and lots of links, and inside there was no configuration of the routers because everyone shared the same. 14 by prefix. And you could Hop around within that cloud and keep your address. So the way routing worked was the first 14 bytes worked like IP, where you could have as many levels of hierarch as you wanted, but where IP thinks that the final thing is a single link, that IP just sends it here with CLNP, the routers would say, oh, this is my cloud.

And so therefore, then it would route based on the bottom part where it would route individually to each end node within the cloud. So that was a much better solution. Now indeed, knowing the danger of spanning tree, it's so fragile, like without the hot count. I also hate computers and I'm not a hands-on person, but I like to design things so that people don't have to understand.

The what's going on, you should just be able to plug it together and it should just, but don't you think you did that materially with the spanning tree protocol and the default MAC address, breaking all the ties , because it really is auto magic if it's not a very complex environment.

It's gonna just work and it's gonna be completely automatic for the last 20, 30 some odd years since you developed it. The Spanning Tree algorithm was intended to be like, just plug it together and you don't have to think about it. So all of this configuration of priorities and stuff. When I first did it, somebody said to me, Hey Radia, some of the customers are complaining because.

It's the most boring product that digital ever did, and they like to configure things and I said, fine. If they like to play and configure with things, I'll put in knobs, but you don't have to touch the knobs. And even if you do, any setting of the knobs will still work. It was intended to be rock solid, but I also knew that if.

The reliability of this thing depends on you not losing you being a bridge, not losing any Spanning Tree messages. The digital spec said you must be able to keep up with wire speed. So I don't care what you do with the data, I'm not interested in the data, but when you're receiving packets, if you're a bridge, you look at it and say, is the Spanning Tree message?

And if it is, then you must process it. And what you have to do to process it is incredibly trivial. This is an incredibly simple thing. You have to store the best Spanning Tree message you've heard on each one of your ports. And when you receive one, you compare the received one with the one that's stored and there's a trivial comparison about which is better and you throw away whichever one is not better and save the other one.

The digital bridges wouldn't have these problems, but when I took it over they, there were some vendors that wanted to build super cheap devices that couldn't keep up with wire speed. Imagine if you have a loop. Not only do you have this data that goes around, but it exponentially multiplies itself because if you have five ports, you receive a packet, you'll make four copies of the thing.

What would happen is everything would work great until there was a momentary glut of traffic, which would the spanning tree, if you don't hear from a neighbor, You assume, oh, I must be the most qualified bridge on this link. So you will start forwarding on that link. Oh, the loop. So if couldn't keep up with the momentary glut of traffic, wait until you actually cause more and more of these cheap bridges to turn on extra links and have all of these loops and stuff.

So it's not really a fault of the Spanning Tree algorithm. First of all, you shouldn't need a Spanning Tree algorithm. There shouldn't be forwarding at layer two. It should just all be layer three. But if you are going to do that, which is a nice simple thing, you have to be able to do it safely. What has happened with the CLNP these days?

I know it's an ISO standard. I remember looking at some of the packets from it way back in the late eighties. And trying to understand it. And I even taught some lessons on it a little bit, but it never seemed to garner much support and the only company that really moved on it was deck and then they didn't really move forward.

So is anybody else using CLNP or is that standard completely just latent. Yeah, I would say it died, but it's, oh, and just for listeners, deck and digital are the same thing. People call it different things. The problem was it was widely deployed and it worked just great, but, and that was what DECnet was, basically CLNP, but then in 92 someone said, Hey, IP addresses are too small.

Four bytes. Hey, maybe we should do something with bigger addresses. And someone said, oh, there's this CLNP thing with 25 addresses. It's widely deployed. It seems to work great. Let's use that. And unfortunately, standards bodies tend to be very tribal. Territorial. Yeah. Yes. And the reason, so that was actually recommended the recommendation in 92 that we should move to CLNP.

And somebody showed how to make TCP work on top of CLNP. It only took them a few weeks. It was the trivial exercise. And since all of the applications worked on TCP, If they hadn't resisted immediately in 93, certainly the internet would've been using 20 byte addresses. But yeah. Now one fault of the CLNP people is whatever standards body that is certainly managed to make their standards hard to read.

All of this fancy, unnecessary terminology and stuff. Plus they, you had to pay for the specs, I think. Yes. I remember buying them in their big, thick books from ISO standards body somewhere. Yeah. And the routing critical that I had done for digital was got adopted by them and they renamed it.

Unfortunately, So at some point, Trump apparently said that Hillary and Obama invented IS-IS. And some of my friends noticed that headline and forwarded that to me and said, didn't you get some credit? Look what you did. Yeah. And that's still widely deployed, but at any rate, I wasn't going to those meetings, and so the spec had to be.

Translated into ISOs and I just international languages. I guess that was one of the big things, right? Everything had to be translated into every language on the planet and doing that and the terminologies, it probably just got unwieldy. Yeah, I'm not quite sure why. One of my skills is that once I understand something, I can explain it so simply that nobody's impressed.

They go, oh, of course. Whereas other people can manage to make anything incomprehensible. So the audience thinks, oh, I didn't understand that cuz I'm not very smart. But I feel privileged to have been in the room with someone who's such a genius. But at any rate, somebody else translated it into ISO-ease and I could not read my own Spec after that.

Oh my goodness. Something understand it. I'd have to compare it with the DEC (Digital) one. But yeah, so that was part of the thing. But the excuse that there were some vocal people in IETF that kind of went berserk at the notion of adopting this layer three thing. So the kinds of arguments they gave were actually hilarious.

It's like that would be ripping the heart out of the internet and putting in a foreign substance. Whereas CLNP is no less compatible with IP than ip. V6 is Sure where. And that's pretty much continued to be somewhat of a very difficult to maintain both of those simultaneously. Yeah. And 92 would've been really trivial to move the internet, but now it's so entrenched.

Another reason they gave was we don't like ISO's layer six, which was the session layer. And indeed it was mysterious. It's not like you have to use it, it's something that if you're doing file transfer, it does checkpoints and things like that. But that has nothing to do with the 25 layer three address.

And they had other kind of equally silly arguments. And I really wish that people would understand. Technology before saying, oh, those people are just idiots. It would waste our time to try to understand it. I'm not quite sure what I'm answering at this point, but yeah, I'm, yeah, I don't, oh, and it's because we went with ip, the industry that we're stuck with having some sort of other technology that can glue a bunch of links together to disguise.

A cloud as a single link to the IP routers, but it's not like the ideal way to build networks. Interestingly, and I'm not sure how much you've kept up with the QUIC protocol, but the QUIC protocol does away with the need for port and IP address sockets , and it. Uses that link ID that, then you can have Nat and Pat changes .

And it really doesn't matter because it uses the link id. So we've had to glue in a lot of other shims in order to make some of the things that you probably had working in CLNP that we would not have had the same trouble. As protocols evolved, like the QUIC protocol with the link id now? Yeah. I haven't looked at QUIC recently.

I should refresh my memory, but it did some and I like it. And so like when you think about strict layering, That's not a no, there's no strict layering because they use the UDP port 443 to pop the packet out, and that's typically our transport layer. And then they move transport up into the QUIC session area.

And so now QUIC basically takes care of layers, part of layer three to some degree because. The link ID is akin to the socket that we used to use with ports. So I've been studying QUIC for the last several years. It's interesting in watching it. And so yeah, the problems that you talk about probably would've been obviated with some of the technology that you were advising that we'd take a look at in 92.

Oh, people have to make money and problems create the opportunity. Okay. There's. Making money. I understand that motivation when it's just a, anyone that's not on our team are idiots and I don't even wanna learn what they're doing. I have much less sympathy with that. The N I H factor not invented here.

Exactly. Right. So I wanna get back before we go to your famous. Poem and that, and I'm just wondering what was the motivation? And it was probably somewhat to do with that simplicity of explaining it to people. And so you chose an outlet, a creative outlet to use a poem to help us all understand a little bit and get it into our neural network.

Do you have any remembrances on what spawned those thoughts? This will be stepping a little bit on the things I will say. Oh, during my keynote, but I, so what happened, the story of this was, again, I was in a bad mood because people didn't understand that Ethernet was not a network. It was a link and that keynote designer should have called it Ether Link, but whatever given, you know that they were misusing Ethernet as an actual network.

My manager, as I said, called me in and said, oh, you do this sort of thing. And he said, without any configuration, just let people plug it together and they'll figure out a loop free subset. And he thought it was gonna be really hard. And then he thought he was being witty, I think, and he said, oh, and just to make this a little more challenging, make it scale as a constant.

So no matter how many links and bridges there are in the world, the amount of memory necessary to run this should be a constant, which is crazy. Nothing's a constant. Linear, might be the best you can hope for. It'll probably be n squared. So anyhow, that he mentioned this on a Friday. And then he was gone on vacation the next week, and this was before email or cell phones or anything.

So he was gonna be completely unreachable. And that night I realized, oh my goodness, it's trivial. I know just how to do it. And furthermore, It scales as a constant cuz all you have to do is hold onto the best spanning tree message you've seen on each port. A spanning tree message is about 50 bytes, so if you have four ports, it takes 200 bytes to run the algorithm.

No matter how big your network is, Monday and Tuesday, because this is just such a trivial algorithm. I had written this back, it was complete enough. That when the implementers started implementing it, it only took them a month or two to get it working and they didn't have to ask me a single question. So the spec was complete as of Tuesday afternoon and I couldn't concentrate on anything else cuz I had to show up to my boss and he wasn't around.

So that's why I spent the remainder of the week working on the poem. So I officially. Spent more time working on the poem than I did inventing the algorithm and rating the spec. Wow, that is just incredible. Now we're all getting together, uh, in a few weeks, and we're gonna talk about packets and security.

Is there anything on the horizon that you'd like to help us understand better or what we should be focusing on? Is there Quantum things? Are there other things? What do you see as some of the things that, as we gather, and a lot of this is just workshops and as we collaborate together, what are some of the things that we should focus on?

Okay, so everyone's always looking for the next big thing, and they don't wanna miss out. People come up with these buzzwords or these nonsense technologies and everyone wants to jump on the bandwagon, and the people create consortiums and they go to a company and say, look at these companies that have already joined.

Don't you wanna join too? Or, look how many, how much they're investing, so why don't you invest too? I try my best to dissuade people from that. So I have a whole bunch of anti blockchain talks for a while. That was, yes, everybody's big thing. So what exactly is blockchain? One way to think of it is as a magic thing that will solve all problems.

And so you just figure out how to stick it into your application somehow. Or people say, what can I use it for? And again, it's start with what problem you're solving. Look at various ways of doing it, and if blockchain is the best thing. And furthermore, blockchain is not even well defined anymore, like the Bitcoin engine, that's well defined.

But once you start talking about blockchain as a service or a consortium of these things, It's really not clear anymore. So at any rate, there's that. Then there's quantum where the mis, there are so many misconceptions and I try desperately to tamp them down. One is that a quantum computer is just like a regular computer, but it's a gazillion times faster.

So any program that runs on a regular computer, if you could run it on a quantum computer, it would be blindingly fast. And this is complete nonsense. They're not faster, they're different. And there's an incredibly small set of problems that a quantum computer can do better than a classical computer or could.

If you could build these things, and one of them is factoring numbers. And that's not very exciting. I don't need to factor numbers. Why do I care? But it turns out that all of our current public key algorithms, RSA, elliptic curves, Diffie-Hellman, depend on a math problem, factoring numbers in the case of RSA discreet logs in the case of Diffie-Hellman, and elliptic curves.

It depends on those math problems. Being difficult, but if we had a quantum computer running Shor's algorithm, which is a marvel, and I'm actually really proud of the fact that I can actually explain it so that regular engineers can understand how it works. And actually I can plug my new book, which is the third edition of network security, which demystifies things like quantum and blockchain and fully homomorphic encryption.

As well as doing, talking about all the other things you'd expect in a network security book. But yes, so that would be really exciting in a bad way if suddenly somebody could break all of our current public key algorithms, cuz suddenly all of the signed code, you could claim that it was signed by something by Microsoft when it wasn't.

You can impersonate anything on the internet, so that might sound like really bad, but it turns out that the. The security, the cryptography community, in conjunction with NIST is developing new algorithms, new public key algorithms that are normal everyday algorithms. That work on normal everyday computers, but they don't depend on the kind of algorithm that Shor's algorithm would be able to solve.

And so I like to call these things quantum safe algorithms. Unfortunately, NIST has called them post quantum algorithms. Which I think is a terrible name cuz it makes people think, oh, quantum is like so complicated. Post quantum must be, and they think that they run on quantum computers, or they think that once the world has converted all of our computers to quantum computers, then we can start wearing post quantum algorithms.

But at any rate, So that is the one thing that will happen in the industry is that we're all going to have to look at all of our products that are using publicly and figure out how to convert to one of these new algorithms that aren't quite standardized yet. So we have a year or two before we can start.

And we might have forever before we really need to because it's really a daunting thought of how to actually build a quantum computer big enough to do this. But so nobody really knows when or if it will ever happen, but you can't wait until it happens. So therefore, you have to start as soon as possible and soon customers will no longer buy your products unless you're using the new algorithms.

Wow, that's incredible. One of my friends is a CIO over at Oak Ridge National Labs, and I was there with him about, I don't know, eight weeks ago, and he took me by and showed me this new

Cray that they had. That's the eighth fastest computer in the world. And then the old, the older ones. Of course. I don't really comprehend that level of technology.

I just look at packets, but it's fascinating to grasp a little bit. Of what the future is gonna hold for us in developing something like you

said, not post quantum, but quantum resistant or, I don't know what the correct term would be now about the book. How is it coming out soon?

Is it already out it, the physical book started appearing a couple of months ago.

Okay. They are available. Oh yeah. Let me just quickly show you. Nice. That's the book. Yes. Very nice. I did rummage through my library and I found your Bridges and Routers third edition, and I was second edition. There is third edition. There is a third edition. Send it to me so I can, so you can find out who the heck's stealing your money.

Huh. But I decided to just, I decided to just talk about you as being such an amazing woman and. The industry. Thanks you for all your contributions, and obviously you're one of the kindest human beings that I've known and come across, and obviously you know a lot and you help us all understand it a little bit better without hurting our dignity because we might not understand everything.

So thank you for the way that you have worked so diligently to help us understand these complex things. And it is a gift that you have. And I know I'm speaking for many thousands or perhaps hundreds of thousands of people who know of your work and just appreciate you so very much. So I look forward to snagging that book and I'm gonna voraciously go through it so that when we are together in a few weeks, I might get to pull you aside and spend five minutes with you and ask you the big questions that I have resulting from that and.

So thank you so much. It's really a pleasure and I look forward to seeing you in a few weeks. And then do you have any last minute little kind of teaser for folks who are gonna come and hear your keynote? Yeah, no. Hopefully it'll be a little bit heretical, a little bit thought provoking, put things. I'm amazed at people that can manage networks cuz I don't do that.

I'm not a hands-on person at all. But the fact that they can do that without really quite understanding why we have all these things. Yeah, hopefully. The conceptual people and the hands-on people getting together can actually make good things happen. There you go. That's perfect. From a theorist to the practitioners, we're really waiting to hear a little bit more from you and hang out with you a little bit in San Diego, sunny San Diego.

Look forward to seeing you there very soon. Thank you, Radia. Thank you.