Tony Jeffree

Peter Jones:  Today, for Voices of Ethernet we’re talking to Tony Jeffree. Tony, thanks for joining us. Could you please introduce yourself?

Tony Jeffree:  Thanks, Peter. I’ve been involved in IT since 1975, and in ethernet since 1984. My first career was as a software engineer. I was initially working on the development of process control systems using PDP-8s and punched paper tape and exciting stuff like that. I later moved into fairly rudimentary bits of data communications, and then later still into ethernet. And then took a detour into consultancy around about the early ‘80s and stuck with that for pretty much the rest of my career, going freelance in 1996. Up until 2016 I was working for myself. And I have to say, I was probably the worst boss I ever worked for.

Peter Jones:  There are a whole lot of conversations about the joys of working for yourself.

Tony Jeffree:  Indeed. Indeed. It’s an interesting trip, but mostly I enjoyed it. It was good.

Peter Jones:  So, tell us a little bit about like how and when and why did you get involved in the Ethernet/standard world?

Tony Jeffree:  Well, I first came across ethernet actually before 1984. I was working for a little software house, and we were messing around with various bits of terminal emulation using the emerging microcomputers that were appearing at the time Commodore Pets and IBM PCs.

Yeah. And we briefly looked at the Xerox standards as they were at the time for ethernet and thought 10 megabits per second, you’re joking.

Peter Jones:  Who would ever need it this fast?

Tony Jeffree:  Who would ever need it this fast? Absolutely. And so we passed over that. And so quite soon after I got recruited by the ICC Data Networks who at the time were one of the emerging companies in the ethernet yellow cable network business. And they were building transceivers and selling them in large quantities to guys your side of the pond.

And it was a company that was very much standards-based. And continued to be so while I was with them. And they sent people to 802.3 to see what was going on and also to help develop the standards as you do. And one of these guys noticed that 802.1 was in existence and was looking at network management standards. And I’d been recruited to the ICC Data Networks to work on their ethernet controller for the IBM PC. So they put me on a plane in November ‘84 and sent me off to my first 802 meeting, little knowing that this was not going to be my last by a long stretch. And I got stuck into 802.1 network management and stayed involved in that for several years up until ‘93, when I took a short vacation from standards activities and came back to it in ‘95 when 3COMM were looking for somebody to help write the standard that became 802.1p.

Peter Jones:  Most people today when they think about 802 standards don’t think about network management. Going back in time, what was the drive to go to do this?

Tony Jeffree:  I guess the drive from the ICC’s point of view was differentiation as is often the case with products. You need to be able to not only make sure the thing works but also show, you know, hey, we’ve got more bells and whistles than you’ve got. But in those days, looking back on it it’s hard to see what real value-add was going to be offered by network management on a PC card and IBM PC, you know, in a rudimentary 10 megabit per second network. You know, when we look at the networks of today the idea of building anything significant without network management is kind of a joke. I mean, even I’ve been amusing myself with implementing ethernet and Wi-Fi in our pub, but these days even a village pub needs data communications, and it needed a decent ethernet system. So I’ve ended up implementing something that has got a network management load on it. I mean it’s got three Wi-Fi access points and a network management load. I mean, how cool is that?

Peter Jones:  When you go back to when you showed up, I assume at that stage the culture war between dot-3, dot-4, and dot-5 were still alive and well.

Tony Jeffree:  Oh, very much so. And it continued to be very much alive and well until well after I returned from my break in ‘93 and came back in ‘95 to work 802.1p. I mean at that point, we still had– the war was going on between dot-5 and dot-1 with regard to map bridging. And we had basically reached the point where we had a bridging standard in dot-1. And the dot-5 guys still wanted their source routing bridge to be standardized. And the agreement we had with them was, you know, well you go away and tell us how you’re going to integrate source routing into the dot-1 bridge, the dot-1 transparent bridge. And the so-called SRTB, source routing transparent bridge, came into temporary existence at least in name, if not in substance. And there was an entertaining series of meetings at which, you know, to the …

Peter Jones:  When you entraining this is for a particular class of entertaining it is.

Tony Jeffree:  It is. It is, yes, under some meaning of entertainment, where to use Mick Seaman’s words, we would have a talk with them about what they were doing. And then, you know, they would say well we’ve got these problems and so we would come up with an idea that they might consider between then and the subsequent meeting. And to quote Mick Seaman these suggestions “were all plausible, enticing and non-trivial.”

