Re: requirements sub-group draft

From: Kastenholz, Frank (FKastenholz@unispherenetworks.com)
Date: Thu Dec 13 2001 - 10:30:39 EST


Bob

Thanks for the comments.

I have some responses in-line...

f

At 10:36 PM 12/12/01 -0600, Bob Salmi wrote:

>RJS: How about
>
>A router must be able to detect, and should be able to recover from transitive
>data inconsistencies. Good, valid data from 1 or more sources must not
>be combined together with existing or received data to create a destabilizing
>effect(for some value of destabilizing) . If a router is not able to recover, it
>must not propagate the inconsitent data if the router is a propagator of control
>information.

that sounds about right.

> 3.9 Rich Policy
>
>
>RJS: Perhaps some language differentiating policy specification from policy
>implementation. The motivations you list under transit rules, business decisions
>and load management may be examples of policy specifications, whereas the
>items listed in examples of things "not policy" are eaxmples of tools/information
>that one might use to effect the larger policy specification.
>
>Are you attempting to say things like prefix x should follow
>"the gold service path" or "traffic to prefix z or provider y should/should
>not be constrained to a set of paths" ,without specifying the
>mechanisms/tools/attributes that are used to effect that policy specification.
>This section seems to indicate that you want to talk about policy at something
>like an administrative domain level not at a box level, but seems to flop back
>and forth between "systemic" things and box things.
>
>Or were you trying to convey something completely different here ?

One of the problems with this whole area is that I've attempted
to come up with a good, useful, crisp, definition of policy
that covers what people are trying to do today with 'policy'.
Unfortunately, policy is one of those N! things -- get N people
in a room and you get N! definitions of policy. The lack of
specificity and crispness of this section may be, I fear,
a reflection of similar lacks in deployed networks. The
only real requirement might be "operators have to be able
to reach in and diddle with things"...

Again, thanks for the comments
Frank Kastenholz



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT