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

abierman-netconf-mar03 1

NETCONF BOF56th IETF

San Francisco, CaliforniaMarch 17, 2003

Discussion:

[email protected]:

[email protected]


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


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)


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

Several drafts have been written on the subject» Operator Requirements of Infrastructure Management Methods

– <draft-ops-operator-req-mgmt-02.txt> (expired)

» Overview of the 2002 IAB Network Management Workshop – <draft-iab-nm-workshop-02.txt> (-02 missed the I-D cutoff)

» Concepts and Requirements for XML Network Configuration– <draft-wasserman-xmlconf-req-00.txt>

» On Transport of Configuration Information– <draft-lear-config-issues-00.txt>


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


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


NETCONF Protocol Layers

Content

Protocol Operations

Remote Procedure Call

Transport

Synchronous Messages divided into 4 independent layers


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


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


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


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


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– It’s time for the IETF to act on these requirements

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

Documents

Transcript of Abierman-netconf-mar03 1 NETCONF BOF 56th IETF San Francisco, California March 17, 2003 Discussion:...