abierman-netconf-mar03 1 NETCONF BOF 56th IETF San Francisco, California March 17, 2003 Discussion: Admin:

abierman-netconf-mar03 2 NETCONF BOF Agenda l Agenda bashing : 5 minutes l Opening Remarks : 10 minutes l NETCONF Scope presentation : 15 minutes l NETCONF Scope discussion : 15 minutes l XMLCONF I-D presentation : 35 minutes l XMLCONF I-D discussion : 40 minutes l Next Steps : 30 minutes

abierman-netconf-mar03 3 Network Management Roadmap l Goals: »Achieve standards-based network management »Phase out proprietary screen-scraping scripts »Manage networks, not just network devices l First develop and deploy the management protocol (1 year) »Decoupled from the data model »Allow for data retrieval and notifications but focus on configuration tasks »Start with a lightweight protocol and proprietary data models to gain operational experience l Then develop a standard data model (2 – 5 years) »Build on existing MIB and SMI experience »Gradually replace proprietary data models with standard data models developed in protocol WGs (similar to MIB process)

abierman-netconf-mar03 4 Operator Requirements l OPS area has been researching NM requirements for almost 2 years »April, 2001 – May 2002 OPS-NM Road show visits Operators at RIPE, NANOG, LISA »June, 2002 IAB Workshop on Network Management l Several drafts have been written on the subject »Operator Requirements of Infrastructure Management Methods – (expired) »Overview of the 2002 IAB Network Management Workshop – (-02 missed the I-D cutoff) »Concepts and Requirements for XML Network Configuration – »On Transport of Configuration Information –

abierman-netconf-mar03 5 NETCONF Problem Statement l Need a standard protocol to manage network configuration; Something that: »operators want to use »vendors can implement on a wide variety of platforms »uses a human-readable encoding that is easy to generate and debug »provides useful high-level operations specialized for configuration management »accounts for different operational models in use today »provides baseline features that can be extended, based on the capabilities of the network device »integrates well with existing widely available toolsets

abierman-netconf-mar03 6 Primary use cases l Need to provide a standard programmatic interface to replace scripts which interact with proprietary CLI interfaces »CLI is intended for human use »CLI is not usually stable enough to be a useful API »CLI does not have standardized high level operations for managing device configuration l Need to provide device level support for network wide configuration operations »Configuration locking »Checkpoint and rollback »Separate validation and commit phases

abierman-netconf-mar03 7 NETCONF Protocol Layers Content Protocol Operations Remote Procedure Call Transport Synchronous Messages divided into 4 independent layers

abierman-netconf-mar03 8 Content Layer l Configuration Data »Mixture of standard and proprietary data models »Payload for protocol operations such as edit-config or get-config l Standard data model work not part of this WG »Lot of work to do, similar to SMI and MIB definition –Data definition language –Common data types –Data model specification –Naming conventions –Change control rules and versioning mechanisms –Data model compliance specification »Define a protocol first, then commit to data model work if the protocol is proven to be useful

abierman-netconf-mar03 9 Protocol Operations Layer l Focus of NETCONF protocol work »Define protocol operations for configuration management »Define framework which encompasses different operational models for editing configuration data and saving it to non-volatile memory »Define device level support for network-wide (multi- box) configuration changes »Define base functionality and extensible set of enhanced functionality based on a set of standard or proprietary device capabilities

abierman-netconf-mar03 10 RPC and Transport Layers l Select or define remote procedure call protocol »Define RPC requirements »Define mappings to different RPC protocols, as needed l Select transport protocol(s) »Define transport requirements »Define security requirements »Define mappings to different transport protocols, as needed

abierman-netconf-mar03 11 Why use XML? l Human and machine readable format »XML provides a standards-based encoding format that strikes a good balance between human readable text and machine parsable text »XML command structure can closely represent CLI command structure l Standards based »Lots of progress has been made on standards related to XML, such as XML Schema, XSLT, Xpath, SOAP l Widespread tool support »Lots of freely available and commercial-grade tools »Used in many domains; not limited to the narrow network management niche

abierman-netconf-mar03 12 Why standardize XMLCONF? l Focus on operational requirements »Appropriate layering and separation of effort »Standardizes important configuration related tasks l Low risk factors »No new technology is being introduced –Leverages BEEP, XML, RPC, SYSLOG –Protocol operations are well understood –Operational experience with existing proprietary solutions such as JunoScript has been positive –Interest in standards for configuration management is high »The IETF has already spent almost 2 years collecting Operator requirements –It’s time for the IETF to act on these requirements