Peter Jones:  Why don’t you chase shiny object for a while?

Tony Jeffree:  Yes, indeed. Indeed. Chase this shiny object for a while and then come back in two months’ time and we’ll have another discussion with you, and we’ll tell you why it doesn’t work.

Peter Jones:  Most people know about dot-3. How would you describe the split in responsibilities between dot-3 and dot-1. What did dot-1 do that was key?

Tony Jeffree:  Well, two kinds of things that dot-1 did. The first was almost incidentally providing a means whereby a full-duplex ethernet could be extended almost indefinitely in size by sticking it together with bridges. And at the same time using filtering in the bridges to reduce the amount of traffic that each node doesn’t need to see if you follow me.

Peter Jones:  That’s an interesting one. We should dig into that just a little bit because there’s a difference between Layer 2 and Layer 3 and most people don’t realize it.

Tony Jeffree:  Yes. Most people don’t realize it. Most people talk about Layer 2 as being a layer in which no filtering and no routing happens. We successfully maintained the fiction for many years that the 802.1 Mac bridge is not a router. It’s a filtering device. It filters frames. It doesn’t route them. This is, of course, complete baloney. It’s a Layer 2 router. Get over it, guys. And, you know, at the end of the day that’s the reality. It reads frames. And it’s not a router in the sense of being an IP router, but it is a router, nonetheless.

Peter Jones:  The way I would do that was the Layer 3 sends it–  you send the packets to where you think it should go. In Layer 2 you send them to where you’re pretty sure they shouldn’t. So you don’t send them to where you’re pretty sure they shouldn’t go.

Tony Jeffree:  That’s certainly the simplistic view of it. The rather more complex view starts to appear when you look at the added complexity that 802.1 added to bridges later on, things like stuff that allows you basically to nail down a circuit in a LAN. And it makes it look very much like a connection-oriented device. But anyhow, I mean, that’s kind of– yeah. I mean the simple answer is, as you say, dot-1 bridges– filter the frames from the places that they’re not needed. Whereas an IP router sends them to where they are needed. It comes to the same thing. It’s just a different mechanism.

Peter Jones:  So you alluded earlier to dot-1 people who started to do priorities. And I think that probably natively hooks into things like VLAN. Do you want to take us a bit through that journey?

Tony Jeffree:  It does indeed. And when a few minutes ago I was talking about two things that dot-1 did for the synergy of the ethernet in dot-1. This starts into the other half of it which is adding value to the ethernet frame essentially. Dot-1p added capability in bridges to prioritize frames and so you could label the frame as it enters a bridge and say this is priority X.  And then on the outbound ports decide whether you’re going to transmit or not depending on whether there were higher priority frames waiting to be transmitted. And if they were then the priority X frame would wait and until a slot was available.

Peter Jones:  On that priority question, why did you end up with eight priorities? Because I mean long term down the line that’d be kind of an issue. My guess is it’s another case of who would need more than this?

Tony Jeffree:  Kind of yes. Yeah. I mean if you looked at the other technologies in 802 at the time 8 was the biggest number that we had to deal. Token ring had eight. Token bus, I forget actually, did it have eight? It certainly had more than one. I can’t remember. But eight seemed to be the magic number. And the VLAN activity which followed very closely behind dot-1p added the ability to put those priorities actually into the ethernet frame. Dot-1p on its own would only allow the ports to behave as if they had priorities? Dot-1q added the ability to signal in the frame, what the frame priority was and carry that end-to-end.

Peter Jones:  I can imagine that the starting conversation for this VLAN thing must have been exciting with people having to adopt fundamentally new position to the way they saw the world.

Tony Jeffree:  Very much so. And actually to begin with there was a lot of resistance amongst the sort of 802.11 old-school of guys who didn’t see the need for this stuff. You know? What do we need VLANs for? And it was rapidly apparent that there was a lot of industry pressure behind this and companies that it implemented, VLAN schemes on or more different basis. So we did the usual thing of raising a PAR and starting a project.

Peter Jones:  Raising a what?

