Automating Network and Service Configuration Using NETCONF ...
Abierman-netconf-mar03 1 NETCONF BOF 56th IETF San Francisco, California March 17, 2003 Discussion:...
-
Upload
edward-paul -
Category
Documents
-
view
212 -
download
0
Transcript of 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:
abierman-netconf-mar03 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
abierman-netconf-mar03 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)
abierman-netconf-mar03 4
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>
abierman-netconf-mar03 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
abierman-netconf-mar03 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
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 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
abierman-netconf-mar03 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
abierman-netconf-mar03 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
abierman-netconf-mar03 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
abierman-netconf-mar03 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– It’s time for the IETF to act on these requirements