NETCONF BOF 56th IETF San Francisco, California March 17, 2003

1
NETCONF BOF56th IETFSan Francisco,
CaliforniaMarch 17, 2003

• Discussion
• xmlconf_at_ops.ietf.orgAdmin
• xmlconf-request_at_ops.ietf.org

2
NETCONF BOF Agenda

• Agenda bashing 5 minutes
• Opening Remarks 10 minutes
• NETCONF Scope presentation 15 minutes
• NETCONF Scope discussion 15 minutes
• XMLCONF I-D presentation 35 minutes
• XMLCONF I-D discussion 40 minutes
• Next Steps 30 minutes

3
Network Management Roadmap

• Goals
• Achieve standards-based network management
• Phase out proprietary screen-scraping scripts
• Manage networks, not just network devices
• 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
• 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)

4
Operator Requirements

• OPS area has been researching NM requirements for
  almost 2 years
• April, 2001 May 2002OPS-NM Road show visits
  Operators at RIPE, NANOG, LISA
• June, 2002 IAB Workshop on Network Management
• Several drafts have been written on the subject
• Operator Requirements of Infrastructure
  Management Methods
• ltdraft-ops-operator-req-mgmt-02.txtgt (expired)
• Overview of the 2002 IAB Network Management
  Workshop
• ltdraft-iab-nm-workshop-02.txtgt (-02 missed the
  I-D cutoff)
• Concepts and Requirements for XML Network
  Configuration
• ltdraft-wasserman-xmlconf-req-00.txtgt
• On Transport of Configuration Information
• ltdraft-lear-config-issues-00.txtgt

5
NETCONF Problem Statement

• 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

6
Primary use cases

• 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
• Need to provide device level support for network
  wide configuration operations
• Configuration locking
• Checkpoint and rollback
• Separate validation and commit phases

7
NETCONF Protocol Layers
Content
Protocol Operations
Remote Procedure Call
Transport
Synchronous Messages divided into 4 independent
layers
8
Content Layer

• Configuration Data
• Mixture of standard and proprietary data models
• Payload for protocol operations such as
  edit-config or get-config
• 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

9
Protocol Operations Layer

• 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

10
RPC and Transport Layers

• Select or define remote procedure call protocol
• Define RPC requirements
• Define mappings to different RPC protocols, as
  needed
• Select transport protocol(s)
• Define transport requirements
• Define security requirements
• Define mappings to different transport protocols,
  as needed

11
Why use XML?

• 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
• Standards based
• Lots of progress has been made on standards
  related to XML, such as XML Schema, XSLT, Xpath,
  SOAP
• Widespread tool support
• Lots of freely available and commercial-grade
  tools
• Used in many domains not limited to the narrow
  network management niche

12
Why standardize XMLCONF?

• Focus on operational requirements
• Appropriate layering and separation of effort
• Standardizes important configuration related
  tasks
• 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
• Its time for the IETF to act on these
  requirements