Tim: 0:12

Hello and welcome back to another episode of the Cables to Clouds podcast. I am your co-host, Tim McConaughey. As always, with me is my other co-host, Chris the Hammer Miles. I don't know. I'm just gonna start making up like I'm just gonna start making up nicknames for you. Sorry, it's like I'm gonna say that.

Chris: 0:28

There's a very there's a there's a there's a local lawyer from Louisville, Kentucky who's also called the Hammer. So we're gonna we're gonna get uh Oh brilliant. We'll roll with it.

Russ: 0:38

He could sue you over using the mimics.

Tim: 0:43

And uh that voice is our guest who we're very happy and lucky to get uh Russ White. Uh probably needs an introduction, but it's kind of a thing that you do that when you bring someone on your podcast. So please, Russ, the the five-letter uh introduction, if you would.

Speaker: 0:59

Oh five letters, yes. A B C D E. I don't know. Everybody pretty much knows who I am, so I'm not gonna spend a lot of time talking about it. If you want to find me, you can find me on LinkedIn and look at my profile. Have fun with that. I don't I do try to keep it up, but you know, it is what it is. So yeah, so that's that's pretty much my five-letter introduction.

Tim: 1:21

All right, brilliant. I love it. And uh he also has a podcast called The Hedge. Uh rule11.tech. That's your website, right?

Speaker: 1:29

Yep, rule11.tech. Yep.

Tim: 1:30

Yep, yep, yep. Thought I remembered it correctly. Anyway, um, so we brought what Russ here today to talk about something that Russ is very good at. Um two things that Russ is very good at. Uh, one is like network design, and then the second is teaching people about things like network design. And the the question we kind of posited to him uh, you know, when we were trying to get him to come on was, you know, how do you feel about how difficult it is, or kind of what is your approach to teaching people design? Something kind of high-level, something kind of ephemeral that way that that comes with a lot of uh a lot of battle scars usually is is how you end up learning these things. But you know, how can you take what you've learned and and and teach other people? So, you know, not to stand on ceremony, but like let's just start that discussion and kind of see where it where it takes us. What what do you think, Russ?

Speaker: 2:25

So I think there are things you can teach. Um, I think there are things you cannot teach. I think the first problem you run into when you try to teach design is is it's too big. There's too many bits and pieces, it's too large, it's too much. And there's no way beyond building a mental map, actually understanding it. And it takes years and years and years to get yourself to a mental map. So as an analog to this, and maybe this won't mean anything to anybody, but when I first started my PhD in philosophy, my professor, it's actually it's philosophy, but there's another major, it's culture and technology stuff. But anyway, he said, What you need to do to understand philosophy is to build a mental map. And so throughout this PhD program, we're gonna help you, we're gonna work together on build you building a set of documents that help you have a mental map of all of philosophy, because that way you can then take different things that you hear or books that you read, and you can insert them into your mental map and understand it's like you know, it's like anything else. Oh, yeah, I know where that store is. That's next to this other store that you already know where it is, and that's kind of what you have to do, and you kind of have to do that with network design and architecture, I think, too. I don't think there's a good way to start from the beginning and just do it. I think you have to just suspend disbelief and go do things and and eventually you'll you'll build a mental map. And you know, anyway, so I don't know if either of you have thoughts on that.

Chris: 3:59

No, I mean, I think I think just to your point, it is like it's a big topic, right? It's it's there's so much encompassed in overall design of something. And a lot of people um, you know, uh that that want to become, you know, an architect or you know, put so to say a designer, uh, an interior network designer, so if you say. Um uh people that commonly come from the engineering side of that, right? They're doing something very technical, maybe doing brake fix, doing operations for a long time. Um, so I'd be curious, you know, what what do you think are the biggest misconceptions people have whenever they first get into it, like coming from that side of the house?

Speaker: 4:36

