Subject: [netmod] need input on diffserv Yang model

From: Norm Strahle <[email-masked]>
Date: Mon, 1 Jun 2015 02:54:05 +0000

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