RE: network controls are necessary

["Tony Li" <Tony.Li@procket.com>]

Tony,

|   > In fact, in my humble experience, it is normally the case 
|   > that they are mortal enemies, competing for budget.
|   
|   This does not mean it is our responsibility to foster the petty
|   bickering. The goal appears to be to pick sides, with heavy
|   representation from those who are most closely related to 
|   the network
|   side. I am not advocating that the hosts do it all, in fact I don't
|   think either side can go it alone, much as they would often 
|   like to. 


I agree that it's not our place to foster bickering.  But we should also
be cognizant of it when we think about how sites are administered.  We
cannot dictate that it be fixed.

I'm somewhat offended that you would accuse us of being partisan.  This
is an architectural discussion about the right engineering compromises
to help grow the Internet.  I'm fully cognizant of what a host administrator
has to do.  I was a Unix and VMS sysadmin for USC from 1983-2000.  We
supported over 2000 workstations and 30,000 user accounts.  Simplifying
host management was a requirement then and still.

I have nothing to gain by having control in the SBR.  I no longer work 
at Cisco, so I have no interest in placing more responsibility and 
complexity into the CPE gear.  I'm just trying to design a clean architecture
that scales.  That's what we should all be striving for.

 
|   Our job is to define a mechanism that allows a disparate range of
|   policies to be implemented without serious detriment to the routing
|   system. Locking down so that the routing system is in 
|   complete control
|   makes defining a technology simpler, but that doesn't mean 
|   the result
|   will actually address the policy requirements. Dismissing a set of
|   policies is a fine thing to do when building a network, but not when
|   defining the standard technology that those individual networks will
|   use. 


Our first job is to define an architecture, not a mechanism.  That
architecture will be able to support some policies, not all.  We need to
understand the bounds of the policies that can be supported by a
particular architecture and to choose the architecture which 
balances policy against complexity and our other design goals.
Supporting all possible policies is not an architectural trait that
is supported with either host or SBR policies.  The amount of possibly
relevant information that either of them will have is far too limited
in any rational design to begin to implement all policies.

So we have to choose.

Tony