Yeah, so I think the first thing is that it's knowable in a very discrete way. I think that's insane. So I face a lot of this in electronic engineering too when I was first coming up that way, that a lot of people think that because you can troubleshoot circuits, you know how to design circuits. And that's that's unfortunately there's some truth to it. You know where things break, or you know how to find things when they're broken, but there's also not a lot of truth of it in other ways. Like my uncle who did all network did all troubleshooting all the time for electronic circuits testing, used to talk about how designers would send him a circuit board and I would say, plug this in and try it, plug it in, and it would be a direct short because they had some line that was running from the source, from the from the source to the ground. And they just hadn't seen it because it was going in all sorts of little circles around all the components, and then you plug it in and like bang, your power supply says, No, no, stop doing that. And so this is very much the way network design is too, is like some of it is yes, so what if you can troubleshoot it? But designing it troubleshooting only takes you so far down the design path, and that's so that's I think one thing that's hard for people to understand. Another thing I think that's hard for people to understand is it's really a game of abstractions and trade-offs. It's really a game of learning how to move between levels and different areas of abstraction and putting them together in your head. It's never about configuration. I mean it's it's just not. I mean, it's good to know what things can do most of the time. Sometimes you don't care if they can do it or not. That's what you need, and you gotta go find the thing that'll do it if the thing you don't have doesn't do it. But yeah, I think that's for a lot of people the two big surprises are one, it's not about configuration, it's not about knowing protocols and like, oh, I know what the e-bit does in IS to IS. Okay. Or OSPF. Okay, great, awesome, great for you. You know what the e-bit does. Next, can we move along now and actually do design? And the other thing is that you can troubleshoot it all day long. It's ironic I say this because the first book that I wrote for Cisco Press that Don Don and Alvarez and I wrote, Advanced IP network design, was came what came out of us saying, we know how things break and we see how things break all the time. So maybe we need to write a book on how not to break things.

Tim: 7:09

Yeah, that sounds right.

Speaker: 7:11

And that was like basically where we started the whole design thing was right there. How not to break things. But troubleshooting is not the same thing as knowing how not to break things. Root cause analysis gets you further around around design than than troubleshooting skills.

Tim: 7:26

That's interesting. So something you said about the the mind map thing is funny. Uh not to go too far back, but uh we were talking about the mind map thing. Are you speaking specifically about just relational, essentially how things relate to each other, like learning something and then relating it to something else? Yeah. Yeah because when I was studying for my uh for my uh uh IE, I remember one of the memorization techniques I was using was the that concept of mind palaces. And it was funny because that was I was like, is yeah, okay. So he's talking about that. But uh the the mind palace thing was was was on the top of my head as well. And I didn't I I don't know why I didn't know this, or I knew this, but I'd forgotten it is that you had a um is it a doctorate in uh it's a doctorate in philosophy, right?

Speaker: 8:07

It's a doctorate in philosophy, yeah. Yeah, that's where I started So for instance, right, and this because it's completely out of the field, sometimes it's really useful to look at how you do things in other areas of knowledge rather than focusing directly in on what you're trying to learn because you can be medicine if you can think about how you would think about it. So, as an example, my written comps for my PhD in philosophy were literally sit down, here is a blank word document. You have two hours. Start with the automatist, the pre-Socratics, and make your way through John Dewey and name for me every major philosophical school, who the primary people were who wrote in that school, if you can remember them, what they were pushing against in the previous school, and why they went the direction they did, and then if there are major turns, like what are there schools of philosophy that change the way everybody looks at things? And there's only there's honestly only a couple of three of those, in all honesty. Plato to Aristotle is ontology to virtue. Then you get to Occam, and a lot of people think Descartes, but it's really starts with with Occam more than it does Descartes. And now we're talking about the differential between um virtue and ontology to epistemology, and all of philosophy ever since that time has been consumed with epistemology. So identifying those kinds of turns and identifying where thing who the you know how the thing came about, the history of the thing really helps you build that kind of a mental map, which is why we did history of networking. Because if you really understand where did BGP come from, what were the goals? What did Yakov think about when he was drawing on that napkin? Like what was he trying what problem was he trying to solve? It makes a lot more sense the way it works. And so that to me is a big part of it. Is this another thing that's surprising? Again, we go back to the it's not about troubleshooting, it's about root causes, it's not about protocol development, it's about theory, it's about understanding the whys and the theories. And so can it be taught? Yeah, if you're focusing on a theory, the problem is a lot of people get so bored so quickly of theory that they don't they don't want it, right? They rebel at the thought of theory.

Tim: 10:28

