[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.

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,


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.


    "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.


    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

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,

        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

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

        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

    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

    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

    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
        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
    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

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

        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]
        Subscribe via ops-nm-request@ops.ietf.org


        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,