Re: snmpconf Reusability of Diffserv MIB

Hi,

I have not check the subscriber-mib, but some question are in line.
Not saying I am an expert in all areas, therefore, some of it below may 
sound dumb.
But in idea I believe it is quit similar.

Hope this helps,

Harrie

On Friday, April 4, 2003, at 03:12 PM, Wijnen, Bert (Bert) wrote:

> So I wonder if document draft-ietf-snmpconf-diffpolicy-05.txt
> would be of help in this case. I have not checked the details
> yet.
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Woundy, Richard [mailto:[email protected]]
> Sent: donderdag 3 april 2003 0:58
> To: '[email protected]'; Wijnen, Bert (Bert)
> Cc: [email protected]
> Subject: RE: [ipcdn] Re: Status - 
> draft-ietf-ipcdn-subscriber-mib-10.txt
>
>
> Wilson and Bert,
>
> One immediate issue I found, in trying to re-use the DiffServ MIB for 
> the
> DOCSIS Subscriber Management functionality, was in the structure of 
> the Data
> Path table, which is the initial table for packet classification.

I do not understand what you mean by 'initial' table. In the 
diffserv-mib
it is not needed to have a classifier as the first datapath element.

>
> The Data Path Table is the first lookup table in the DiffServ MIB, and 
> it
> uses ifIndex and ifDirection as the initial parameters to match. Upon a
> match, the typical next table is the Classifier Table (although the 
> entry
> may point to other Tables in the MIB).

'typical' I would say possibility.

>
> In the Subscriber Management MIB, the first lookup table is
> docsSubMgtCmFilterTable, which uses the particular cable modem, 
> upstream or
> downstream direction (similar to ifDirection), and CM versus CPE (CPEs 
> are
> behind the CMs on the subscriber home network) source/target to map to 
> a
> filter-group. The filter-group points to a set of rows in the
> docsSubMgtPktFilterTable for packet classification. The four subscriber
> management filter-groups are configured through the DOCSIS 1.1/2.0 CM
> registration processes.

A classifier in diffserv is also a set of rows in a table.
So far I believe it is all similar in concept.

Just a question, are only 4 filter-groups possible?? In theory, this is
also possible in the diffserv-mib. The diffpolicy MIB is then a 
possibility
to use in order to define/register such a filter or complete datapath.

> The two gaps I see in DiffServ MIB functionality are:
> 1. The DiffServ MIB assumes that a uniform set of classifiers are 
> applied to
> all traffic flowing over a particular interface, because in the general
> network case, one cannot differentiate traffic except by 
> classification. The
> Subscriber Management MIB assumes that distinct sets of classifiers are
> applied to different groups of cable modems that co-exist on the same 
> cable
> RF interface, because the DOCSIS registration process aids the CMTS in
> differentiating different CM/CPE traffic sources and sinks. Note that 
> there
> can be thousands of CMs from different filter-groups co-existing on 
> the same
> cable RF interface, so an operator would need to add thousands of 
> Classifier
> Table entries to match on specific CM/CPE sources and sinks.

I am not getting this. Do you say that since the DiffServ MIB does not 
group
the classifier table it is not applicable in the subscriber mib??
If I understand it, the docsSubMgtCmFilterTable has just different 
parameters
to get to a first classifier/filter, right??

If so, I do not see a major difference is usage/concept, except that the
docsSubMgtCmFilterTable points to an filter defined in the 
docsSubMgtPktFilterTable
(and is simply more restrictive). This as opposite that in diffserv a 
filter
is not needed to be first.

Correct me if I am wrong, but is the intention of the diffserv-mib is
that a filter for a specific interface and direction and you want to 
have
a single filter defined in the docsSubMgtPktFilterTable that is reused 
for
all the subscribers.

> 2. The Subscriber Management MIB differentiates between CM source/sink
> traffic and CPE source/sink traffic. The CMTS knows the difference 
> between
> CMs and CPEs on the same cable RF IP subnet(s) via the DOCSIS 
> registration
> process. Using the current DiffServ MIB, making distinctions between 
> CM and
> CPE traffic would require many more entries in the Classifier Tables, 
> in
> order to enumerate the CM source IP addresses.
>
> It looks like the DiffServ folks were looking to use more generic 
> parameters
> than the ifIndex during the development of the MIB. From section 2.2 
> of RFC
> 3289:
>
>    Another possible direction of abstraction is one using a concept of
>    "roles" (often, but not always, applied to interfaces).  In this
>    case, it may be possible to re-use the object definitions in this
>    MIB, especially the parameterization tables.  The Data Path table
>    will help in the reuse of the data path linkage tables by having the
>    interface specific information centralized, allowing easier
>    mechanical replacement of ifIndex by some sort of "roleIndex".  This
>    work is ongoing.
>
> I don't know how to apply this "ongoing work" to the immediate issues 
> that
> are solved by the current Subscriber Management MIB.

The more generic usage was to allow configuration templates. For that 
reason
also many datapath element tables are not directly associated with an
interface nad it direction. If I understand you correctly you want to
have filters that are used, but not tightly coupled to en entities 
managed
in the subscriber-mib. The diffpolicy-mib provides something likem this.
As you may note, in the diffserv-mib also datapath elements defined in 
the
various tables do not have to be in operational use.