Yeah, I think the history thing is such a good point, right? When I'm trying to teach people anything about networking, I'm like, okay, I can show you how to, you know, what commands to use, I can show you what the P bits do, whatever. But really, you should be asking the question, why? Like, why did they design it that way? And then usually that gets people to think in that in that way that you're talking, right? In that way you're talking about. And that usually actually gets them further than just parroting, essentially, you know, memorizing and parroting. And I think that's so important. So yeah, that's a huge, huge difference.

Chris: 11:00

Yeah, I think the uh the other day someone asked about BFD and like what it was and why why you would need to use it. And I remember I spent the the paragraph I while explaining why you would use it was this long, and then the the details about how the protocol actually worked was like this long. It was very, it was very different in understanding the why. That's kind of I mean, I think that's kind of come back, it comes back to design overall, right? You have to understand the why. You have to maybe I maybe we can use this to transition to my next question. Um, so like I think one thing that I see people struggle with when moving from an engineering background into a design uh type role or something like that is they it seems to be there's a difficulty understanding trade-offs and why you should pick something over another thing. Um you know, there's the you know the the triangle, you always gotta pick two sides of the triangle, right? Yeah. Um I guess what what do you what are your principles around understanding trade-offs and and things like that?

Speaker: 12:00

So the first thing to do is to find them. And this is this is a matter of experience, fortunately or unfortunately. I I don't I don't always know how to tell people other than the history, right? Go back to the why. Okay, I'm gonna deploy a I'm gonna design in a flooding domain boundary right here. Well, how does that work? And if you understand how that works, you can start thinking about what the trade-offs might be from doing that and what's your experience of doing that in the past, and what is it called what problems has it caused? So that but finding even looking for them. The number of times I've been told by people, oh no, there are no trade-offs. You just deploy this and it just works. And I'm like, no, just stop. Like, seriously, stop it. There are trade-offs. I'm sorry, but there are trade-offs. And and by the way, this is not just network design, this is life, right? This is the way it is. You want to understand economics? Go read Thomas Sowell. One of his biggest things is trade-offs. There's always a trade-off, there's always a trade-off. And so I think the biggest first thing is if you haven't found them, keep looking. Even if you found one or two, keep looking. Always be aware and alert to new sets of trade-offs as you're working on a design or examining. And if you're looking at an old design, if you're brown field, which is a lot more than you think it is, if you're brownfield, go think about what the trade-offs the original designer made. Like what what were they thinking when they put this aggregation point in here? What were they thinking of? Did they consider the trade-offs? Did they do you know?

Chris: 13:35

That's probably very difficult to do retroactively, but I'm sure it would be a fun exercise.

Tim: 13:40

Well, and also how has it changed? How have things changed in the interim? Like what what has changed with the organization? Has it gotten bigger, changed the traffic patterns? Like what has changed, basically? Yeah, I think that's really good.

Speaker: 13:51

Yeah, and that's a major problem, right? What has changed? What what's going on since they designed this? And yeah, to some degree, you're imputing motivations, which is always a bad thing. It's always hard to impute motivations or or figure out reverse engineer motivations. But most of the time with design, you can kind of look at it and go, Yeah, they did aggregation there because they were thinking about this router over here. Where they that's probably what they were thinking about. And then you can look at it and go, Yeah, but that router was replaced five years ago.

Tim: 14:19

Right. Really? What's the static route do?

Speaker: 14:23

Yeah, exactly. Oh, I remember this really funny time. I walked into a big company's I've probably told the story so many times, but anyway, I walked in, I got off an airplane, I was at a company to teach a protocol, teach some routing stuff. And so I walk I took the bus or whatever it was, taxi or whatever it was, to get over to their headquarters, to their building, they're not their headquarters building. And I walk in and I'm like, okay, where's the room? We need to get everything set up, let's figure out what we're doing, let's talk to people, make sure I know what I, you know, what's going to be useful and what's not. And they were like, we need to come over here. I'm like, okay. And there were like 20 people gathered up outside of a single cubicle. And they were all trying to jockey to look inside the cubicle at the computer screen then there. And I was like, okay, what's going on? And they said, well, there is a routing loop in the network that is preventing people from getting to the S390. And I'm like, okay, what are we doing about this? And they said, well, it's a static route, and we know the route it is, but we're waiting on the change control board to tell us we can do a network change to take the static route out. And I'm like, I don't work for your company, let me have the keyboard. Like, what are they gonna do? Fire me? Right? Have it. Good luck with that. And I just like whoever put that static route in was they were thinking, I've got to solve this problem. I'm gonna go solve this problem. They weren't thinking about unintended consequences, they weren't thinking about potential outcomes, you know, they didn't think about the whole system as a whole or as as what it is. And you see this all the time. I see people do network design all the time, and they're like, okay, we're gonna support this new application. Great. So they go out and they start designing stuff and they start throwing protocol stuff on the routers, and they get to the end of it, and they're like, now nobody understands how the network works. Oh, imagine that. Like, why would that be? Because you didn't think about how to work with the existing design. That's why. And so, yeah, so I think those are all very valid things. I don't know if we answered your question or not, though.

