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

IETF 48 Pittsburgh snmpconf Tue 0900 1 Aug 2000

IETF 48 Pittsburgh snmpconf Tue 0900 1 Aug 2000

Reported by Dale Francisco (dfrancis@cisco.com),
Rob Frye (rfrye@longsys.com), and Steve Moulton

The bulk of the Tuesday morning meeting was
devoted to Jon Saperia's presentation
"Configuration Management with SNMP:  SNMPCONF WG
Status" (see also accompanying slides), and
discussion of the topics he raised.  Then Mike
MacFaden and Jon discussed the BCP doc
"Configuring Networks and Devices with SNMP"
(draft-ietf-snmpconf-bcp-02.txt).  Finally, Steve
Waldbusser began his presentation on "Policy
Processing Questions" originally scheduled to
begin at the Friday meeting.

    Andrea == Andrea Westerinen       andreaw@cisco.com
    Andy == Andy Bierman              abierman@cisco.com
    Case == Jeff Case                 case@snmp.com
    Dan == Dan Romascanu              dromasca@lucent.com
    Harrington == Dave Harrington     dbh@enterasys.com
    Jon == Jon Saperia                saperia@mediaone.net
    Juergen == Juergen Schoenwaelder  schoenw@ibr.cs.tu-bs.de>
    Mike == Mike MacFaden             mrm@riverstonenet.com
    Partain == Dave Partain           David.Partain@ericsson.com
    Randy == Randy Presuhn            Randy_Presuhn@bmc.com
    Shai == Shai Herzog               herzog@iphighway.com
    Steve == Steve Waldbusser         waldbusser@nextbeacon.com

Jon Saperia began his presentation with an agenda:
  - Review of charter, goals, and work items.

  - Policy management with SNMP:  Goals, Terms and
    Operational Model

  - Policy-based Management MIB Module: quick status
    and work items.

  - DiffServ Policy MIB Module: quick status and work

Jon went on to discuss the wg charter, goals and
work items.

The overall goal is to improve the utility of
SNMP as a configuration management framework.
In support of this goal, the wg will add MIB
objects to support policy-based provisioning

Work items include:

- Best Current Practices document for configuration using
  SNMP and for documenting policy-based work
- Policy Management MIB module
- DiffServ Policy MIB module

Jon argued that it made sense to use a common
framework (SNMP) for all management activities,
in order to achieve benefits of efficiency and
scale, and to leverage existing knowledge and
software.  There will also be operational benefits
from integration of configuration data with other
data such as that from performance and fault

The wg approach will involve adding MIB modules
at different levels of abstraction.  Jon proposed
defining those levels as:

    Domain:  A domain is a general area of technology
    such as service quality or security.  Services,
    or service level agreements, may span several
    domains, each of them potentially including many
    policies.  Generally people will not discuss
    these domains in the abstract.  They will most
    often use technology or application-specific
    examples.  Examples include IPSec and
    Differentiated Services.

    Mechanism:  A mechanism is a management technology
    over a domain--the dials that you turn to affect
    a domain.  Comprises standard MIB modules.

    Implementation:  Vendors may define
    implementation-specific parameters to augment a
    standard set of mechanism-specific parameters.
    These vendor-specific extensions are described in
    private (enterprise) MIB modules.

    Instance--The low-level details; the actual parameter
    values associated with particular instances of a
    managed element.

It is useful to have _all_ of these levels represented.

