Real ops talking to future ops

I'm afraid this is only slightly operational and limited to a subset of
the NANOG crowd. I apologize profusely in advance for abusing the list
as I might, but I can't think of a more suitable group of people to
approach. I think the essence of the request is in line with the spirit
of NANOG.

As some of you know, I teach networking classes at DePaul University in
Chicago. What has gone over extremely well in the past is when I've had
a real op come talk to the students, even if its just about what they do
on a daily basis. If any of you are in or around the Loop in Chicago
area on a Wednesday night between September and November of this year
and wouldn't mind getting up in front a few geeky undergrads, I would be
forever grateful if you do so with my class.

I'm not asking for anything polished. If you've presented something
recently that you think a computer science undergrad should be able to
grasp or even if just have enable, your future ops want you to tell
them about it.

...and yes, many of the other instructors they come into contact with
are focusing only on class A, B, C addressing. So you'll be doing the
world a favor and maybe even me, by saying some things I'm not the only
one saying to them before they interview circuit.

Here's what things looked like last quarter to give you an idea of the
general topics covered:

  <http://condor.depaul.edu/~jkristof/tdc375/>

Thanks,

John

wow.

d/

I'm just as surprised as you are. They left out AppleTalk.

A few classes ago I had a student tell me they had an instructor spend
two full classes (out of 10) on Token Ring. I think Token Ring is
interesting and I feel a little bit sad about all the token ring
experience I have that is slowly rotting to history with no one to pass
it on to, but was a wow for me at the time.

John

<http://condor.depaul.edu/~jkristof/tdc375/&gt;

John,

I could not help but take a peak at the class topics. I nearly jumped
out of my seat with joy in seeing the e2e principle

But, then went sad and jaded again when poking around revealed no
signs of IPv6....

Cameron

Maybe there's hope for you yet:

  http://fcotr.org/

Jethro.

. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Computing Officer
Information Services, The University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.

Hah, I am not available! :slight_smile: Someone else sent me that too.
Everything old is new again. I'll see their FCoTR and raise them one
EtherRing spec:

  <http://groups.google.com/group/comp.dcom.lans.token-ring/msg/3f5b48931ac29ba8?dmode=source>

Ob humor, I actually got a phone call from someone at the Tolly
Group asking where/how I got permission and the quote from Kevin Tolly
since they didn't remember authorizing such an endorsement of EtherRing.

John

<snip>

  <http://condor.depaul.edu/~jkristof/tdc375/&gt;

It is just me that found the location "Loop Campus" amusing in this context?

There's a serious need to cover such a construct, but also to introduce it in the context of modern systems:

      Probably none of what is sold today as ethernet is actually the original ethernet protocol or even close to it.

      What is sold today is a the ethernet *interface* and some other protocol under it.

This difference between the interface and the infrastructure under it that provides service to it is a fundamental construct that is often missed. Standardized interfaces let technology adapt underneath it.

So, for example, IBM published the API for netbios, without publishing the protocol. That let some of us build alternative protocols that satisfied the API but ran over TCP. (See RFC 1001, 1002 for the standardized version.)

Much of what is sold today as ethernet has a protocol under it that is contention-free. The different Token Ring schemes provide that in a distributed manner.[1]

d/

[1] Though my own focus was on email, my CS prof was Dave Farber, so I had to absorb more about TR than I would have wanted. One of the interesting metricts for TR is delay-time per node. The Irvine Ring introduced one bit-time delay. Scaled great. The IBM TR introduced one full packet-time. Didn't scale well.