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:lho...@nic.cz]
Sent: Wednesday, June 03, 2015 10:14 AM
To: Norm Strahle; netmod@ietf.org
Subject: Re: [netmod] need input on diffserv Yang model
Hi Norm,
Norm Strahle <nstra...@juniper.net> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