Tony Jeffree:  A PAR, project authorization request. It’s the scoping document for a project. And the end result of a project in IEEE standards world is a standard. It’s a standard document. The PAR dies at the point where the standard gets published. So the old-school elements in dot-1 wanted to make sure that the purity of the bridging standard was maintained.

Peter Jones:  At this point, I need you to point out the interesting thing of neither of us are particular young and we’re describing the old school as the people who were there before us.

Tony Jeffree:  Well, I was one of them. I mean, the old school was– I was in the dot-1 people that were there already as opposed to the newcomers who were coming in and saying we want VLANs. So anyhow, we felt that the whole sort of VLAN project was sufficiently risky that it was worth keeping it as a separate standard from 802.1d which was the bridging standard at least in the initial stages. And it stayed that way, you know, for quite a few years, and was eventually reunified back into dot-1d. Actually, it was the other way around. Dot-1d was reunified into dot-1q, into the VLANDs.

Peter Jones:  Before we dive too far away from this, can you give me a few words on how Spanning Tree became Spanning Tree.

Tony Jeffree:  How Spanning Tree became the Spanning Tree. Well, the original Spanning Tree was invented by Radia Perlman. It was a result of a paper that she wrote when she was working at digital. And the idea basically is that if you construct a mesh topology in ethernet you’ve got all kinds of problems because frames circulate endlessly. And, therefore, you have to find some way of reducing that mesh topology to a tree structure and, hence Spanning Tree. You want it to be tree structured and you want it to span the entire network. So all loads are included. And there’s an arc between any one node and its immediate neighbor that allows you to reach all parts of the network. The problem with Spanning Tree in its original form was that it wasn’t very quick. Worst-case in a large– in a maximally sized network 30 seconds to reconfigure if you broke a link. You know, I mean this is madness guys. You know, people could die in that intervening 30 seconds and you would have no way of dealing with it. And we needed to fix that one way or another Mick Seaman had a really quite major brain wave when he realized that if you have a tree structure and you snip off a branch of that tree you can reconnect it to the end of any other branch and the tree is still a Spanning Tree.

Peter Jones:  I got that. You’re moving a chunk of a tree.

Tony Jeffree:  You chop off a limb. You can move a chunk of a tree to any other end node on any other branch of the tree and attach it there and connectivity is restored and it’s still a Spanning Tree.

Peter Jones:  I don’t think that I understood that. I’m sure I looked at it, but I never actually thought about it that way. So somewhere in there you could transition from editing as sort of being a major contributor to actually be running the group. I’m just sort of wondering like how and why? Why did you take on that task?

Tony Jeffree:  Because I was asked to I think is the short answer to that. Bill Lidinsky who was the first chair of dot-1 basically dropped out of 802 activities in 2000. And that was partly because at the time there was a sort of sunset clause on repeated reelection of chairman that you couldn’t be reelected more than x number of times before you had to pass the baton on to somebody else. And so he used this to basically terminate his activity in 802. He decided to give up at that point. And I was asked to take over and also given an offering of funding to do it. So, you know, why not? It’s a very different role, obviously, attempting to run the group as well as editing standards is kind of– it makes your life pretty hectic at times.

Peter Jones:  You need to be very clear which your hat you’re wearing as an individual contributor, editor or chair because they’re very different behaviors.

Tony Jeffree:  Yes. Yes, indeed. And, I mean, I shall leave it to others to pass judgment on how well I managed that multiple hat-wearing. But I stayed in that role for 14 years from 2000 to 2014.

Peter Jones:  Well, you can’t have done that badly.

Tony Jeffree:  Yeah. Either that or everybody else was saying, well, you know, we don’t want to go there.  

Peter Jones:  Sort of along that, you did a sideline into the Registration Authority Committee or the RAC. And probably most people out there have no idea what that actually is.

Tony Jeffree:  Okay. Well, the RAC, the Registration Authority Committee is the policy-making body that sits behind the IEEE Registration Authority, surprise, surprise. The Registration Authority is an assigned numbers registry organization that it keeps registries of assigned numbers. And if you want one of those families of assigned numbers you go to them.

Peter Jones:  And an assigned number is?

Tony Jeffree:  For example, a block of ethernet address and that’s the most commonly known registry that the IEEE maintains. But there are a bunch of funds that go alongside of it which are rather lesser-known, but nonetheless valuable to those that care about them.

