[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minutes from interim meeting -- scottsdale arizona
Vikas Trehan wrote
Vikas> Will the meeting minutes from Phoenix be available on this list?
Bert Wijnen replied (May 27 2001)
Bert>3 people have been taking minutes that they will/have sent to me and
Bert>that I will merge into a "official minutes". That will be posted for
Bert>review comments, and then we will submit them to minutes@ietf.org
Bert>together with the slides that were presented. They will then be
Bert>included in official IETF proceddings.
Bert>
Bert>Bert
I sent these rough notes to Bert at the end of May but they somehow
got lost and never appeared on the list. I am posting these (with
Bert's permission) so that there is *something* out there before
tomorrow's meeting, even though these are my raw notes rather than
the merged official minutes. Frank Strauss's notes can also be
found in the archive.
My presentation slides can be found by following the Conference Presentations
link at www.snmp.com.
best regards,
jdc
---------------------------------------------------------------------------
Operations and Management Open Area Meeting
May 22-23, 2001
Doubletree Hotel
Scottsdale, Arizona USA
Day 1
Bert Wijnen called the meeting to order at about 7 pm.
Bert noted Randy Bush's new affiliation.
Administrivia
"Blue" sheets were circulated.
Minute takers appointed. Jeff Case and Ann Cerio??? @ Verio.
Thanks to Lucent for underwriting the expense of the meeting.
Agenda Bashing.
Bert introduced the agenda.
The group decided to finish by 1:30 p.m. on Wednesday.
Introduction
Bert introduced the meeting, addressing the question, "Why are we
here?" and going over the goals of the meeting: garnering operator
input so as to insure that the IETF work is relevant to their needs.
A few people are to do presentations, not tutorials or sales pitches,
but to get focused discussions started.
Someone suggested that we take a few minutes for introductions. In turn,
participants took a moment to identify themselves, their affiliations, and
briefly what they do.
Presentation/Discussion 1
Jeff Case presented a set of four slides describing the state of
the art, and how we got to this point in the interest of spurring
discussion. Much discussion followed. Some of the key points
captured include:
One person observed that SNMP is good for basic faults but
for more complex faults it has shortcomings. Difficulty
downloading routing tables was cited.
A discussion followed about the fact that ping, traceroute
and CLI are used extensively for diagnosis and whether this
is a problem.
One person observed that operators aren't getting involved in
the standards process.
One person commented that it is easier to work with CLI than SNMP
because you can work with CLI in a text editor but you can't do the
same with SNMP.
One person spoke of his experience with Cable Modems which are fully
manageable with SNMP and in fact have no CLI interface.
One correction was made to the presentation slides -- that we
should really be talking about CLI over SSH instead of CLI over
Telnet.
Presentation/Discussion 2
Bob Moore presented a set of slides describing the status of IETF work
on core policy. Bob described the status of the Policy Framework
Working Group of the IETF.
In the discussion that followed, some of the key points captured include:
Q: Are we on the right track in investing a lot on how to manage
using policy?
A1: Don't use any of this.
A2: It is interesting to think about what policies are in use
versus what policies could be in use.
Some of the operators offered descriptions of how they automatically
generate router configurations. It was stated that their work is
inspired by C and Perl, not by a policy model.
While Verio autogenerates everything, Verio is somewhat exceptional
in this regard.
With respect to using SNMP to convey configuration data, having
config data separate from all other data would be a help, i.e., in
a dump of MIB data, configuration data are entangled with counters,
etc.
Someone observed that the folks in NOCs use SNMP whereas configuration
geeks use CLI. (Note that geek was not used in a pejorative sense.)
Geeks don't know SNMP but know CLI.
One illuminating perspective is the answer to the question "What is
the authoritative configuration database?"
The network?
The central database?
The operators indicated their reluctance to put in new technologies
because of manageability issues, especially a critical need for
experienced staffing.
It was observed that the hard part of automating management is the
database, especially information about customers.
It was observed that some of the current IETF work is viewed as
a wasted effort by some operators -- for example, work in EOS to
conserve bandwidth through OID compression and suppression. Bandwidth
preservation is not that important given the amount of bandwidth
coming on line and available to these operators. Stability and
safety (in the form of mitigating risk) are more important to some
operators than are these tweaks.
The group then temporarily digressed into a bit of a rathole, exploring
why users experience delays and poor performance if there is so much
excess bandwidth. It was stated that much of the core is well
engineered, with little queueing, little jitter. The stuff at the
edges is typically not nearly so well engineered.
The operators present shared their philosophy that it is less
expensive to overprovision than to do bandwidth allocation
schemes such as QoS, DiffServ, etc.
Someone thought it is worthwhile to note that the operations
personnel present are reflective of a very narrow slice of
operators, mostly facility based, tier 1 backbone operators, and
they tend to be big backbone operators.
Other operators may have different needs.
Presentation/Discussion 3
Jon Saperia was to talk about the IETF SNMPCONF Working Group but experienced
laptop trouble. Given the lateness of the hour, this was punted to
9:00 a.m. Wednesday.
The meeting recessed just before 10:00 p.m.
End of Day 1
-----------
Day 2
Wednesday
Bert Wijnen called the meeting back to order at approximately 9:00 a.m.
Presentation/Discussion 3
Jon Saperia made a brief presentation on the work of the IETF SNMPCONF
Working Group. During the discussion that followed, some of the key
points captured include:
It was again noted that there is little demand in the room for QoS,
the right approach to throw bandwidth at the problem.
Someone presented a counterexample from NASA and getting bandwidth
to Iowa, similar to the needs of a large private network.
It was observed that the customer view may be different from that
backbone provider view ... in some cases, customers are intently
focused on how to move traffic the most efficiently and at the
lowest cost, in part, because more bandwidth equates to more cost
to the end user. In addition, in these cases sometimes increasing
the pipe takes years.
The current methods for configuring routers are too inefficient, with
too many humans doing things by hand, and more automation would be
helpful ... doing configuration in a structured and disciplined way.
Today, most router configuration is done with expect scripts tweaked
for particular managed products. Backbone providers have a high
degree of homogeneity in the managed products they configure,
typically only two vendors.
Part of the problem is that router vendors wish to differentiate
their human interface to the router. Some operators indicated their
desire for a more stable and programmatic interface to configure
their routers devices.
One speaker observed that SNMP is too simple to meet his needs and
would like an abstraction above SNMP.
Another speaker noted that there is a distinction between
transport/encoding and the semantics behind the meanings of the
commands.
One speaker requested something more verbose (although this notetaker
believes he might have misspoke, meaning to say less verbose because
he also asked for something more powerful), something easier to
read, ...
That is, they would like to have a smaller number of more powerful
knobs. Perhaps, something like management information that works
at the phrase level or sentence level rather than the word level.
Someone asked about CORBA as a possibility for a platform independent
OSS but the question was never answered nor was there much interest
in discussing this.
It was observed that not everybody does one thing. In fact, most
people do/use many things to perform configuration.
One speaker observed that unifying tools would be very nice, but it
does not happen rapidly.
There was a stated desire for a universal language for configuring
routers, as vendor independent and product independent as possible,
possibly including element managers for routers.
Presentation/Discussion 4
The meeting then departed from the agenda and established pattern
somewhat. VJ Gill [spelling?] was convinced to come to the front to
talk about his perceptions of unsolved problems. VJ was formerly at
UUNet, and is now at metromedia ????
He believes what he really needs are some simple tools ... simpler is
better in his view.
His configuration activities are to configure a very few things that look
a lot the same.
What they need is a common configuration language. When they deploy a
new (different) device, they need to rewrite their scripts to accommodate
it.
He would like to pull data out of the box using an ASCII-based simple
output command that he can tie to his Perl and expect scripts.
He presented the use of XML as a strawman. He is looking for something
that is simple, ASCII, and which does what it needs to do.
He sees common abstractions in vendor specific configurations.
He perhaps would like to see query by example.
Q: Why is ascii so important in terms of the transport?
A: Want simple, understandable, something they can look at on the wire.
They must be able to fix the network from a VT100.
They must be able to do configuration from the craft access port
He then shared his vision of configuration via XML. XML would be used
as a transport from the database to the router. Each router would come
with a DTD, perhaps a standardized DTD. He knows he will not get
complete alignment, but an 80/20 solution would be a help.
He is also seeking an abstract language to represent routers for use
in simulations.
When they have 600+ identically configured interfaces, then they ask the
vendors to build a template and if something is not specifically
configured, it falls back to a template and you only config the diffs
from the template. For example, when configuring a peer group in a cisco
router, you use a template, from which the data are incorporated by
reference.
The discussion revealed that the environment in which:
The operational methodologies reflect that the organizations are
very risk averse, where things are very static and change is
viewed with suspicion and care.
The number of devices to be configured is much, much lower than
that encountered by enterprise managers, only 300 to 3000 boxes.
Q: How many interfaces on each box?
A: Typically 600 interfaces to customers and 8 interfaces to uplinks.
The amount of heterogeneity is much, much lower than that encountered
by enterprise managers, typically only two brands of routers.
They would like to have different access levels for junior people
versus senior people, e.g., a junior person might be able to select
one choice from a set of preconfigured templates but could not
add nor alter a template -- an operation which would require the
privs of a senior person.
There is a need to be able to do a full load of a box, i.e., a crash
recovery after a hardware replacement requiring a load of an entire
configuration.
The general consensus among operations persons present is that a high
level configuration language would be a help, a language that is ideally
mechanism neutral.
Q: What would such a language look like?
A: A parsable language
Q: What are some of the verbs and elements?
A: Interfaces, customers, BGP globs, filtering and rules,
applications to aggregates of interfaces, e.g., all interfaces going
to peers with a particular prefix, rules about how you access the box,
rules about how the box is monitored
Statement: "By the way, we love SNMP-based monitoring and traps lest the
SNMP group feel abused."
There is a need for a unified way to go from the database to what is
happening
They have some clues about what they want in the database
They need to close the gap
Some operators are working together to noodle some requirements.
They don't want to have to go to each vendor 1 by 1, can see some
possible benefits of the standardization process in this regard.
It was again observed that stability and determinism are more important
important than efficiency.
One vendor observed that the most active input to vendors is not from
internet operators but from RBOCs. The vendors need additional clear
input from the internet operators in addition to what they are hearing
from the RBOCs.
Mid-way break 11:00ish - 11:30ish
Presentation/Discussion 5
Next, after the break, Scott Hahn presented information about the work of
the IETF RAP Working Group and the COPS protocol for configuration in
particular. The some of the key points captured from the discussion that
ensued include the following:
Some vendors have COPS but cannot find customers to buy it.
XML over HTTP does not have a necessary feedback mechanism and COPS
has that necessary feedback mechanism.
There was not much discussion of Scott's presentation. The discussion
rapidly returned to the language discussion. There are at least two
approaches:
1. Define the language, figure out how to move it later
2. Start with representations
There wasn't any apparent consensus on the preferred approach.
After further discussion, one person observed that there are other
choices such as a linear syntax versus entity relations versus other
paradigms.
A pseudo consensus formed around an approach of wanting to think about things
in the following order:
1. the management information we need to describe what it takes to
configure a device
2. next consider the language
3. worry about how to transport the information
Moving forward
The group then grappled with next steps and outcomes.
One outcome is to get people started writing down the requirements in
a document so that it can be discussed.
An observation was that the meeting had been a useful meeting of
different cultures.
A follow-on activity is to get more diversity of operators in these
discussions.
Perhaps a BOF session during a multi-track session at future
meetings of NANOG.
There was a sentiment that a retreat-like atmosphere such as the
one of this meeting is best because of avoiding scheduling conflicts.
Someone suggested that the meeting be scheduled on Sunday as are
NANOG tutorials.
Someone suggested that another set of input could be collected at RIPE.
A mailing list was suggested and created.
[Check this before publication]
ops-nm@ops.ietf.org
Subscribe via ops-nm-request@ops.ietf.org
or
send to majordomo@ops.ietf.org
with subscribe ops-nm in the message body
Minutes and slides are to be sent to Bert Wijnen. Bert will compile
the notes from the notetakers and post the compilation to the list.
Someone suggested an additional possibilities for followup: revisit
writable objects in existing MIB objects.
Randy Bush has predicted that we can gather additional input from other
groups but he expects that we will find the requirements of tier 2, tier 3,
and enterprise managers will be similar to those expressed by the tier 1
operations represented at the meetings. Others disagreed.
Bert is unlikely to charter new IETF work in this area until the requirements
are in place.
To that end, Suzanne Woolf, woolf@isi.edu, or woolf@mfnx.net, and Bill Woodcock,
woody@pch.net, are to edit a draft, along with input from other operators to
get a strawman draft penned for discussion in time for the id cutoff for the
London IETF meeting.
The meeting adjourned early, at about 12:30 pm.
End of Day 2
Respectfully submitted,
JDC