Re: Meeting minutes

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Vikas> Will the meeting minutes from Phoenix be available on this list?

Attached are private notes from the meeting. There may be significant
stuff missing, incorrect names, etc.  These are *not* the `official'
minutes.  I post them just to give a first impression and to support
the minute taker(s).

 -frank


OPS-NM Interim, May 22-23, 2001, Scottsdale

Net Management Protocol Folk and Net Operators - Reality Check #2
=================================================================

May 22-23, 2001  7-10pm on 22nd
                 9am-1:30pm on 23rd

  Chaired by Bert Weijnen
  Attended by ~50 people, only ~8 raised hands being operators
  Minute Takers: Jeff Case and one women from the operators


Prelimenary Agenda
------------------

  - Agenda bashing and intro

  - From SNMP people
    - How can SNMP and MIBs help manage your network
    - New developments SNMPCONF and EOS

  - Operator experience with SNMP 
    - how it has been and is being used
    - issues with SNMP
    - area it does not help with

  - From COPS people
    - how COPS and PIBs can help manage your network

  - Operator experience with COPS (if any)

  - From POLICY people
    - how policy framework and tools will help manage your network

  - Operator experience with POLICY (if any)

  - Operator requirements
    - what are the real hot issues to be solved this year
    - what are the constraints within which the tools have to work

  - Next steps

  - Wrapup/Summary



1. Agenda bashing and intro

Idea: very short presentations as a starting point. And then extended
discussions. Objective of the meeting: Makes all the IETF work in this
area any sense?

Operators claim: `we use CLI for configuration'. Other bodies suggest
CORBA, WBEM, XML, ... Did we hear any operators who want this?  So,
are we wasting our time in the IETF? How can we make the IETF work
relevant? Let's not make this a tutorial; let's have a lively
discussion!

All attendees shortly introduced themselves. Most are IETF
people/vendors, just 6-8 are operators. Total: approx. 30-40 people.


2. SNMP, MIBs, SNMPCONF, EOS
   Presentation part by Jeff Case

JC (Jeff Case) presents status of (a) protocol, (b) standards MIBs,
(c) private MIBs, and (d) depolyment in the FCAPS categories:

- Fault mgmt: yes, yes, yes, yes