Peter Jones:  Today, for Voices of Ethernet we’re talking to Tony Jeffree. Tony, thanks for joining us. Did you happen to be there at the time when we had the argument about whether we should go to EUI-64, 64-bit addresses, instead of 48.

Tony Jeffree:  Yes. Yes. There were various ongoing discussions about 64 versus 48 and how to integrate them and so on and so forth. And, of course, the reality with number spaces is that you can’t put a quart into a pint pot. I mean like surprise, surprise if you have 48 bits, you can put those in 64 bits. That’s easy enough. If you have 64 bits, you can’t represent them in 48 bits. Well, you know, okay, so you have to choose one. And there also lots of discussions around whether it was possible to put together a scheme where you could integrate the two. But actually, you know, the short answer was choose one, stick to it and, you know, get over it really. In the few cases where 802 standards ended up with a 64-bit address spaces they pretty much had to reduce their effective number space to 48 in order to talk to the rest of the world, or use a router. I mean, it’s not a big surprise really.

Peter Jones:  Related to this topic, there was the time where we shifted from 802.3 to ethernet. I’m guessing this was during that period as well.

Tony Jeffree:  Sorry, in what sense.

Peter Jones:  As in because there used to be standards such as LLC 802.2. And there used to be a link field which became a top field.

Tony Jeffree:  Yes. Okay, yeah. Yes. All right. Ah, right. The ether type.

Peter Jones:  Yes.

Tony Jeffree:  Ethernet as in ether type. Yes. Yes, indeed. That pretty much coincided with 802.5 disappearing from view because they were pretty the only people that cared about LLC surprise, surprise because they didn’t have an ether dot in their frame format. And dot-3 and dot-1 didn’t really much care about LLC. It didn’t have any great value for us. In fact, it was a pain in the backside frankly. Yeah, I mean pretty much at the point where 802.5 became a non-protocol. Ethernet and using ether types for ethernet networks was the obvious way to go really.

Peter Jones:  So if you took a look back, right, I mean, the standards development world is a very strange world. And you did mention something about the server people shop is strange.

Tony Jeffree:  Yeah.

Peter Jones:  If you were trying to explain it to the outside world as to how it is you succeeded in that world, how do you think about how success happens?

Tony Jeffree: I think the primary way success happens is by not being too optimistic about how far you can go, if you follow me. That’s not expressed very well. I guess the expression don’t try to boil the ocean springs to mind. There’s an inevitable tendency in all projects that, you know, you get project creep and scope creep setting in. People say, oh well you know let’s just add this other new feature. And I’ve got this other thing that I want to do. You know? We can just sneak it in here. And suddenly you’ve got this gargantuan mess, and nobody really knows what they’re trying to implement anymore. So what we tried to do in dot-1, at least, was to make sure that we had a very clear idea of what the scope of our project was. And we would test what we were doing against that scope on a fairly regular basis. And if there was any scope creep, we would actually do the decent thing and go back and change the PAR and say, well actually we want to include this in it. Because strictly speaking if you produced a standard that exceeded your PAR you could be pulled up on it and told you were a naughty boy. So that’s certainly one aspect of what we felt went for a successful standards process that stay within your scope. Be realistic about what the scope is. And importantly, limit it to stuff where there’s an existence proof of a solution. Standards work very well when you take an existing technology, and you develop a common view of what that technology is and what its rules are. Standards development works very badly when you treat it as a research and development project. I mean that way basically lies disaster.

Peter Jones:  If met here be dragons.

Tony Jeffree:  Yes. Here be dragons. Very large, very nasty dragons and things go on for years and years and you get nowhere.

Peter Jones:  I’m reminded that in dot-3 we vote quite a lot. And in dot-1 you run a more consensus model where you basically never vote unless you know you’re going to win.

Tony Jeffree:  That’s absolutely right. And we nurtured that way of looking at the process. It was something that Bill Lidinsky set up when he was chair and we saw that it work well, and we carried it on. Essentially, the way we worked was to build consensus in the technical meetings. And once we’d understood what the technical consensus was we could take a vote in the closing plenary and say, we have agreed. This is the consensus. And those votes almost invariably passed. It was very rare that we had a punch up in that final discussion. And on the very few occasions when we didn’t go down that route, I mean, there was one occasion when there was a binding vote taken at one of the task group technical meetings and went– well, it went whatever way it went, at which point the meeting broke for coffee. And there was a lot of discussion over coffee as to how that vote had gone and whether it was the right thing to do and so on and so forth. And after the coffee break, the meeting reconvened and decided that that vote was a really bad idea and they rescinded it.

