Hey folks,
The diffserv group looking at some alternatives for supporting
various vendor implementations.
The main component in differv model is the policy. Basically it looks
something like:
policy
classifier-1
action-1
action-2
child-policy
classifier-n
action-x
action-y
child-policy
etc.
A classifier will classify on things like address, port, dscp. Example actions
are: discard, mark dscp, meter, schedule and queue. A child policy can
be attached under a classifier to add further classification and
corresponding actions. As shown here, the policy is fairly flexible and
extensible. For example, one could have multiple schedulers in a single
policy under different classifiers, one could have n-number of child
policies, etc.
Two issues we are running into are:
- in a base model, how do we limit various combinations of classifier/action/
child-policy for vendors that don't support them
- how do we limit the model to not support things that don't make
sense in general, e.g. a child policy with a scheduler underneath a policy
with queue
We are discussing some approaches, and are looking to a wider audiance for
suggestions. Some approaches we are considering for some of the issues:
- if-feature conditions to allow some vendors to not support some functionality
- "must" statements to limit some combinations of classifer/action/child-policy
- alternatively using more explicit modules (i.e. less flexible) to restrict
what capabilities are available
- using standard and vendor-specific extensions to define additional
capabilities.
Likely some combination of some/all of these will be needed.
We are looking at two alternatives for defining queues and schedulers.
- The first approach is using the generic policy definition above. Queues
would be defined in a child policy underneath an action/classifier with
a scheduler.
- The second approach would be to define explicit queue policy module and
a separate scheduler module (in addition to the scheduler action). The
queue policy could be referenced by either a scheduler action (supported
by some vendors) or a scheduler module attached directly to an interface
(supported by other vendors).
The advantages of the first approach is that we are defining a very general
and consistent approach to a policy module. The difficulty is that some
vendors do not support child policies, schedulers as actions, and may be
more restrictive as to how one can configure queues as an action. Should
a controller request any of the combinations of capabilities that are not
supported by a particular router, the router would have to fail the config.
The advantage of the second approach is that the rules for applying a schedule
or queue policy would be much more explicit leading to fewer invalid
combinations of configuration that a router vendor could support.
Additional levels of functionality could be supported with if-feature
or extensions. The disadvantage is that the policy module is not as
generic.
So, to generalize, I believe the choice is between a more flexible/generic
module with routers failing configurations that are not valid, or a more
restrictive/limited/explicit base module where invalid configurations are
rare.
Sorry for the long explanation, but hopefully the explanation is clear.
Thanks for your inputs.
Norm
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
