2.4.12 Operations & Management Open Area (opsarea)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07


Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Goals and Milestones:


  • draft-ietf-ops-mib-review-guidelines-03.txt
  • draft-ietf-ops-vlanid-tc-mib-01.txt

    Request For Comments:

    RFC3291 PS Textual Conventions for Internet Network Addresses
    RFC3419 PS Textual Conventions for Transport Addresses
    RFC3595 PS Textual Conventions for IPv6 Flow Label

    Current Meeting Report

    OPS Area Meeting at IETF 61: Nov. 10, 2004

    Thanks to Andy Bierman for taking notes on which these minutes are based.

    - agenda: see OpsAreaAgenda61.ppt
    - no changes to agenda
    - added Management Considerations to agenda

    - OPSEC BOF:
    WG has been formed;
    will work on operational requirements to run a secure network

    - AAA WG not meeting at this IETF because they are almost done
    - aaa-eap on IESG plate
    - aaa-sip-application and aaa-uri drafts are not done

    - Possibly form a new Diameter Maintenance WG
    - focus on maintenance
    - possibly advance Diameter to DS

    - should this WG be formed?
    - no questions or comments, probably because the people in the room are not familiar enough with the details
    - comment on what maintenance scope really means
    - could it mean adding features left out of last update?
    - see details in: OpsAreaAgenda61.ppt

    - CAPWAP
    - initial work completed
    - CAP == Control and Provisioning
    - scope does not include other non-mgmt WAP issues
    - aggressive deadline for objectives document
    - this work will be done in coordination with IEEE 802.11

    - Bridge
    - WG will close down and transfer work to the IEEE 802.1 WG
    - Improve timeliness of MIB modules by reducing delay between protocol and MIB definition
    - Distribute the work load
    - Work will be done by the technology experts
    - Cross SDO coordination is improving
    - default liasons identified
    - cross-org review of new work
    - IETF MIB Doctors will review IEEE MIB modules, at least initially
    - MIB modules will be available in ASCII, not just PDF
    - no questions or comments from room
    - Bert: could be MIB Doctor resource issue; may need to prioritize IETF MIBs over IEEE MIBs
    - Dave Harrington: IEEE may assign a MIB coordinator to oversee progress and quality

    - Request to read and comment on I-D:
    This is an Interesting document that IESG approved recently You might want to take a look. It defines standard terminolgy for different kind of Internet services.

    - NGN Network Management
    - ITU-T focus group consists of 7 or 8 WGs
    - do not have a NM WG in this focus group
    - ITU-SG4 has accepted new work for a NM focus group
    - informal conf. call was held 11/1 between ITU, ETSI, TMF,
    and IETF people on the possiblity of working together
    - mailing list and FTP site will be created
    - participation will be on an individual basis
    - want people familiar with IETF NM work to participate

    OPS Area mailing list archive:

    - Sharon Chisholm: goals are to reduce operational costs for networks and reduce the duplication of effort across SDOs
    - Bert: they are starting out on terminology; they are top-down; we are bottom-up, so may not get to protocol detail right away
    - National Light Rail is another group that could be involved
    - Brain Carpenter: need a roadmap for better coordination so SDOs can plan their own work better and not duplicate efforts

    - Collaboration for Data Modeling
    - WEB Services Based NM (GGF, DMTF, OASIS, W3C, IETF)
    - had informal meeting between leadership of different SDOs
    - want to avoid duplicate work
    - MoU (Memorandum of Understanding) being worked out
    - goal is coordination and encourage information sharing
    - they want pre-planned conf calls and f2f meetings
    - possible issue wrt/ impact on NETCONF data modeling
    - initial work:
    - landscape doc
    - definitions and taxonomy
    - white paper, FAQ
    - they want a governance panel
    executive, technical, and liason
    - Sharon: this is the right group of people; could be the same type of effort as NGN; this could be a good thing
    - Eugene G:concerns about slowing down our work if we get really involved with industry consortiums and other SDOs
    - Brian C:value in knowing what else is going on but we don't want to be too dependent on schedules of other SDOs

    - Management Considerations section:
    - draft-farrel-rtg-manageability-requirements-00.txt
    - Better to consider NM early; can discover problems with the protocol early if this done
    - Dave Meyer: this section is not authoritative; this should not be a replacement for detailed documents
    - Avri (co-author): need some input to finish the details in the draft
    - David Perkins:this is a good idea; may not know what needs to be managed at first; may need operational experience to finalize these requirements
    - Andy B: this helps a lot to consider NM at the start; doesn't get cheaper over time; should identify what is manageable, but don't need details at this phase

    - NETCONF status update
    - WG charter covers just the protocol
    - use XML
    - network-wide protocol
    - extensible enough so vendors can provode access to all configuration data on the device
    - need PI, not screen-scraping interface
    - data model support in charter
    - need to identify principals (e.g., user names)
    - mechanism needed to distinguish config from other data
    - (missed last 2 points)
    - all NETCONF drafts in WG Last Call
    - comment: Is there an issue tracker that identifies that an operator made a suggestion that was rejected? No.
    - Is the WG done?
    - possible next steps:
    - NETCONF WG charter extended
    - close NETCONF and start new WG (i.e., NETMOD)
    - big issue is the scope of the work
    - stop netmod work and let vendors or other SDOs continue this work
    - low hanging fruit
    - USe XSD, but not universal agreement on using XSD
    - standard data types (like InetAddress)
    - leverage existing frameworks like SMIv2
    - request to read RFC 3535 (justification to do NETCONF)
    - not a big issue if there is no SMI or framework
    - Andy B: need an SMI and data types right away to have consistency
    - Dave H: Problem is the vendors not implementing enough MIBs. Why are MIBs too difficult; need building blocks to create an API that allows better alignment with CLI; need a standard CLI;
    - Juergen: look at Relax NG instead of XSD because it is more readable; no compliance; no info-modeling
    - set of guidelines on using Relax NG
    - set of data types
    - interworking with SMI
    - Steve W: this is first step; agreed at start that this work is needed but it was deferred to make progress in steps. need to continue work so we get interoperability
    - Bert: post to netmod mailing list on this topic, not ops or netconf WGs

    - MULTI6 WG status
    - most items are almost finished (in WGLC)
    - design team formed in San Diego IETF
    - approach is an "L3 shim"
    - below fragmentation, IPSEC
    - this shim is needed to provide connection survivability for multi-homing independent of the transport protocol.
    - no new DNS namespace
    - AAAA records contain same thing as today
    - applications use upper-layer ID
    - hash based address scheme to prevent redirection attacks when host has a fixed set of addresses, then hash (e.g., SHA-1) can be used for verification
    - Issues from the design team
    - handle ingress filtering
    - DT did not specify packet formats
    - David K: WG agreed to consider new work when documents are near completion (which it is now)

    - IPv6 OPS
    - slimmed down charter will be defined
    - new WG in Internet area for tunnel protocol work
    - no comments

    (MBONED chair)

    - Dave Meyer: cross area coordination between PIM, IPv6
    who owns P2P LSP problem?
    - general issue: how to do these cross-area coordination efforts

    - protocol work in OPS area?
    - should protocol work be moved in general to other areas?
    - Dave M: operation needs, but can't find a home in a protocol WG so don't have a very strict rule about this
    - Bert: NM and OPS merged together; NM has always done protocol work in NM (SNMPv3, NETCONF); This will continue; Need to be aware of other work going on and not duplicate.
    - ???: OPS WGs should not be competing with a protocol WG if such a WG exists; minor work okay in OPS if no protocol WG exists
    - Curtis: not worried about OPS area doing protocol work worried about all the other documents being produced.
    - ???: Not clear what is "Operations" work
    - Dave M: if protocol WG exists but doesn't want some new work then this should be considered carefully
    - ???: transition work falls between the gaps;
    - ???: missed some comments on details for protocol work that was done in OPS; transition evaluation, etc.
    - David K: If it makes sense, or there is a strong need it will be chartered in OPS area
    - Bert: need to consider how much agreement there is on solution approaches; little or no agreement means little chance of success
    - Curtis: missed most comments; bar is not high enough for non-protocol work in the OPS area
    - Dave M: criteria for Informational documents not clear; not that the bar is too low but there is too much variance
    - Do people share this opinion (no response)
    - Randy P: which statement are you asking about? Variance in quality is across IETF, not just OPS
    - ???: Informational documents do not get as much review comments as STD track documents
    - ???: not so clear that this variance is a big problem; maybe an IETF-wide document is needed
    - Randy P: Maybe have an "Operations Considerations" section. Maybe OPS has all this work to do because protocol WGs are not considering OPS well enough in their work
    - open mike: no comments


    IETF Bridge WG Transition to IEEE 802.1 WG
    NETCONF Status Update and Outlook
    Multi6 WG and DT status
    P2MP LSPs: MBONED, PIM, and MPLS WG Cross-functional Update