Subject: Re: [netmod] need input on diffserv Yang model

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 03 Jun 2015 16:13:54 +0200

Hi Norm,

Norm Strahle <[email-masked]> writes:

> 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

This is a typical situation, and there are three possible approaches
that often need to be combined:

- For parameters supported only by a single vendor, put them into a
  separate vendor-specific module, and augment the generic data model
  with them. Every device will this typically advertise the generic
  module(s) and the vendor-specific one.

- For parameters that are supported by some vendors, define an
  appropriate feature, and use "if-feature" statement.

- For parameters that should normally be supported, devices that don't
  comply may declare a deviation (although it turns out that most
  vendors hate to do so and consider it bad PR). 

> - 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

Using "must" statements if possible, otherwise by specifying the rules
in a description.

Lada

>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Norm Strahle <[email-masked]>
Date: Thu, 4 Jun 2015 04:07:32 +0000

Thanks for the feedback, Lada. Some good guidelines and help us with some of our issues.  There is one fairly large issue that I would like to give a couple of examples on and ask for more feedback from yourself and others on this.

As I mention, the policy module looks as follows:

     policy
         classifier-1
             action-1
             action-2
             child-policy
	etc.

In the specific example, to create a scheduler with queues, it would look like:

	Policy 
		Classifier-1
			Action scheduler-1
			Child policy queue-policy-1

In this manner a child policy is used to stitch a set of queues to a scheduler. So, to support scheduling/queueing using the current model, a vendor must support the child policy concept.  All vendors support queuing scheduling, and thus, to support using the current model, must support the child policy concept. However, Juniper for example, would support the child policy only in this instance, but not in the case of say, a child policy with meters, where as Cisco would support that. So, how if we have a generic model of:

     policy
         classifier-1
             action-1
             child-policy

But all vendors do not support all actions with child polices, but are required to support child policies for the basic functionality of stitching queues/schedulers.

Since some vendors support this flexibility and some don't, it becomes hard to use "must" statements and "if-feature" for this particular case, as combinations are not always a "must" for all vendors, and the "if-feature" is difficult, as it is not one feature, but a combination of features that may or may not be valid.

Two options have been proposed. The first is to stick with the flexible model, and if a controller sends a policy that is not supported by one vendor, e.g. and invalid child policy, then the vendor would "fail" the config.  My feeling is that this is not correct - i.e. if a capability is advertised then the device should support it.

The second option is to restrict the policy definition to be less flexible, and more explicit in its definition. This could be done as follows:

 - define a separate queue policy - i.e. a policy whose only actions are queuing actions. 
 - define a separate scheduler module that could be bound to an interface and can reference a queue policy. So, this is the equivalent of having child policy, but only in a very explicit and supported place.
 - define a scheduler action, that could be "if-featured" so that vendors that support schedulers as actions could do that as well.  And the scheduler action could reference a queue policy
 - make child policies an "if-feature" this allows vendors that support to use. However, it is no longer required to support queuing/scheduling, since the scheduler module can reference a queue policy directly without supporting the generic notion of a child policy.

The second option makes it clear to a controller as to what is supported - i.e. no guesswork on what combinations of actions/child-polices will work.  It also provides support schedulers as both an action and a unique module, so it resolves the conflict in scheduler/queue configuration between router vendors. The queue policy is common for all router vendors (though maybe some if-feature for internal capabilities).

So, my preference, if not already obvious, is option 2. But we could definitely use input from the wider netmod group on this issue.  Please ask questions for clarification on the above if needed.

Thanks,
Norm  

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Wednesday, June 03, 2015 10:14 AM
To: Norm Strahle; [email-masked]
Subject: Re: [netmod] need input on diffserv Yang model

Hi Norm,

Norm Strahle <[email-masked]> writes:

> Hey folks,
>
> The diffserv group looking at some alternatives for supporting various 
> vendor implementations.
>
> 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.
>

This is a typical situation, and there are three possible approaches that often need to be combined:

>    sense in general, e.g. a child policy with a scheduler underneath a policy

Using "must" statements if possible, otherwise by specifying the rules in a description.

Lada

>
> We are discussing some approaches, and are looking to a wider audiance 
> for suggestions.  Some approaches we are considering for some of the issues:
> 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.
> 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.
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Jun 2015 12:01:18 +0200

Norm Strahle <[email-masked]> writes:

> But all vendors do not support all actions with child polices, but are
> required to support child policies for the basic functionality of
> stitching queues/schedulers.

One option is to introduce "type" leaf for policies and encode different
combinations of policy functions into it. Using the identity datatype
for this leaf could make it quite flexible (and probably even more so in
YANG 1.1 where multiple inheritance of identities will be allowed).

Then you could use must or when constraints referring to the type for
specifying parameters of each policy type.

Lada