Tim: 16:24

I mean, it's a hard I think I think they're all hard questions to answer about design, and that's kind of the point. That's why there's something to talk about, is that it's very hard to do that, right? Like when I'm trying to I okay, all of us did that uh the megaport thing recently, right? We were all we all had a session or or whatever on the recent megaport connect, right? Right. So mine was about like modern WAN design, right? And so I think Alexis was like, oh, well, this is gonna be a technical, uh, technical um presentation. It's in our advanced track. And I'm like, yeah, but it's about design. So it's not like I'm gonna get down to the protocol layer and start telling people, hey, you need to use BGP and these address family. Like people like the it's funny because you know, you can I think that's still possible to have a quote unquote technical session and have it still not be like everybody thinks technical means I'm down in the protocols, I'm down on the weeds, I'm in the CLI. But like, yeah, it's still a technical session, right? Designing is still a technical thing.

Speaker: 17:18

That actually is one of my big annoyances with conferences, it's it really is, and and with training in general. I have people all the time say, Well, when you get into the advanced stuff, and I'm like, welcome to the advanced stuff. The advanced stuff is how SPF works, it's not the packet formats, it's how SPF works. Right. Advanced is being able to look at a topology and say, if this link fails at time one, it's gonna flood here and it's gonna do that and intuitively know how that network is going to, whether it's using BGP, whether it's using distance vector, path vector, or link state. Like you know how it's gonna converge. That's advanced.

Tim: 18:03

Right. And and not only is that advanced, but uh the ability to look at that and then derive all of that. That is, I mean, that's it. Like I was doing uh uh we were doing the CCIE lab build for uh uh I I I was I was contracting for a company that did the CCI lab build. And I remember because as part of that, you you know you insert faults and and you do the all of that, right? And uh I remember looking at one and they were like, oh, we got this fault, and they put it in, they're like, it's gonna, it's gonna break when they do this. And I looked at it and I was like, it's not gonna break. Like, of course it's gonna break, it's gonna cause a routing loop. And I'm like, I don't I don't think so. Let's try it. And so we did it, and of course it didn't break. But that's but that's exactly the point, right? That doesn't make it not advanced just because you didn't get down to the CLI and and and type the commands in, right? Like, I absolutely completely agree.

Speaker: 18:50

Yeah, exactly, exactly. Yeah, my CCIA failure story, by the way, is that in my lab, the first time I took the lab, I failed it. And one of the things that the Proctor did, Alan, was we had a term surfer, right? And he went in and he changed one of the terminals, one of the routers from 2501, because I had named them all 2501 A, B, C, whatever, to 250 lowercase L. And so I spent probably 20% or 30% of my troubleshooting time just trying to figure out why I could not get into that router.

Chris: 19:26

The lab used to be so evil, man. I thought it was evil when I took it, but I hear about those days.

Tim: 19:30

I'm like, man, I mean, we bent one of the pins on our one of the pins on the serial cable or something.

Speaker: 19:37

The 60 pin. Oh no, they didn't bend them, they just pushed them back about a quarter of an inch, so you visually wouldn't see it. Like, you know, the pins are all different lengths, so it's supposed to be all the same lengths. But if you push them back, some of them you push back an eighth of an inch, and the rest, you know, and you leave some and you pull some out a little bit and you push some back a quarter of an inch.

Tim: 19:56

That's evil.

Speaker: 19:57

When one of those long pins hits the bottom, the Eighth inch pushed in will still work, but the quarter inch won't. And so, you know, you plug it in and you you have you have carrier, but you can't ping.

Tim: 20:09

Right. No take it.

