> > 3.9 Rich Policy
...
>
> 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"...
One question: is the next-generation routing system constrained to preserve
the pure hop-by-hop forwarding model that we've all grown to know and love?
I've read through section 3.9 of the draft so far between IETF sessions and
don't see anything that states that thus far.
Why is this question relavent? Because it directly affects the set of
policies that can be supported and how those policies are applied. On
today's Internet, "policy" is primarily about setting the next hops that
traffic uses when it exits a particular domain, with brute-force methods
used to try and engineer end-to-end paths on a per-prefix granularity.
But this isn't really what providers of edge or transit services really
want; they want to be able to specify how traffic flows to the customers
of their service - those who pay more should get better service. In today's
world, the mapping between what the routing system can deliver and what
the services that ride on top of that system would like to see don't match
well at all, which is why horrible, non-scalable kludges such as more-
specific route propagation are used in the name of "traffic engineering".
Is it within the scope of the next-generation routing system to solve this
problem or does that properly belong at layer-4 or above (which, I would
argue, is the only place that it can scalably be addressed, no pun intended,
today)?
--Vince
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT