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

snmpconf IETF 49 SNMPconf WG notes



SNMPconf - December 14, 2000 13:00 - 15:00, and
December 15, 2000 09:00 - 11:30
Charter: http://www.ietf.org/html.charters/snmpconf-charter.html
Chairs: Jon Saperia (saperia@idscons.com) and
David Partain (David.Partain@ericsson.com)
Agenda was published as
http://www.ietf.org/ietf/00dec/snmpconf-agenda.txt,
and the only changes made were re-arrangements of topics due to time
constraints.
The note takers for the sessions were Rob Frye (rfrye@longsys.com),
Russell Dietz (rdietz@hifn.com), and Steve Moulton (moulton@snmp.com).

David Partain opened the meeting, Blue attendance
sheets were circulated.  Jon Saperia indicated what the
current drafts are, how to join the mailing list, and
displayed the agenda.

The first day of the meeting had presentation and
discussion of the Policy Management MIB with some related
discussions about accessors and language features, and the
presentation of status on the Configuring Networks and
Devices with SNMP BCP.  Day two had more accessor and
language discussion and a presentation of issues that have
arisen in the DiffServ Policy MIB.  The text of these
meeting notes have been re-arranged to keep the accessor
and language items together.

Session One: December 14, 2000 13:00 - 15:00
The first document discussed was the Policy Management MIB
(draft-ietf-snmpconf-pm-04.txt), presented by Steve
Waldbusser.  There was much work done on the current
version; 5 slides of changes were presented.  Some of the
significant highlights are:
- Scratchpad functions were extended and include scoping,
examples of scoping were given.
- Parameter tokens $1 through $9 were increased to allow
$01 thru $99, and these parameters are available in local
variables.
- Text was changed to use const" in the document for built-in constants,

rather than "#define".
- A gap was added in numbering between data types & error codes to
allow enough room for future data type expansion.
- Added pmPolicyAbnormalTerminations, which counts the number of times
that policy execution has failed.
- Minimal varbind list length was changed to 32 variables (from 60) for
each Policy instance.
- Added 64-bit "long long int" integers, getint() modified to return
"long int".
- Added array derefencing; the contents of octet string
objects in strings can now be returned and a way was needed to access
binary data in octet strings.
- Added support for Strings.
- Filter scripts execute immediately when network elements are
discovered; action scripts execute immediately when its related
Filter evaluates TRUE.
- A script code table was added for scripts that are larger
than the MTU; multiple SNMP sets will be needed to build
the script, then reference it in the other MIBs to
trigger its execution.
- Added newCapability & newRole notifications, add
registration table for managers to receive these notifications.
- A description of the handling of SNMP errors was added.
- New BNF was defined to account for the various changes made; there
may be some discussion of the BNF on the mailing list.
- ISO C, not ANSI C (X3J11), will be used as the standard language
definition; with the addition of String support, there
was some discussion about making C++ the standard
language definition though conclusion was reached that C should continue

to be the standard reference, due to concerns about needing to make it
simple so implementation on embedded platforms would be possible.
This may not be relevant, as the BNF describes a subset
of C or C++ anyway.
- A question was raised about whether this language
definition & SMING should be combined, or at least use
the SMIng functions in the SNMPconf language.  However, SMING is data
definition oriented, whereas the SNMPconf policy language is operator
oriented, which makes SMING inappropriate at present for the
SNMPconf expression language.  Furthermore, because of the state of
SMING,
it is not yet possible for SNMPconf drafts to make reference to SMING
documents, other than as "works in progress".  Therefore, between the
C/C++
issues and SMING issues, we should stick with the C reference and then
add
the items we need from C++.  There may be further discussion on the list

about this, if anyone disagrees with this approach.

There was a question on the example given of
pmPolicyAbnormalTerminations that led to the conclusion
that more clarifying text is needed.

There was some discussion about the notification
registration table, as to whether it is like RFC 2573's
trapFilterTable & trapForwardingTable [correction:
snmpNotifyFilterTable and snmpNotifyTable, respectively].
Although there are similarities, the RFC 2573 tables are
not appropriate, as the snmpNotifyFilterTable is based on
an information bus model; all traps from all sources go
thru that table.  This did not reach satisfactory
conclusion and will be considered & discussed further on
the mailing list.  Similar discussion was related to the code
table vs VACM in SNMPv3.  No satisfactory conclusion was reached
and this topic will be considered & discussed further on the
mailing list.

Some Security issues were discussed and will be added into
the draft.  In particular, dealing with SNMP actions in
scripts - how security parameters are to the SNMP calls,
and Mid-level manager inherited access writes - how to
decide which security parameters to use.

Policy Grouping for precedence was discussed, particularly
that we ensure that when a policy is no longer valid,
rather than waiting for "max latency" time to expire, when
Policy C terminates and "uncovers" Policy B, that B would
execute immediately.  To accomplish this, an "on exit"
clause was discussed so that policies would go to a
"quiescent" state when the policy is no longer in effect,
and use precedence & grouping so that a "normal" policy
runs all the time when some higher-priority policy is NOT
running.  Error conditions need to be considered, where
setting of some variables depend on other settings
elsewhere.

Policies run while the schedule indicates the policy is
active and are dormant otherwise; some sets of policies are
interrelated and these sets of policies should be turned on
and off in tandem.  Edge triggered versus level triggered
scheduling (with addition of duration) was discussed to
accomplish this; using edge-triggered scheduling, pairs of
scheduleEntry's would be needed to accomplish one schedule
although the addition of duration is not sufficient to
provide sufficient level-triggered semantics.  It was
agreed that level-triggered scheduling is desired.  There
are unreliable semantics regarding when multiple, potential
overlapping schedules touch a policy; consensus was that we
probably want the semantic that the policy is active if ANY
associated schedule is active.  There was some discussion
about whether the DisMan ScheduleMIB would provide the
needed functionality, or if we could use it and change the
meaning of certain objects when used with the Policy
management MIB - it was agreed that this could result in
confusion.  The difficulty in having one policy clean up
from another was discussed, with the possibility of having
the scheduler do some cleanup (ie, do more than simple
scheduling, such as be a "schedule guardian" or "ober-scheduler").
No matter what happens, the new policy must be able to determine
the result.  Based on the concerns outlined by Steve in his
presentation,
Jon Saperia presented a new pmSchedTable to the group designed to
address
these concerns. This will be the basis for another revision of the
draft.
Further work is needed in the scheduling (pmSchedTable) area.

Possible future draft changes include adding "pass by
reference" and automatic initialization, to be discussed
further on the list as needed.

The next document was Configuring Networks and Devices with
SNMP (draft-ietf-snmpconf-bcp-03.txt), presented by Wayne
Tackabury.  Some highlights of that presentation:
- The scope was clarified, text was thoroughly
reorganized, examples were expanded & clarified.  The
scope of the draft is to provide guidance on current
practices using SNMP for configuration, focusing on
using SNMPv3 and to provide the groundwork for policy-
based SNMP configuration.  The draft provides guidance
for ISP Operators in SNMP deployment practices and
configuration change diagnostics, guidance to
agent/MIBmodule developers for developing coherent and
scalable settable row objects and other features, and
guidance to management station developers in
implementing transactional semantics.
- A request was made for text to be contributed
describing how some agent implementions do a lot of
things incorrectly and how management stations can
cope with these poor agent implementations.
- The current draft needs WG review and further editing;
particularly security issues discussion.  The plan is
to go to WG last call after IETF 50 while avoiding
scope creep.  It is intended for Standards-track as
BCP.

Session Two: December 15, 2000 09:00 - 11:30
With some examples from the Policy Management MIB, Steve
Waldbusser led the discussion of Accessor Functions and
Language Issues.

Language and Accessor Function issues included the following.
- In the Accessor Functions discussions (particularly in the first
session), several examples were given, both simple (involving simple
settings of integers) and complex (setting up RMON2 alMatrix
monitoring).
These examples were used to show flaws of certain approaches and the use

of the searchColumnEntry or storing the OID/index in the scratchpad
between invocations.
- There was some discussion about how resource cleanup would occur,
particularly considering that there is no automatic garbage collection.
No solution was reached in the meeting and may be discussed further on
the mailing list.
- It was generally agreed to do "pass by reference" so that "&" is not
needed when passing parameters to accessor functions.
- Automatic, non-default, initialization was added.  This occurs
whenever a script becomes active.
- There was considerable discussion about the need to
support both createAndWait or createAndGo operations.
The group consensus was that both createAndWait and
createAndGo should be provided.
- The createAndWait/createAndGo discussion led into a
discussion of the staging of building PDUs to send (or
parsing/reading received PDUs) - whether by passing of
varbinds 1 at a time vs a "varargs" approach.  There
was no clear consensus, so a small design team (Steve
Waldbusser, Juergen Schoenwalder) will consider the
possible approaches for building PDUs, including PDUs as objects
with operator overloading.
- The next significant discussion was whether or not to
add a "setCli()" function to interact with command
line interface mechanisms (analogous to the "system"
function call on Unix).  Major concerns are of it
being used in heterogeneous environments, it is ugly
and goes against standards although is very practical, the
numerous security issues (eg: how to map SNMP context
to "login" equivalent), etc.  Many reasons were given
for doing so (even by those who would prefer not to),
and many reasons against it.  No consensus was
reached, so we decided that this is to be investigated
further - it was agreed that it's a bad thing to do,
that the benefits may not outweigh the bad things.  We
will continue discussion on the list.