Speaker: 20:10

What's going on with that? You know?

Tim: 20:14

Yeah, you could do some pretty evil stuff when you had the physical, physical gear. And and they did, right?

Speaker: 20:20

Yeah. And the other favorite they always did was on the AGS Plus, you had to boot from the from the boot ROM, or you had to boot, you know they had those jumpers on the motherboard that you could change to force change where it booted from, whether it booted from the ROM or whether it booted from RAM or disk or whatever it was going to boot, not disk, but whatever. And so they would change it so it would boot from the wrong place, but it would be one version back of iOS. And so you would pull it up, and it wouldn't if some things would not configure.

Tim: 20:50

Right. They weren't they weren't modeled, those commands weren't there or something like that.

Speaker: 20:54

Exactly. Or it was instead of being a kitchen sink image, it was an ISP image. And there were certain things that weren't there. So you do a chauveur and you're like, that's the right version. What's the problem? Why won't it work with why is this thing gone away on me? And you so rude, man.

Chris: 21:12

That is truly wicked. Truly wicked.

Speaker: 21:14

You need to power it off, go switch the stupid jumper on the motherboard, boot it back up, and then everything works again on this brand.

Chris: 21:23

Um I have a question. Um back on back on topic. I'm sure we'll derail from it pretty soon, but we'll at least get back on course for a minute. Um so one thing I've at least noticed um kind of in my tenure is that the I guess the best designer doesn't always win in terms of being the best network designer. And what I mean by that is that I feel like there are people that I've met in my life that I'm very convinced if I lock them in a room for six hours, they would come out with the most prestige, beautiful network design you've ever seen. But one thing they could sometimes lack is the soft skills to either talk, talk about that to the business or talk about um it could be something as simple as gathering requirements from non-technical stakeholders, things like that. Um so what what what are your what are your inputs around that? Like what what do you need to focus on to be good in that area?

Speaker: 22:21

I think communication skill is the biggest thing in the world. Just knowing how to listen and how to talk and how to um and honestly, the only way I know how to be a good communicator is just to go do it. I mean, I I feel really sorry for the first for the people who took my first two years of uh of of presentations in Cisco Live. I I feel sorry for them because I I honestly think I'm a much better communicator than now than I was way back when. So that's fair. That's like it's like a thing, right? You just get better at it over time. And I don't know, when I first started at Cisco Live, I was doing a lot of animations, I was relying on the slides, I had a lot of text. Most of my presentation was reading the slides a lot of times. And I think what really shifted that was when Alvare Ratana and I started presenting together and Don slice. So the three of us can basically I think they're both well, Alvaro's not totally retired, but the three of us could actually give each other slides without ever looking at them in advance, like our thought processes are so close that we could I I could take Alvaro's slides and just present them without ever seeing like seeing them in advance. Um he can do the same thing with mine. So I think part of what forced me to relax was when I started having to do other people's presentations without the preparation time of building the preparation, of building the presentation. And the second thing was when we relaxed and started just making it funny as well. Like we would play joke on a multi multi-presenter presentation. We play jokes on each other, right? Like when I was doing the CCDE, um, what was her name? I don't remember her name now, but anyway, she would come up and she would introduce the session, and then Mosadak and I would like not show up until five minutes after her after it started, and she was done with her introduction, and like, you know, just to like okay.

Tim: 24:21

It was Elaine, yes. I love Elaine, she's great.

Speaker: 24:24

So we used to like intentionally like leave Elaine hanging for like three to five minutes.

Tim: 24:30

That's terrible. She's so sweet, too. What is wrong with you?

Speaker: 24:33

Just like, you know, because then everybody's laughing, and it's much more relaxed, right? It's much more of a shared experience than if you're like four, gotta get it done, got my outline, gonna do it, gonna do it. Yeah. The more the more you can make the presentation relaxed. And I agree. I mean, I I have all these stories about things like this. Like when I was at a customer, um, the sales engineer had built a spreadsheet of what we were gonna talk about in 15-minute increments. And in the morning, I walk in and there's these pieces of paper scattered around the conference table, and they're these 15-minute slotted. And so I walked around and I just tore them in half and threw them away. And like the sales engineer was so mad. I worked so hard on that, and I was like, the customers at the end of the room, we just gotta talk to it. Yeah, you just gotta roll with it. Like, just don't do that kind of stuff, don't over plan, don't overthink it. Like it's too much. Calm down, it'll be okay. And so, yeah. But communication skills are are really, really critical in the design side. Um, the other thing that people do, I think, in design that they don't think about too much or they overthink is they over optimize.