Discussion already started: Simon Leinen (Swiss operator): We use SNMP
fault management only for very simple stuff. Complex stuff is too
expensive. Actions upon notifications are often not SNMP
oriented. Jon: Would it be useful to use SNMP here too?  Scott Hahn:
The MIBs often don't give you the information you really want. Jeff:
ok, you're using a different tool. But: Are you happy with that tool?
Tracy: Why not using another tool like CLI after you got the
notification!? Andy: CLI is a *human* interface. This is why we need
something else. Agreement: CLI is a human/machine interface, SNMP is a
machine/machine interface.  Operator: There are limits to what you can
expect to be automated.  It's really difficult to correlate events to
find the real cause of a problem. Jon: In many machines the
information you need is not available via SNMP. Often CLI is
implemented earlier, so expect script are developed. Then when a MIB
is available there is not much motivation for changes. MIB
implementations are often bad, e.g. returning zero for undeterminable
values. Steve Bellovin: It's difficult to establish standard MIBs
amoung a number of vendors. It's easier to fiddle with configuration
files than to handle SNMP. It's probably impossible to build a
shrink-wrapped generic event correlation system.  Ran knows about a
single SNMP success story about an event correlation system for cable
modems, reason: they have no CLI (TFTP is used to `upload' sequences
of SNMP Set requests). One key to success: getting MIBs deployed
sooner. Andy: It's roughly ten times more work to implement a MIB than
to implement CLI functionality. Ran: What could help for configuration
is to set large chunks more or less atomically. Ran: ``Operator to
Vendor: give us SNMPv3 cable modems to achieve security. Vendor: no,
too costly.''  Ran as a vendor: more customers ask for SSH than for
SNMPv3 security.

- Configuration: yes, partial, yes, partial
- Accounting: yes, yes, yes, 1/2
- Performance: yes, yes, yes, 1/2
- Security: yes, no, yes, no

Vendors are not motivated to comply with standards by default
(complexity, costs compared to CLI).  Customers have to work with
whatever they get. Often they prefer CLI via SSH/Telnet.  Standards
view: MIBs for configuration management are being developed.  Security
now available. Vendors are not completely and correctly implementing
and users aren't deploying the standards they have now. So what's
the point in making more? Cynic: should we standardize CLI?

[...] Operator: I don't really care about the underlying mechanism,
as long as my configuration is provisioned from the database to the
device. Currently, CLI fits best (of what's available) in many cases.


3. POLICY: Policy Framework
   Presentation part by Bob Moore

Policy Framework WG: (1) Policy Core Information Model (RFC 3060), (2)
several I-Ds: LDAP Schema, QoS PIM, QoS Device Datapath IM, ...
Related Work: IPsec Policy WG, DMTF SLA WG, DMTF LDAP Mapping WG.
Presentation of the Basic Policy Architecture: Policy Mgmt Tool,
Policy Repository, PDP, PEP. Further explanations of what a policy
is. Policies are applyable in two ways: (1) on decision which
configuration is provisioned to which device, and (2) on decisions at
runtime within the device. Future/Research: Policy adaption,
i.e. autmated adaption of in cases where they don't fit their
intentions.

Steve W.: Are we on the right track? Operator: we should think more
about real applications of policies and what's *really doable*, rather
than what polcies *could* be used for. Randy Bush: Who here uses QoS,
RSVP, DiffServ, ...?  [Nobody. Laughing. But results seem to be unfair
because there are not many operators present.] Many operators seem to
use Perl scripts that ensure to send the right configuration to the
right device. That's a kind of policy based configuration. Some
operators poll their devices frequently and do cvs diff to detect
configuration changes. Most operators have a completely database
centric setup.

[First day ends at 22.oo, followed by some lively offline discussions.]

[On the second day some more attendees: ~50-55.]

4. SNMPCONF
   Presentation part by Jon Saperia

Jon presents goals of the SNMPCONF work. Idea: Do more with less, more
efficiently.  Discussion: We want to have a more standardized API for
configuration, and that's not necessarily SNMP based. Question: Do we
need more knobs on the machines? We need more powerful knobs, i.e. a
higher level of abstraction. This are getting more diverse, at least
at the edges.  Pres. cont.: SNMPCONF output: (1) BCP, (2) PM-MIB, (3)
PM-based DiffServ Provisioning MIB. Principles: templates, no new
infrastructure, simple scripts. Terms. Example. Jeff adds two examples
of filter/action. Bert asks: Does this look reasonable? Is this what
operator wish to have bigger knobs? VJ (Operator): This is an example
of where people try to help where we don't need help. In world we
cannot trust lots of simple MIBs (incomplete, incorrect
implementations), how can we trust on such a complex SNMPCONF MIB
stuff?

VJ in front: What we really need is a common config language. Easy way
to provision database config to the devices. Easy way to poll data
from the devices. Q: Why would you like XML? VJ: Doesn't matter so
such. I But I don't like to make things just slightly better but
totally different.  XML would help to unify.  Dave P.: Why is ASCII so
important? VJ: We like things that are simple, understandable and that
we can look at. Wish: Every router comming with a DTD. Ran: operators
demand could press vendors to support such DTDs. Vikas Treshan:
XML/SNMP/CLI are just ways to transport/encode. The problem comes with
variation of contents. Bob: Scalabity. Imagine a router with 500
interfaces, would you suggest to provision 500 similar records?  VJ: I
would prefer a template mechanism. Jon: configuration seems relatively
static. VJ: agrees.  VJ: we don't need this dynamic adaption, if
someone plugs in a new interface. This happens very infrequently. What
we need is a way to provision configuration to the device, e.g. if a
crashed device has been replaced. We want a simple readable format.
Ran: Which operators do think a high-level configruation language (no
matter whether executed on the device or on the nms) is useful?
~8 raised hands (all present operators). 

Randy: I read to wishes: (1) a configuration mechanism, (2) a
mechanism to fetch the device capabilites. Do we wish to have the
*same* mechanism for both? Both should be at lease vendor-independent.

~8 operators would volunteer to work on an operators-requirements
draft.  Note that this would be driven by Internet operators needs,
not by rbucks(?) needs.


5. COPS, PIBs
   Presentation part by Scott Hahn

Scott gives a short presentation of the COPS architecture,
protocol, usage models (outsourcing, provisioning), documents.
Intel Open Source SDK: www.intel.com/ial/cops (Linux and Windows).
COPS is not intended to replace SNMP, it's intended to fill the
gap of configuration management.

Operators want to have a common language, no matter how it gets
into the box.

Bert: Shall we have meetings like this at every IETF? Hopefully we
will be able to talk about a requirements documents at the next
meeting. Let's have BOFs during the next NANOGs in order to make it
easy for operators to get in. We need both, a large (rather passive)
group, and also a small group of people getting actively involved.
Hence, 1-2 days after a NONOG seems reasonable. Probably scheduling
on same day as tutorials (Sundays). Jeff proposes to set up a mailing
list based on the blue sheet. ops-nm@ops.ietf.org will be set up
in five minutes. ;-)

Susan Wolf and Bill Witcock [check names with blue sheet] are
volunteering for the I-D.

[Closing meeting at 12:30.]