Subject: RE: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt

From: Andrew Smith <[email-masked]>
Date: Tue, 13 Jun 2000 16:55:00 -0700

What we actually decided was that the MIB already allowed you to specify
multiple levels of TCB for a given {interface,direction} and that this lets
you place a classifier basically anywhere you like (some minor wording
changes to be made to clarify this). 

The "serious semantic problem" that you describe is a general one for
implementations of this MIB: the matching up of a manager's desires with an
agent's capabilities is a difficult problem, particular with such a flexible
MIB. This is made easier, as I indicated in a previous message, if you can
have a good description of the agent's capabilities in the MIB - I think we
might tackle this as a follow-on project but there seems to be a strong
desire not to impede the progress of this MIB right now.

In private discussions, the authors did consider something the VFL solution
but we decided that we did not want to introduce a new namespace like that
in order to solve a problem that was soluble with a more generic mechanism.
I believe that we do need the ability to have classifiers other than "IP BA"
at this point e.g. an IEEE 802.1p or MPLS classifier.

Note that you can restrict which (or how many) MFC filter elements are able
to be created by limiting row-creation in the 6-tuple filter table: these
table entries can be re-used/shared between the top level classifier and the
"dropper classifier". You can also restrict which classifier entries are
allowed to point at them (yes, this will make life confusing for a manager
...).

Andrew

> -----Original Message-----
> From: Yasusi Kanada [mailto:[email-masked]]
> Sent: Monday, June 12, 2000 11:24 PM
> To: Fred Baker; [email-masked]
> Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt
...
> I want to add one more issue.  As a result of recent discussions, a
> classifier is going to be introduced before the algorithmic dropper.
> In the current design of Diffserv MIB, you may need a BA classifier
> there, but I think there should not be a MF classifier.  In Diffserv 
> MIB, a classifier can be inserted anywhere in nature, because 
> the tables 
> are connected by RowPointers.  However, I think this is too flexible.
> For example, if two or more MF classifiers are specified in a 
> Diffserv 
> MIB usage and the router support only one MF classifier, 
> there will be 
> a serious semantic problem.  I experience this problem now because our
> hardware router is not so flexible as Cisco's software routers (7200,
> 7500, ...).
> 
> A BA classifier may be too restrictive.  I think a better solution is 
> to use virtual flow labels (VFL) that I introduced in my MIB 
> (draft-kanada-diffserv-qospifmib-00.txt).  In this architecture, a
> classifier appears only once, but VFL makes configuration flexible.
> However, introduction of VFL into Diffserv MIB would take us too far
> from the current point.  I think a moderate solution is to restrict 
> the dropper classifier to BA.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2000 23:36:04 -0500

Right, and the BA-based classifier model is such a basic part of diffserv
that I find it hard to justify inserting the VFL approach at this
late stage.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: Yasusi Kanada <[email-masked]>
Date: Wed, 14 Jun 2000 00:27:35 -0700

On Tue, Jun 13, 2000, Andrew Smith <[email-masked]> wrote:
>You can cascade schedulers, queues and other elements in the -03 MIB by
>using multiple levels of "TCB" (see e.g. diffServClassifierLevel definition
>or issues 17 and 20). The TCB concept is introduced in the Conceptual Model
>draft although it only shows up a couple of times at the lower-level
>representation of the MIB. This should give you the freedom to implement
>CBQ-like schemes - let us know if it does not.

Do you mean, if I want to use CBQ-like queuing, I can cascade queues
instead of connecting queues to a scheduler?  This is possible, but
then, what is the difference between a queue and a scheduler?  I am
not sure.

Actually, in the previous version of the MIB, the difference between
a queue and a queue set (which is something like a scheduler in the
current version) was not very clear either.

>desire not to impede the progress of this MIB right now.

OK.  I agree the multiple-classifier problem is not the only semantic
problem.

>at this point e.g. an IEEE 802.1p or MPLS classifier.

I am interested in reading this.  I understand, if there should be a
"dropper classifier", it must be able to point an external table.
However, I think IEEE 802.1p or MPLS classifier is more like BA than MF.

>allowed to point at them (yes, this will make life confusing for a manager

We can put many restrictions on specific implementations of the MIB.  
This would be OK for device-dependent managers.  But, if you want a policy-
based control in multi-vendor environment, this will cause headaques.
I hope we will be able to solve this problem in Diffserv PIB, and ...
will Config Management WG solve it?

---
Yasusi Kanada, Ph.D,  WWW: http://www.kanadas.com/
Email: [email-masked] (day), [email-masked] (night)
Network Systems Research Dept., Central Research Lab., Hitachi Ltd.
---