Tim: 25:48

Oh, yeah, god yes. Oh, that's such a pet peeve of mine, gold plating. Oh my god. Yes, I hate gold plating, I hate it.

Speaker: 25:56

If I can cut five more off five more bits out of the packet format, but it only costs me like 20 pages of documentation. I'd rather have the five bits taken out. Like, no, seriously.

Chris: 26:09

Yeah, sometimes the trade-off is convenience. Yeah, sometimes it's usability.

Speaker: 26:15

Understanding being able to understand it, somebody after you has to look at this thing and understand it, right? Um, my classic example was OSPF and ISIS when they first came out, and the whole reason OSPF was designed, not the whole reason, but one of the reasons, was because ISIS is TLV based. And back in the day, we cared about the number of octets on the wire. I'm telling you, we cared. And so we built entire protocols optimized around how many octets it put on the wire to get a certain thing done. Like, yeah, I get it, but the result is complexity. The result is like, you know, same thing with tuning your timers down when you can make a network converge. I'm gonna make the network converge in 17 milliseconds.

Tim: 27:02

Subsecond timing. We're in a WAN situation here. We don't need sub-second timing.

Speaker: 27:07

Yeah, even in a data center, right? Seriously, 20 milliseconds, 100 milliseconds. Like, I don't know, is there that big of a difference? Now 10 seconds to five seconds? Yeah, I get it, right? I get it. That needs to be fixed. I don't know. I've seen people split flooding domains because it saved them 15, 20 milliseconds in in convergence time. And I'm like, you just that's just insane. Absolute insanity.

Tim: 27:34

So I have a oh, sorry, I didn't mean to cut you off there.

Speaker: 27:37

No, go ahead.

Tim: 27:38

Well, like I told you I did that that uh thing, and uh I gotta send you my megaport slides. You can I'm I'm very curious about your your feedback on it because it's so funny. Without prompting, you've said a lot of the things that I say in this in this thing. I I have a whole slide that says basically design networks so that someone else can operate them. Like that I did not agree with that more. So anyway.

Speaker: 27:58

We we had a rule in tack, by the way, when I was back in Cisco Tac. We had a rule that if you can't explain it at two o'clock in the morning to someone whose primary language is not your primary language, it's too complicated. Don't don't do it.

Chris: 28:13

I think I think we all uh I think we all became designers because we hated operations. So you need someone else needs to be able to do the operations.

Speaker: 28:21

Yeah, that's that's true too. I keep going back to operational operational roles, and I keep discovering I really don't like operational roles that much. It's not my thing. I mean, I get it. There are a lot of people who love operational roles, but it's just not my thing. It's just I just don't do as well.

Tim: 28:37

Yeah, I mean, there are people that do really well in operations, um, and there are people that that do really well in designing something for people in operations to operate. So yeah, that everybody, every to each his own.

Speaker: 28:49

That's right.

Tim: 28:50

Yeah. All right. So I know we're almost out of time here. Um, I wanted to see if we could roll up a little bit of the of what we have kind of sussed out here. So let me recap a little bit if I can. Uh, you know, first of all, of course, is design. Well, I I don't know if this is exactly what you said, but it basically like design for the constraints, right? You you have to it's like I when I when I describe design, I don't know if you'd agree with me or not, you could let me know, but when I describe what is designing to other people, I'm like, look, think of it like a puzzle box, right? Like you see the picture, you kind of you got the picture on the front, you kind of know where you want to get, but you have to work within, you have to build the uh the border. And the border is really all your constraints. That's everything you have to work within the budget, uh, equipment, location, all of that, right? Yeah, so that's I think number one. I think we talked about that. Um, and then you know, don't gold plate, obviously, go, and I say gold plate it, like it's everybody knows what I'm talking about. It's just what you were talking about, right? Don't make things too complicated so that no one you're the only one that knows how they work. Don't be brand.

Speaker: 29:52