Peter Jones:  So along this path even though dot-1 started off really looking at a lot of different physical media, to a large extent, it’s become, you know, joined at the hip with ethernet.

Tony Jeffree:  Very much. Yes.

Peter Jones:  I just wonder if you could express an opinion as to how they contributed to each other’s success.

Tony Jeffree:  Well, it’s kind of an obvious synergy really that bridges need something to connect them together. And ethernet segments needs bridges to connect them together. That’s the sort of trivial answer to that question. We were developing different parts of the same– of the overall network. The ethernet frame ended up being extended in various ways by the work that we did. We added a VLAN tag to it. We added another VLAN tag to that. And we did Mac and Mac, and we did other crazy things. And so for a while, we were going through this meeting’s ethernet frame size discussion. And eventually we reach the point where it said, okay, well this has got to happen once and for all. We’re going to make a final decision. This is going to be the maximum frame size that an ether frame will ever have regardless of what one decides to add in terms of bridging functionality.

Peter Jones:  The envelope frame.

Tony Jeffree:  The envelope frame, the overall frame. The actual data portion of the frame stayed the same through all of these discussions. We were adding bits on the front.

Peter Jones:  So it would be reasonable to say that this is what the standards and mainly things happened outside the standard.

Tony Jeffree:  Yeah. Yeah. I mean other things happened, obviously.

Peter Jones:  The way I tend to think about was I think it was the right mix between dot-3 did just enough and dot-1 did just enough. Whereas maybe the others tried to do too much. And so I think it became a everyone did what they need to do but nothing else.

Tony Jeffree:  Yes. Yes, indeed. And that I think is another great principle when you’re looking at standards and what makes a good standard. I remember a fascinating discussion that I had. I did a bit of consultancy with the guys at CERN. At the time they were looking at ethernet and rapid Spanning Tree. And the 802.1as time synch as the basis for essentially wiring up the LHR for ethernet. And their spec for this was they needed the time sync to be at least as good as two nanoseconds. Okay. So the synchronization node to node had to be no worse than two nanoseconds. The demonstration involved a kilometer of fiber optic cable and two nodes, and you heated up this kilometer of cable with a hair dryer, which made it longer, of course, and therefore skewed the time sync between the two nodes. And you could see on the scope the two nodes getting back into sync. And it always stayed within two nanoseconds. So at a meeting fairly soon after that, we got this guy to come and give a talk dot-1 about what he’d been doing and how he’d been doing it. Which was utterly fascinating, because at the time most of the people implementing rapid Spanning Tree were looking at a couple of orders of magnitude worse than the sort of speed reconfiguration that these guys needed. And a couple of orders of magnitude worse in terms of the time synchronization between nodes. And so it was fascinating for them to see what was possible. And one guy stuck his hand up, you know, in the question session and said, you know, you’ve got to two nanosecond synchronization. Did you think about going any further? And he said, nope. Question, why not? It was good enough. And that absolutely was a fascinating– you know, these guys were engineers. They had a problem to solve. They weren’t into the business of researching ethernet networks. They were into the business of researching particle physics and ethernet was a tool to get them there. And they had a spec and once they meet that spec, they’re done.

Peter Jones:  I’m reminded of advice I got from someone. It may have been you or someone else. A standard is not done until there’s nothing left to take out.

Tony Jeffree:  Yes. Yes, indeed. Yes, that’s another way of looking at the same thing that you start the development process by putting loads of stuff in the document. And then, you know, when you pair it down to the absolute minimum that you need to keep in the document then you’re done.

Peter Jones:  So I’m going to move along because otherwise we could make this 10 hours. So we want to reflect on from where you started which is old serial loop to where we are today. There’s been huge changes.

