I tend to think about this from a different perspective.
The requirements for policy can be thought of as
a) carry enough information that a path selector can pick paths that fit
its policies
b) give the path selector enough expressive power that it can cause packets
to follow paths that fit its policies
It seems to me (although I can not prove it) that if you approach this as a
general perspective rather than as a specific ("avoid some AS" or "only
tell my customers about this"), then the QoS properties and the traditional
policy oriented policies ought to be amenable to similar treatment.
And if they are so amenable, we don't have to figure out now what QoS
information or QoS path selection is needed any more than we intend to
figure out all possible policies. At the same time, it may help us in
thinking about the mechanism to also think about the kinds of inforamtion /
decision QoS tends to lead one towards, as I think those handles are useful
even if one is not actually doing QoS. (I have trouble telling "cheap"
from "low loss" from this altitude. And I do not expect providers to
advertise their tarrifs any more than I expect them to advertise their
dropping policies in the routing system.)
Yours,
Joel M. Halpern
At 09:59 PM 12/19/01 -0800, Fred Baker wrote:
>At 07:18 PM 12/19/2001, J. Noel Chiappa wrote:
>>I wouldn't be so quick to write off constraint-capable routing - which is
>>what you're really talking about here. TOS routing, QOS, various kinds of
>>policy - when you look at them, what they all really are is the ability to
>>select a path given a set of constraints.
>
>it's true that this is in essence what traffic engineering is, in another
>guise. I don't think I'm writing it off. I'm countering Ran's claim that
>it was ten years ago the wave of the future. It was then a ripple at best,
>and as one who tried to ride it, it wouldn't carry a board. If it will
>carry a board now, fine.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT