Re: [RRG] Are host-stack modifications allowed or disallowed ?

["William Herrin" <bill@herrin.us>]

On Wed, Feb 20, 2008 at 9:38 AM, Randall Atkinson
<rja@extremenetworks.com> wrote:
> Earlier Bill Herrin wrote:
>  % The point of that is not to figure out "the" way that the solution
> % will be deployed. The point is to verify that there is at least one
>  % way the solution could be deployed
>
>  However, for virtually any IETF proposal in the past 10 years, there
>  have been at least some folks ("peers") who derided that proposal as
>  "totally unrealistic".  Despite this, a number of those proposals have
>  been deployed at significant scale.

Ran,

Derided the proposal or derided a specific step in the proposal's
deployment plan? Recognizing whether a particular small step in a
theoretical deployment process is pure pie-in-the-sky is a whole lot
easier than evaluating the likely impact of a plan's general
weaknesses.

We could, for example, argue forever about whether push or pull makes
a plan too consumptive or too  slow to be viable. On the other hand,
its fairly easy to see that "One ISP deploys one machine which does X"
is a viable step in essentially any deployment plan while "27,000 ISPs
each deploy one machine which does X" is an unweildily large step
that's nearly impossible to justify without first breaking it into
multiple steps.

That's why I say: write it out step by step, verify that you still
have a working system overall at each step and then ask, "Why would
individuals choose to perform step #X at that point in the process?
What would cause step #X not to be performable?"

If your deployment process looks like this:

1. Everybody installs the new software and hardware and turns it on.
2. It works

Then the system has a high probability of deployment failure.


>  So I would narrow your constraint a fair bit.  If a reasonably large
>  set of folks view a proposal's deployment model as viable, that
>  is sufficient.

In other words, get a general consensus after excluding the outliers.
If you're talking about consensus among operators then I can agree.

I have found that folks outside of operations or whose operations
tasks are small-scale tend to take a distressingly simplistic view of
how tasks are sequenced in order to get from one working state to the
next. This routinely leads to a faulty consensus, as the IPv6 debacle
should be making painfully obvious to everyone here.

Regards,
Bill Herrin

-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg