RE: draft-ops-mumble-conf_management-02.txt

[Andrew Smith <andrew@extremenetworks.com>]

Some comments marked as [andrew] below. Might be valuable to start an
"issues for discussion" section in the document.

Andrew


> -----Original Message-----
> From: Luis A. Sanchez [mailto:lsanchez@bbn.com]
> Sent: Wednesday, October 13, 1999 3:48 PM
> To: mumble@ops.ietf.org
> Subject: draft-ops-mumble-conf_management-02.txt
...
> 1.1 Motivation, Scope and Goals of this document
> 
>     Over the past months, a number of IETF working groups have
>     introduced new technologies which offer integrated and

[andrew] IETF WGs do protocols, not technologies. How about: 
"Over the past years, IETF working groups in the areas of Quality-of-Service
and Security have developed new protocols which provide for, amongst other
things, Integrated Services, Differentiated Services and IP Security."

>     differentiated services.  To support these new technologies,
>     working group members found that they had new requirements for
>     configuration of these technologies. One of these new requirements
>     was for the provisioning (configuration) of behavior at the
>     network level.
> 
>     An example of this type of configuration would be instructing all
>     routers in a network to provide 'gold' service to a particular set
>     of customers. Depending on the specific network equipment and
>     definition of 'gold' service, this configuration request might

[andrew] insert "high-level" ----------^^^

>     translate to different configuration parameters on different
>     vendors equipment and many individual configuration commands at
>     the router. This higher level of configuration management has come
>     to commonly be known as policy based management.
> 
>     Working groups associated with these new technologies believed
>     that the existing SNMP based management framework, while adequate
>     for fault, configuration management at the individual instance
>     (e.g., interface) level, performance and other management
>     functions commonly associated with it, was not able to meet these
>     new needs.  As a result they began working on new solutions and
>     approaches.
> 
>     COPS [COPS] for RSVP [RSVP] provides routers with the opportunity
>     to ask their Policy Server for an admit/reject decision for a
>     particular RSVP session. This model allows routers to outsource
>     their resource allocation decisions to some other entity. However,
>     this model does not work with DiffServ [DSARCH] where there is no
>     signalling protocol. Therefore, the policies that affect resource
>     allocation decisions must be provisioned to the routers. It became
>     evident that there was a need for cordinating both RSVP-based and
>     DiffServ-based policies to provide end2end QoS. Working groups
>     began to extend and leverage approaches such as COPS for RSVP to
>     support Diffserv policies. This gave birth to COPS-PR [COPS-PR].

[andrew] Not sure why there is a need to couple in COPS-RSVP here, other
than as a historical driver for the development of the base COPS protocol.
COPS-RSVP has very little to do with configuration management. So I don't
see that COPS-PR grew out of a realisation that "it became evident that
there was a need for coordinating both RSVP-based and DiffServ-based
policies to provide end2end QoS". COPS-PR has been proposed for the config
mgmt problem, not to help integrate COPS-RSVP. Instead of the last sentence,
how about:
"The RAP WG has started to leverage the base COPS protocol in order to
support Diffserv policies: this gave birth to COPS-PR [COPS-PR]."

...
> 
> 1.4 Definition of Technical Terms
> 
>     Device-Local Configuration
> 
>     Configuration data that is specific to a particular network
>     device. This is the finest level of granularity for configuring
>     network devices.

[andrew] I think that you need more granularity than just "per-device": you
need "per-interface" for sure and possibly also
"per-traffic-class-per-interface". Other granularities might also include
logical interfaces (e.g. FR circuits) or VLANs.

>     Network-Wide Configuration
> 
>     Configuration data that is not specific to any particular network
>     device and from which two or more device-local configurations can

[andrew] "one or more" not "two or more".

>     be derived. Network-wide configuration provides a level of
>     abstraction above device-local configurations.
> 
>     Configuration Data Translator
> 
>     A function that transforms Configuration Management Data
>     (high-level policies) or Network-wide configuration data
>     (middle-level policies) into device local configurations
>     (low-level policies) based on the generic capabilities of network
>     devices.  This function can be performed either by devices
>     themselves or by some intermediate entity.

[andrew] Need a definition of what you mean by "Configuration Management
Data".

...
>     2. Statement of the Problem
...
>     Figure 1. Current model for configuring network devices.
> 
>     Historically, network operators and engineers used protocols and
>     mechanisms such as SNMP and CLI applications to provision or
>     configure network devices. In their current versions, these
>     mechanisms have proven to be difficult to use because of their
>     low-level of granularity and their device-specific nature. This
>     problem is worse when provisioning multiple network devices
>     requiring large amounts of configuration data.
> 
>     It is evident that network administrators and existing
>     configuration management software can not keep up with the growth
>     in complexity of networks and that an efficient, integrated
>     configuration management solution is needed. Several IETF Working
>     Groups

[andrew] Be specific: Policy, RAP, DiffServ?

> working on this problem converged into adding a layer of
>     abstraction to the traditional configuration management process
>     described in figure 1. Figure 2 depicts this process. As in the
>     previous figure, first the network operator, engineer or entity
>     responsible for the network creates a model of the network and its
>     expected behavior. This is formalized and recorded in the form of
>     high-level policies.
> 
...
>     The following requirements for configuration management will be
>     used in evaluating the cost effectiveness of the extension to SNMP
>     and/or the use of COPS-PR with modifications for configuration
>     management. An integrated configuration management solution MUST:

[andrew] You probably want to phrase this as protocol-neutral in case the
final solution is not called COPS or SNMP. How about:

"The following requirements will be used in evaluating the effectiveness of
protocol solutions for configuration management." 

>     - provide means by which the behavior of the network can
>       be specified at a level of abstraction (network-wide
>       configuration) higher than a set of configuration
>       information specific to individual devices,
> 
>     - be capable of translating network-wide configurations into
>       device-local configuration. The identification of the relevant
>       subset of the network-wide policies to be down-loaded is
>       according to the capabilities of each device,

[andrew] It may also be according to dynamic local network conditions: e.g.
topology, current network loadings, phase of the moon etc.

...

>     - provide expiration time capabilities to configuration data. It
>       is required that some configuration data items be set to expire,
>       and other items be set to never expire,

[andrew] Are you implying a need for a timer per object here?

>     - provide error detection (including data-specific errors) and
>       failure recovery mechanisms for the provisioning of
>       configuration data,
> 
>     - eliminate the potential for mis-configuration occurring through
>       shared write access to the device's configuration data,
> 
>     - provide facilities (with host and user-based authentication
>       granularity) to help in tracing back configuration changes,

[andrew] Are we sure we want the "agent" to have to be involved in
roll-backs?

>     - allow for the configuration of redundant components (both as
>       network elements and configuration application platforms).  In
>       addition, the system should support the concept of individuals
>       (humans) in different roles with different access privileges,
> 
>     - be flexible and extensible to accommodate for future
>       needs. Configuration management data models are not fixed for
>       all time and are subject to evolution like any other management
>       data model. It is therefore necessary to anticipate that changes
>       will be needed, but it is not possible to anticipate what those
>       changes might be.  Such changes could be to the configuration
>       data model, supporting message types, data types, etc., and to
>       provide mechanisms that can deal with these changes effectively
>       without causing inter-operability problems or having to
>       replace/update large amounts of fielded networking devices,
> 
>     - leverage of the existing SNMP management infrastructure where
>       possible. The system MUST leverage knowledge of and experience
>       with MIBs and SMI.
> 

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
****************************************************************