Policy Grouping discussions were next.  The
policyGroup & policyPrecedence semantics have not been
worked out entirely, although in general lower
numbered precedence value gives higher priority within
a group, and the highest precedence policy whose
filter allows it to run at a given time "wins".  Time-
ordering of policies within a group may be critical.
It was agreed that any particular policy (action)
should run as an atomic transaction.  An entire
policyGroup should be considered as a single logical
policy, such that all policies are running at once,
depending on what filters trigger for given elements.

Some discussion was done regarding booting/startup.
Specifically, any policy not in a group can fire
immediately, within its schedule, and for those in a
group, no Policy can run, except for the highest
Precedence policy, until all filters for all policies
in the group have been evaluated.  More discussion
took place on the issue of what to do on "policy
replacement" - what to do when PolicyB trumps PolicyA,
B runs, then B terminates.  The conclusion was that it
is necessary to immediately re-evaluate A's filter &
schedule to determine if PolicyA's actions need to be
invoked.  This leads to different windows of
evaluating precedence and filters, and deciding
appropriate actions.  Filters should be rechecked
immediately when precedence changes, new policies are
added, or old policies are deleted.  It was agreed
that this needs further consideration on the list.

The next draft discussed was The DiffServ Policy MIB
(draft-ietf-snmpconf-diffpolicy-03.txt), presented by
Harrie Hazewinkel and Bob Moore.  Harrie gave some
background of what DiffServ is all about, then used
the diffServDataPathTable in DIFFSERV-MIB as a
starting point for SNMPconf policy-management
discussions.

The DIFFSERV-POLICY-MIB is used to
create templates with classifier, meter, actions drop,
mark, and count using the diffPolicyDPCTable.  A
Policy example was used for providing gold service,
applying EF marking to packets from certain customers.
Obsoleted entries could be garbage collected, which is
not currently defined in standard.  There are further
issues related to garbage collection, such as being
able to tell if something SHOULD be GC'd.  The
conclusion was reached that we need to use template
cloning with a single SNMP Set to build the right
diffserv policy, although that leads to further
problems with RowPointers.

Bob Moore then continued the discussion showing the
difficult interactions between Templates &
RowPointers.  The advantages of this approach for
doing data path parameterization was shown, and it was
shown that duplicating Templates does not require
duplicating parameterizations.  It was determined to
be necessary to identify in Templates what needs a new
row (new object to point to) vs re-using the same
object as in copied-from row(s).  There is no simple
answer to this; an example next-order problem was
shown with "fan-out/fan-in" linkages, with the desire
to share a new single instance rather than duplicating
instances.

The current diffserv MIB has only StaticRowPointers
which point "outside" of the template; it doesn't have
dynamic RowPointers.  It was suggested that an
appropriate approach might be to not focus on the
RowPointers, but on the pointed-to objects via a new
kind of TextualConvention, which would have the
negative effect of combining 2 distinct operations
together: copy & clone vs the value & use of the
objects.  There are 2 steps involved: generating
(creating the new row & new OID) or reusing
(referencing the row by copying the OID), and
determining how to plug in the relevant information to
referencing tables.

An ID has been submitted into the Management and
Operations area with 2 new TCs to handle these template
conditions.  However, that draft will likely be modified
and re-submitted (on the MIBs list) with just the one TC
that describes new behavior, not currently available with
the definition of RowPointer operations.  Meanwhile, the
DiffServe WG is moving ahead with their approach in
case the generalized ID doesn't become an RFC in time.
It was agreed that between now & the next IETF (IETF
50, March 2001), the diffserv examples will be updated
by David Partain.

To wrap up the meeting, Rob Frye agreed to distribute
notes to the WG list not later than 12/22/2000 [note:
they are being sent to Chairs on 12/25/2000].
There will be further discussion on the mailing list
for at most 2 weeks about the need for an interim
meeting before IETF 50 in March to discuss topics such
as the "setCLI" function.  We agreed to see how much
can be done on list first, then hold an interim
meeting if we do not reach consensus.  The existing
charter says that we will conclude our work by IETF 50
in March 2001.

--
// Rob.

Rob Frye
Director, Software Development
Longitude Systems, Inc.
15000 Conference Center Drive
Chantilly, VA  20151
www.longsys.com
voice:  +1-703-818-5426
fax:    +1-703-961-8751
mobile: +1-703-725-1130
email:  rfrye@longsys.com