Sometimes brute force is the best thing. So back in my double E days, I'll tell another little story here. The I I used to work on VORs and tack ends, which nobody knows what those are, but that's I unless you happen to do airplane stuff. Um, and so the first time I walked into the VOR shelter. And the VOR, its final tube stage is a is a Thyrotron. The radar was a magnetron, but this was a Thyrotron. And then it's high enough power that it actually uses um waveguide rather than because you can't use um cable, even coax, even well-designed coax above a certain power rating, because it leaks too much, it becomes an antenna. So we had can't we had waveguide. And right there in the middle of the way, now you're very, very careful about the way you connect waveguide. Like you've got to make sure that the half-lengths are, you know, that you're half the wavelength and whatever, it's all all your joints have to be in the right places and right at the null points. It's very, very persnickety job putting waveguide together. So right in the middle of the waveguide, there is a gap and it's about half an inch wide, and there is a stinking fan with its blade running through the waveguide. Is this that is the weirdest thing? We have to pay so much attention to waveguide. I asked, and the answer was it's a final modulation. That fan sweeps the signal once every second and blocks the signal entirely so that that is basically your one-degree marker as the signal goes away on the VOR. And I'm thinking, you know, there are a thousand ways you could have done that. You could have shut the Thyrotron down, you could have blocked the transmit side circuitry, put a fan in the waveguide, like brute force. It works, but it's brute force, and everyone can understand it. If you go wave guides, you walk in the shelter, you look at it, you're like, oh, I know what that's doing. Design that way.

Tim: 31:56

Yeah, right. Totally, totally agree. Totally agree. Um, okay. Well, I mean, you guys, everybody.

Speaker: 32:03

You were rolling up. Did you did you finish rolling up there?

Tim: 32:06

No, no, that was good. No, that was that was actually great. Uh, that was a great segue. That but that's that's kind of the point you were making, which is literally design as simplistically as possible. I have uh another slide in that in that in that uh uh presentation that says it's the quote, and I forget who the quote is, I just I lost it all of a sudden it's a philosopher or something. Uh it's something like uh it's finished uh when there not that when you have nothing left to add, but when you have nothing that left to take away.

Speaker: 32:32

This is like that's the protocol design thing, and I think this goes all the way back to the beginning of the internet, and I'm trying to remember who said it, but yeah, it's actually a protocol designer.

Tim: 32:42

Yeah, okay. I couldn't remember who it was. I grabbed the I grabbed the quote, but it's one of my favorite quotes, which is was just that.

Speaker: 32:48

So and it's true of networks as well. Like you don't keep adding stuff, you take stuff away.

Tim: 32:53

Absolutely. So, okay. So we went over at the beginning where we can find Russ. And honestly, if you are listening to this and you don't know who Rice White and you don't know how to go find him, I'm I'm really disappointed in you. Send me a message so I can so I can fix it. Very disappointed.

Speaker: 33:12

You might be disappointed when you find me, but that's okay.

Tim: 33:17

Oh no, that's great. We'll have to uh we'll definitely have to have you back again, Russ. This has been awesome. Thank you for coming on the uh the pod and uh talking with us today.

Speaker: 33:25

Yeah, cool.

Tim: 33:26

And check out the hedge. Anything? Yeah, check out the hedge.

Speaker: 33:29

Rule11.tech is uh I don't know if that's where you prefer to people to go, but that's where I usually I mean, I don't really, other than like the hedge is on all sorts of podcast thingies. Yeah, the podcast. I don't I don't even know. Like I have no idea where all the hedge podcast thingies are. Um but yeah, rule 11.tech is kind of anytime I'm teaching a class or anything, I try really hard to remember to put it out there. I have been very bad at this of late. In fact, I'm teaching tomorrow and it's not even on there. So I need to do that.

Tim: 33:58

Just mention it. Just you know, mention it in there somewhere. Yeah. But um, yeah. Anyway, all right, everybody. This has been uh Caples Clouds podcast. Uh Chris, any closing thoughts or anything before we uh shut down? Forgot to ask you.

Chris: 34:10

Um I was gonna say happy Thanksgiving. Uh, but uh by the time this releases, the Thanksgiving will have come and it's gonna have been long gone by that point. So I hope you enjoyed it. Yeah, I hope you were very thankful and spent time with loved ones and all that good stuff. But yes.

Tim: 34:28

All right. Okay, we'll see everybody in the time.