Telco's write best practices for packet switching networks

### On Tue, 12 Mar 2002 12:23:51 -0800 (PST), Ratul Mahajan
### <ratul@cs.washington.edu> casually decided to expound upon Sean Donelan
### <sean@donelan.com> the following thoughts about "Re: Telco's write best
### practices for packet switching networks ":

On the downside -- this is yet another instance of conflict between
research and operations. Being able to address the (core) routers

This may be a repeat discussion but I also wonder if there are some other
social level conflicts derived from how one structures their management
network. For instance, many providers have a seperate group which handles
the corporate IT which is different from the group which handles the
production provider network. One could take the stance that the production
network should only be reachable from the corporate network and that the
management network become an extension of the corporate network. I imagine
that many network engineers on the side of the production network might take
issue with that (I probably would). For better or worse, many of us have
gotten used to managing our backbones under a single umbrella including
control over how we design and run our management network. I'd be
interested in hearing about some of the practises of bigger providers
(assuming I'm not asking anyone to violate security) on how they let their
emloyees access their infrastrcture. Do you seperate and outsource your
management infrastructure to your corporate IT support? Do you seperate but
control it within your production network engineering groups? If so, do you
have a special group within network engineering concentrating specifically
on management or do you have the same people designing the network also do
the management design?

Although many of the principles are the same, there are differences
between running a corporate network and a public network. You can
have the same people doing both. In small ISPs its likely the same
people will be doing both. A larger company will have seperate groups
because they serve different masters and have different measures of
success. A company may not want to pay for the same levels of
reliablity and survivability for their corporate network as their
public IP network.

The goals of the corporate network and the public IP network are often
different, at best. The corporate network is inevitably focused around
the needs of the business, including such irritations as file sharing,
printing, calender services, video conferencing, and other notoriously
secure (heh!) services.

The public IP network is focused by and large on providing a limited
number of services, and flinging packets around as fast as possible.

The clue behind the public IP network is almost always focused on the
network (often to the point of considering any systems involved to be
second class citizens "Why should I care if there's a system down? It
only matters if the network's down"[1])

The clue on the corporate network often doesn't care at all about the
network (beyond "is it running") - but really cares that their services
are deployed and accessible.

I think that Sean's right about the goals being different - but it's
more than just "reliability and survivability". The network and
enterprise markets are notably different, with different goals and
requirements.

Most vendors seem to have a very clear grasp on that - and I suspect
that it'll be another 5-10 years before we see any form of true
convergance (if not longer).

[1] This ignoring the fact that a down'd network monitoring system may
  cause all sorts of interesting side effects in viewing the network...