[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Abstraction levels - (was) Re: snmpconf PM MIB Policy vs. QOS Policy




In observing the discussion on this topic, it seems that once again we
are having a discussion about the abstraction level of the policy. In
per packet policy is at one extreme and EF or good service is
somewhat higher. The PM Table can set policy at a number of levels from
the instance specific, e.g., give these security characteristics to a
certain interface or tweak specific meter and marker values on a
particular queue on an interface. 

In the presentation that Hongal gave at the IETF, he demonstrated (I
think well), the use of the system at and above this level where we have
the 'templates' found in the DiffServ Policy MIB Module which can have a
simplifying effect on the policy scripts since they need not contain all
the default values which as Wes points out can be quite large. This is
policy abstracted to the mechanism-specific level. EF is a good example
as used below since it represents in my view, the level of abstraction
above a mechanism. There may be several entries in our policy table on a
system that contain EF, but which point to different entries in the
DiffServ Policy MIB Module that control different mechanism in the rest
of the system.

I have a now expired internet-draft posted sometime last year that we
never had WG time to pick up. I may do something with it in the
future. The original in pdf form is still available at:

        www.jdscons.com/snmpconf.pdf

It needs some updating but is still pretty much on target.

/jon


> >>>>> On Tue, 03 Apr 2001 10:04:46 -0700, Steve Waldbusser <waldbusser@nextbeacon.com> said:
> 
> Steve> From time to time I see policies described simply as packet
> Steve> treatment specs like:
> 
> Steve> if (srcIP == a.b.c.d)
> Steve> then set DSCP to EF
> 
> Steve> I don't expect that implementations will execute scripts on a
> Steve> per-packet basis to determine treatment of the packet as this
> Steve> would be somewhat slow (understatement of the year!) The policy
> Steve> above would really be a directive to the diffserv system (for
> Steve> example) telling it how to treat packets - in other words it
> Steve> would all exist in the policyAction. But the other problem is
> Steve> it doesn't say which interfaces should treat packets this way.
> 
> Certainly the policy in the PM table should define what policies to
> "implement" in the QOS table, and the packet filtering is not done by
> the script itself (as you pointed out).  I'm not all that familiar
> with the QOS tables, so I'll switch to a IPSEC-POLICY-MIB example: I'd
> expect my PM action script to set up the filters by performing
> appropriate SETs to those MIB tables (which includes a set of "how to
> filter packet" tables).  Now, the IPSEC-POLICY-MIB table also has a
> table that allows you to assign a filter set to a given interface, so
> that actions could assign the policy definitions to certain interfaces
> if need be (professing ignorance (not remembering the PM tables well
> enough), are the actions passed the element in question as a
> parameter?)  I think the IPSEC-POLICY-MIB mib is set up will for your
> particular problem, and the PM scripts to configure the tables would
> be fairly easy to write (though long, because the tables contain a lot
> of data).
> 
> -- 
> Wes Hardaker
> NAI Labs
> Network Associates
> 

Thanks,
/jon
--

Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/