Tony Jeffree:  Yes. There have been. Yes. The most obvious changes that pretty much everywhere you look you’ve got ethernet. You’ve got Wi-Fi, or a combination of both. Wi-Fi, of course, is these days the thing that is much more visible then ethernet because ethernet is just the plumbing. It’s the wiring down below. But, of course, as we well know without ethernet the Wi-Fi would be kind of lost.  And that doesn’t even get fixed by mesh, but that’s a whole other discussion. We probably better not go there.

Peter Jones:  As you mentioned earlier, you’ve definitely retired and you bought a pub, and now the question is you have to put the network in the pub. If you think about where we were to now it’s like, yeah, connectivity is everywhere.

Tony Jeffree:  Yes, absolutely. And what people don’t realize about open…

Peter Jones:  Just for fun, where are you located?

Tony Jeffree:  I’m on the Isle of Mull which is in the inner Hebrides just off the west coast of Scotland. 

Peter Jones:  A long way away, and not somewhere you would think, oh, I’ll, have communications. I can video conference with these peopls.

Tony Jeffree:  Well, absolutely. But, of course, we’re currently video conferencing using the services of Elon Musk with his Starlink because essentially that’s the only game in town at the moment, but there you go.

Peter Jones:  These packets that go on and cost an awful lot of ethernet links.

Tony Jeffree:  They are. They’re going off across–  they’re very large number of ethernet links. And, actually, a fair number of ethernet links just in my house, but there you go. But what people fail to realize about ethernet is just how pervasive it is becoming. It’s not just about conventional data processing type activities and video conferencing and so on. It is invading our cars. It’s invading the technology that we use for…

Peter Jones:  Invading?

Tony Jeffree:  Invading. Yes, it is replacing bits of the wiring lube in your car in order to reduce the amount of copper that’s used, and, you know, add functionality and so on and so forth. It’s doing the same thing in planes. It’s very much doing the same thing in process control which is where I started in this gig back in 1975. And for me that’s a fascinating sort of full circle thing. 

Peter Jones:  I was going to ask you later about what you’re keeping track of, and it seems that you’re actually keeping track of some of the stuff I’m really interested in which is the movement of ethernet into the OT world.

Tony Jeffree:  Yes. Yes. Indeed.

Peter Jones:  Have you been tracking the fact we’re doing the 10 megabit again?

Tony Jeffree:  Well, yeah. And why not?

Peter Jones:  And multidrop.

Tony Jeffree:  Yeah. But that’s fascinating in itself because it goes back in the days when the dot-5, dot-3 and dot-4 wars, come to that, were still in full flood. You know, people were saying that ethernet could never do real-time activities and that’s patently not the case. You know, well, we had in the time that I was still at dot-1 a very active series of projects working on support for audio, video, and manufacturing and so on and so forth. It’s a whole area that I’m sure will become very interesting in the coming years.

Peter Jones:  In the interest of self-promotion, what do you think about putting this sort of history together?

Tony Jeffree:  I think it’s a great idea. I mean clearly the case. You just have to look at the hair color to realize that some of us guys that were there in the early days of 802 won’t necessarily be around for many, many years to come. And in fact some of the people that were involved in the early days have already departed unfortunately. So getting these sorts of stories down, and, you know, getting a bit of background into the, you know, the real life aspects of how these standards came into being, I think, is a great idea.

Peter Jones:  All right. Any final thoughts?

Tony Jeffree:  Final thoughts. I had some somewhere. Yeah, I mean, it’s– I think we’ve mostly covered what I had in the way of final thoughts which is really around, you know, that it’s been a fascinating area to work in. You know, if I had any advice for somebody who’s contemplating going into standards development, you know, on the one hand the advice might be, you know, run a mile because you’ll get sucked in and you’ll stay in that identity for 30 years, like I did. On the other hand, it’s been a massively rewarding exercise to, you know, a pretty rewarding way to spend 30 years of your career. And it’s a great way to meet some pretty smart engineers and go to restaurants and things to connect.

Peter Jones:  Tony, thank you so much for your time today. I really appreciate it.

Tony Jeffree:  It was a pleasure.

Peter Jones:  I do miss seeing you at the meetings. Maybe I’ll get to Scotland sometime.

Tony Jeffree:  That would be good. Yeah. You’d be very welcome.

Peter Jones:  Thank you so much. All right. So this is end of our story from Tony Jeffree. So tune in to hear the other Voice of Ethernet stories. And I look forward to seeing you on another videocast.