Jon proceeded to define terminology for policy-based
management using SNMP:

    Policy-based management: The practice of applying
    management operations globally on all managed
    objects that share certain attributes.

    Policy: The association of a boolean filter that
    selects objects with an operation to be performed
    on those objects.  Expressed as: if (policyFilter)
    then (policyAction).

    Filter: A boolean expression that determines if
    an object is a member of a set of objects upon
    which an action is to be performed.

    Action: An operation performed on a set of
    objects (efficiency gain--don't set individual

    Role: An abstract characteristic assigned to an
    element that expresses a notion such as
    political, financial, legal, or geographical
    association; a way of identifying who gets a
    particular QoS, for example.

    Element: A uniquely addressable entity on a
    managed device.

Jon described the inputs to managers (slide #9, Policy
Management with SNMP: Operational Model--Applications):
Roles, schedules (only want something to be true at certain times),
filters (for a particular policy, select only these elements), and
actions (mechanism and implementation-specific info).

Managed elements include capabilities, capacity info, utilization, and other state info.

For example: The House Lighting MIB module.
A table might have light intensity and other
parameters for every light in house.  Next level
of abstraction: Mechanism specific: House
lighting Policy MIB module Next level: Policy
based Mgmt MIB module (communicates w/ other
modules as needed) Note: The standard, low-level
management framework is unchanged. Policy mgmt is
just an overlay.

Jon then gave the current status of the
Policy-Based Mgmt MIB module:

draft-ietf-snmpconf-02 published in July.

Modifications to capabilities table
  - pointer to mechanism- and technology-specific modules
  - support for implementations with restricted capabilities (how does
    a system tell the world it supports WRED, or security, but with

General functional questions:
   - policy precedence
   - notifications
     (if there's a config change, should tell system)
   - policy override mechanisms

Execution environment (scheduling)

Policy expression issues (versioning, extensibility)

Architectural relationship w/ other docs e.g.,
interaction w/ mechanism- and
implementation-specific modules

Conflict resolution

Jon then gave status on the DiffServ Policy MIB module:

draft-ietf-snmpconf-diffpolicy-02.txt, published in June.

Work items:
  - Ongoing sync with QoS device model
  - Ongoing sync with DiffServ MIB
  - Expansion of how module relates to other MIB modules
  - Better usage examples
  - Integration of state, other info

Then followed discussion on Jon's presentation:

Partain: In slide 10 ("Policy Management with
SNMP: Agents", using the House Lighting MIB
example) I'd like to restate the terminology to
see if I understand it.  The "House Lighting MIB
module" is the nuts and bolts--what we SNMP IETF
people love.  The "House Lighting Policy MIB
module" is a template for operations (e.g.
vacation lighting policy).  The "Policy Based
Management MIB module" sets up filters/mechanisms
(a role might be "edge light").

Dan: I have a question about the different
definition of "role" (different from PIB/COPS).
I better understand the COPS one.

Jon: We talked about this: a role can be an
arbitrarily assigned attribute of an element.

Dan: Other definition: A role is a selector for
policy rules that determines the applicability of
a policy to a network element.

Jon: My sense is that they don't mean exactly the
same thing.

Andrea: Why don't we work together and come up
with a better word? "Role" means function in COPS

Steve: They really are different things. In COPS,
a role is the entire selector for whether policy
applies to a particular element.  In snmpconf, we
draw on many variables (e.g. ifAdminStatus) for
selection; "roles" are "special", high-level
notions only known by humans.  Maybe we need
another word.

Shai: "Role" is a problematic usage.  COPS already
has this well-defined.  No reason to twist an
existing term.

Jon: Someone will contact Andrea to work with her
on syncing terminology.

Next, Mike MacFaden discussed the BCP document
"Configuring Networks and Devices with SNMP"

The goals are to:

  - Document what we already know

  - Document BCPs in the use of SNMP as a configuration tool, and
    correct misperceptions about SNMP-based configuration and policy.
    Illustrate the practices through examples.

  - Highlight application and MIB module design
    choices to produce efficient and effective
    configuration mgmt systems.

  - Update general knowledge of SNMP-based mgmt to
    the year 2000.

The intended audience is network vendors and
people who design and deploy MIBs.

Some MIB design guidelines:

Distinguish row creation from activation; need to
make explicit the effect a change has on the
stability of a system under configuration.

Newer MIBs often provide objects to turn all or
some features off.  Turning off is better than

Design in ability to save the active config
easily.  It's nice to have clear separation of
config variables from others. One idea is to use
MIB design convention of groupings.  What do I
have to save from a MIB in order to capture
active config?  A BCP would state how to
partition the config info.

Don't use OCTET-STRINGs to aggregate multiple
objects. Does this conflict with PortList TC?
No...that's a good example of efficient

Specify an upper limit on the number of traps
that can be sent in response to a given event.
The effects of configuration can generate an
inordinate number of notification events.  E.g.,
when an FR link is set admin down, don't need to
send down traps on each DLCI.

Provide user controls to avoid cascading
notifications due to hierarchies. When possible,
specify a notification equivalent to the layer
being configured. Provide a mechanism that can
control lower layer notifications e.g.,
ifLinkUpDownEnable.  (Otherwise things could get
bad in policy changes, where you change lots of
things at once.)

Provide user controls to avoid a flood of
notifications due to parallel notifications,
e.g., a line card w/ 400 IFs goes down--just need
one trap for the "containing" object.

Persistence of config objects should be well
specified. Consider using StorageType TC as
opposed to using DESCRIPTIONS. e.g., disman
schedule MIB. Alternate approach: defining static
config tables.

Design w/ multiple managers in mind (provide
appropriate locking mechanisms, such as spinlock,

Define read-write objs at "right" level of
abstraction.  Too many instances to configure may
mean abstracting the mgmt interface. A lot of
MIBs have too many details--if I have to config
1000 rows to put ACLs on my router, I probably
won't use SNMP.

Randy: Providing individual controls on
generation of notifications at the MIB level
interacts with the Notification Log MIB and
access control in 2575, seems like it invites
a multi-manager problem.


Jon: One clarification: Wrt notifications, you
want to create them at the appropriate level of
abstraction. Some things shouldn't be notifiable
(e.g. queue depth change).  Try to decide where
does it make sense to have a notification, then
choose level.

Jon Saperia then continued with discussion of the
BCP doc.  More recommendations include:

Management software:  Make SET PDUs as efficient
as possible by grouping as many varbinds as makes
sense.  Take advantage of AGENT-CAPS if
available.  Make config ops as parallel as
possible (support concurrent Sets as makes

Use notifications to relate changed configuration
to one or more mgmt stations. (ability to
timestamp, rollback, etc.)

Policy management:

Provide implementation-specific MIB objects if
instance-specific vendor extensions have been

Policy mgmt apps should determine the
time-keeping abilities of managed systems. E.g.,
could either have the mgmt app send down policy
at particular times, or have devices that know
what time it is turn policy on at particular

A notification should be sent when a policy
override occurs. Overrides may be necessary, but
when allowed, need to let mgr know.

Q: On making sets as large as possible:  You need
to know more about the device before you can know
if an entire Set of varbinds will work together.
So sometimes conservative policy is best.

Harrington: If you send large SET packets, you
can tie up bandwidth (v1) figuring out what went

Perkins: Business logic is duplicated in the mgr
app as well as agent. If I decide to change
rules, I need to update in two places. It's been
proposed over the past 10 years that SETS could
return an app-level error, so that business logic
could be done in agent.  Agent might return
"can't do this op because of constraints X,Y,Z".

Jon: Agent error reporting for config ops would
be useful.

Perkins: Access control is very fine-grained in
SNMP. It's hard to relate from a user point of
view what I need to config in VACM to perform
high-level operations.

Q: You say it's necessary to notify when config
changes or when there's a policy override. Are
they really different?

Jon: Not every element in a system is necessarily
under policy control. So if something isn't under
policy control, you need to send config change
trap.  Secondly, the policy override is meant to
keep the policy mgmt system informed about things
it thinks it controls being temporarily removed
from its control.

Q: About throttling notifications. Would be nice
to have mgrs subscribe to different sets of
traps. More flexibility.

Juergen: Need better specifications in MIB docs.
Procedures for app writers on proper sequence of
SET ops. So really need better documentation in

Perkins:  I support that, I typically advise that
the table DESCRIPTION tells meta-level info (e.g. if you
have this many slots, you have this many rows),
ROW description gives entry-specific info.

Andy: One of the big problems with SETs is
arbitrary and incomplete rows that you need to
handle. (E.g., many set requests for different
rows in 11 different tables, all bundled in one
SET PDU). We could get rid of a lot of this
complexity.  BCP touched on rowStatus and how
many items in a PDU.  We really should address
this in the SMI.

Randy: Regarding complex SET requests--the
infamous "as if" simultaneous requirement in
the protocol is the root cause.

Andy:  About the House lighting MIB and House
lighting Policy MIB...why not just add a table to
the House Lighting MIB?  House lighting MIB could
have templates.  Not clear how there's a
reduction of work in having two MIBs. You still
need to have perfect knowledge of the low-level
MIB to do the Policy MIB.

As there was time remaining, the wg moved on to
Friday agenda items, with a presentation on
"Policy Processing Questions" by Steve

1) An agent that gets a bad policy should do the
right thing, where the right thing is TBD. A bad
policy is one that has a syntax error or that
creates a processing error. The right thing is
terminate immediately.

2) Expression examples would be helpful (the new draft is OK in this).

3) How do we handle syntax errors?

Harrington: Need clarification: syntax errors at
processing time vs load time.

Andy: Delay of syntax error returns goes against
SNMP approaches to have SNMP agent reply about
success/failure of SETs immediately

  - Can a management station step through an expression statement
    to find errors? No.
  - An agent can't reasonably go through every code path in a script to
    look for potential errors & return such at SET time.
  - To the extent that these are described in BNF, the agent should be
    able to verify that they adhere to the language (BNF) syntax
    without evaluating correctness.
  - Is there value in doing the check at SET time? Limited value.
  - Protecting the agent from overruns is different from other types of
    checking of valid operations.

4) How do we handle run time exceptions?  How many errors are OK in a
    policy? (0?)

5) How to deal with partial failures and notifications thereof?

6) Different types of exceptions, e.g. divide-by-zero or system
failures--how to handle different error severities?

Juergen: What is the relationship of this work to
the disman Script and Expression MIBs?

Steve: They are different to address different
(though similar) problems

Case:  There are strong similarities between
disman and this work.

Randy: Why are there scripts?

Steve: Network operators are comfortable with the
use of scripts.

7) What is the role of the management application
in evaluating expressions?

8) What type of error reporting from agents is

The meeting adjourned for further discussion on Friday.