[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Policy configuration


> I have to compare ( for my studies ) different solutions for policy
> management and I have two questions for your workgroup:
> 1/  One of the scope of your group is to work on how to do policy
> configuration and yet you just develop a MIB for policy configuration:
> what about all the technical issues about SNMP ( especially those
> noticed by people working on COPS)?

Our working group expressly is _not_ chartered to work on
questions regarding changes to the protocol, SMI, and so on.
Instead, we are working on creating infrastructure necessary
for doing configuration management in a "policy" way

Now, at the risk of opening a kettle of worms, I'll try to
address your questions briefly.  Note, though, that I am NOT
interested in a COPS versus SNMP debate.  That is certainly not
what we need to be concentrating our efforts on at the moment.

> For example:
> * should SNMP be on TCP?

This is a recurring theme in the SNMP world.  You'll find that
many of us (myself included) think that SNMP/TCP is generally
a bad idea.  As such, we don't see this as a bug but rather a
feature.  On the other hand, the issue seems to be one of state
synchronization, which we believe that you can do just fine
with SNMP without moving to a connection-oriented transport.
Folks in the RAP working group see this a different way and
reached different engineering decisions.

> * bulk transfer with SNMP?

Firstly, get-bulk helps some.  Secondly, I don't believe that you
_need_ bulk transfer to do what we're trying to do.  The whole
exercise results in less data being transfered between the
managers and the agents.

> * how to communicate from a PEP to a PDP (traps unreliable and not
> adapted)?

SNMP traps are not the only kind of notification:  we also have
informs.  Informs are certainly "reliable" and acknowledged.

> Or do you think that SNMP should be used, just as it is right now, for
> policy configuration?

It certainly can be.  That is exactly what we are doing.

> 2/ Why is it that snmpconf WG has been created after rap WG?

There are a significant number of people who believe that SNMP
should be used for configuration management.  As such, rather
than create a new protocol with a new information model, SNMPCONF
was chartered to work on how SNMP could be used to solve this

> I mean that
> one of the major drawacks of COPS was that it is a new protocol so it is
> quite expensive  to implement it and now that it seems that it has been
> accepted by the companies you start working on another method for policy
> configuration/management. Maybe there is something that I have missed?

I'm not privy to the level of deployment of COPS in networking
infrastructure today, so I won't address that.  I expect there
are other readers of this mail who can address that.

The fact is that there are many people who _want_ to use SNMP
rather than something else.  This working group is chartered
to enable that.  In the end, what the market decides upon is
an open question.  The IETF is simply trying to address the
engineering issues appropriately in two separate working groups.

With kind regards,

David Partain                  David.Partain@ericsson.com
Ericsson Radio Systems AB      Tel: +46 13 28 41 44
Research and Innovation        Fax: +46 13 28 75 67
P.O. Box 1248
SE-581 12  Linköping, Sweden