RE: Goals for netconf - moving towards the charter description

["Faye Ly" <faye@pedestalnetworks.com>]

Andy,

The commands are very generic and are not technology specific.  They are
very common to support all sorts of network services unless you can
think of something otherwise.  The reality is that the protocol designer
probably already has certain data model in his/her mind coming up with
the protocols.  How else can one justify how does the protocol meet the
needs.  We are not designing any protocol to configure the light bulb
:)-  Might as well be specific and these are certainly not an arbitrary
set of configuration data.  They are again very common in router, access
device as well as switches configuration.  

As for enable/disable, you are right they are not some sort of switch to
turn on or off certain command.  I picked them out of lack of better
term to use.  Enable a user data path, for example, usually involves
configuring the following:

1. User data determination (is it a physical port, a data based on
certain destination IP, IP+port, or certain data tags, and so on ...)
2. Route (src, dest, type and so on ...)
3. Qos (type, profile, bandwidth and so on ...)
4. Access control 
5. security configuration 

You can see that this covers a lot of user data configuration including,
for example, IP static route or cable modem user data port.  The
advantage of being specific is to make sure protocol design meets a
certain needs but not be too ambitious and therefore doomed for failure.
Actually I was very much hoping someone will challenge the items listed
and narrow the list of needs to a smaller subset.

Best,

-faye 



-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com] 
Sent: Saturday, March 22, 2003 3:05 PM
To: Faye Ly
Cc: xmlconf@ops.ietf.org
Subject: Re: Goals for netconf - moving towards the charter description

At 02:43 PM 3/22/2003 -0800, Faye Ly wrote:
>Andy,
>
>Here are some suggestions to the slides titled "Netconf BOF 56th IETF"
>in particular to the 'Goals' bullet item on slide 3.  This is also
>proposing a set of charter description for 'netconf' WG. 

I think there is no need to limit the scope of configuration management
to the 6 specific types of configuration data listed below.  This WG
should not develop configuration commands for any specific technology 
such as logical interfaces or port diagnostics.  

It is important that the protocol be capable of manipulating 
configuration for any network service, not some arbitrary subset.
I don't believe the transaction requirements will differ
significantly based on the content of the data model.  Your list
seems to focus on enable and disable commands, as if on/off
switches would be sufficient for configuration.  Maybe this
isn't what you meant.

>You currently have:
>
>>Goals:
>>Achieve standards-based network management
>>Phase out proprietary screen-scraping scripts
>>Manage networks, not just network devices

I think these are the proper goals for the NM Roadmap slide.
That doesn't mean that this WG will achieve all of these goals
with its initial charter. It just means we can start moving in
the right direction.


>These goals have proven to be controversial and a bit too ambitious for
>this working group to tackle.  Suggest using the following:

You have mostly restated the original charter text. I'm not sure
it makes the goals more understandable, though.

>=======================================================================
=
>===
>
>Develop a standards-based network management protocol specifically
>addressing the need of configuration management (CM) where CM is
>described as:
>
>Enable file based and transactional based configuration and
>configuration information retrieval to one or more network devices to
>meet the following needs:
>
>1. Enable or disable user traffic on one or a set of heterogeneous
>network devices where this user traffic traverses.  Note that
management
>channel is categorized as a special type of user traffic which has the
>same set of requirement with the user's traffic.
>2. Enable or disable network devices and physical/logical interfaces
for
>inventory management.
>3. Enable or disable all levels of diagnostic and fault triggering
>function to ensure network device, user data path as well as physical
>port and/or path for fault management.
>4. Enable or disable operator and operator access (Role based
>configuration).
>5. Enable or disable data integrity and secrecy for all user traffic as
>well as management traffic on a per user traffic, per device or per
>network basis.
>6. enable/disable file management for upgrade, save, backup, restore
and
>execute for full or partial configuration set on a single or multiple
>network devices.
>
>This protocol is also required to address the need of 'transaction'
>based configuration model for one or a set of heterogeneous network
>devices where the typical property of the 'transaction' should be
>supported.  (Such as but not limited to configure, commit, and
>rollback).  
>
>This protocol is designed to solve the lack of consistency for
>configuring network device(s) and network device to network device
>configuration discrepancy problem.  Specifically it is designed to
>address the pain of using CLI based scripting tools to configure one
>network device at a time and hence no transactional support for
applying
>configuration to all network devices that are involved.
>
>This protocol is not designed to attach to a certain data model but
>focused on addressing all the configuration management needs depicted
>above. 
>
>=======================================================================
=
>=== 
>
>-faye
>  

Andy




--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>