Subject: snmpconf a new issue: off-the-box operations

From: David Partain <[email-masked]>
Date: Wed, 04 Apr 2001 13:53:14 +0200

Greetings,

I've added a new issue to read the documents to find holes in
how off-the-box operations are done.  It's number 26.  Issue:
The policy engine should operate both on local SNMP objects
and on objects in other SNMP engines. The PM draft needs to be
read to fill any holes in the description of how this is done.

With kind regards,

--
David Partain                  [email-masked]
Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
Research and Innovation        Fax:    +46 13 28 75 67
P.O. Box 1248                  http://linlab.ericsson.se/~epkpart
SE-581 12  Linköping, Sweden

---

From: Jon Saperia <[email-masked]>
Date: Wed, 04 Apr 2001 07:57:50 -0400

I want us to evaluate very carefully the benefit/cost ratio of this. I
am not convinced it will be worth it. 

> read to fill any holes in the description of how this is done.

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Pablo Halpern <[email-masked]>
Date: Wed, 04 Apr 2001 14:42:11 -0400

>am not convinced it will be worth it.

Do you mean that you're not sure it is worth it to support off-the-box 
operations or that it is not worth it to do the work to detail it?

> > SE-581 12  Linköping, Sweden

- Pablo
----------------------------------------------------------------------
Pablo Halpern                      http://www.halpernwightsoftware.com
[email-masked]

---

From: "Wayne F. Tackabury" <[email-masked]>
Date: Wed, 04 Apr 2001 15:36:18 -0400

At 02:42 PM 4/4/2001 -0400, Pablo Halpern wrote:
Do you mean that you're not sure it is worth it to support off-the-box 
operations or that it is not worth it to do the work to detail it?

Personally, I've been somewhat mystified on the application of this ever 
since I noted it in the somewhat incomplete mention in the PM draft.

Maybe "mystified" is too strong a word.  Can Steve tell me what he was 
thinking about here in terms of application and how objects might get 
exposed as to their local agents?  I've been considering the notion of a 
"PolicyScript proxy" for some time now, but that would be a private matter 
of local proxy configuration, not exposed through the PM MIB.

Don't misread me--there might be and likely is some essential application 
I'm missing here, I just want to understand what it is and how it would 
play out administratively.

Thanks!

Wayne

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 05 Apr 2001 00:10:40 -0700

In my previous email I described the non-local feature in which the
PM agent abstracts out instance/addressing information from
scripts, even when the PM agent is acting as a proxy and SNMP
operations are performed remotely.

Key to this is that it in policy scripts it is very easy to address
"this element", and easy to address related elements.

"This element"
   getvar("frCircuitCommittedBurst.$0.$1")
   or:
   getvar("acmeRouterCircuitTable.$0.$1")
   // this works when the other MIB is indexed the same

Related Element
   getvar("ifSpeed.$0");  // the parent port of the interface

As elements become less related, they become more difficult to address
because less information is defaulted and more of it needs to be
explicitely specified. The policy engine is doing less work for you
for elements that are less related. Luckily the most frequent
operations are on "this element", next most frequent is related
elements, and unrelated elements are even less frequent.

Unrelated elements
   getvar("ifSpeed.7"); // needed to specify #7
   // stuff like searchcolumn can help:
   searchcolumn("ifType", oid, "6", 0); // find an ethernet

Unrelated elements are on a continuum because we can get even more
unrelated if we address other contexts on the same system or other
systems entirely. In the former we need to begin specifying the
context explicitely and in the latter we need to specify
context, address and security info.

By this way of looking at it, the proxy agent non-local operation
couldn't be more different than this type of non-local operation.
While the former is about less and less explicit addressing, this is
about providing more and more explicit addressing so that a script
can address anything.

Why is it valuable to do an snmpsend to another system in a policy
environment? Let me pose an example.

  You have a medium-sized field office that connects over a big pipe
  (10MBit) to headquarters, with a slow-speed backup link
  (256K). There are a number of routers and switches at this site. The
  PM MIB is used to deploy a consistent QOS scheme of marking in
  switches and limiting/shaping on the routers in order ensure
  proper usage of the link. However, when the link goes down, all of
  this needs to change and a new QOS scheme needs to be deployed
  everywhere (HTTP can't enjoy it's 512K allocation anymore). How will
  the switches/routers know the uplink has failed? It would seem that
  they need to test the status of the link with a remote snmp query. I
  see the policies structured as:
        Filter1: uplinkUp() && (...)
        Action1: deployRegularQOS()

        Filter2: !uplinkUp() && (...)
        Action2: deployDisasteQOS()

I believe such situations will be infrequent but when they arise they
will require a solution. The solution isn't very expensive. Since we
have to fully specify local operations including context, the added
cost of non-local is just adding the address and the security
information as optional arguments to the APIs of some of the accessor
functions.

Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 05 Apr 2001 00:07:12 -0700

Wayne,

The best way of showing this is to describe it locally and then
extrapolate in a couple of steps to non-local.

The way the model works is I tell the PM agent that I'm interested in
running policy on certain element types and I also install the
policies that should run.

Let's say an element type is frame circuit and there are 3 circuits on
the system { port 2 DLCI 67}, { port 7 DLCI 134 } and
{ port 7 DLCI 135 }. We discover the following elements:

internal element database
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135

The system will iterate all circuit policies on each of these
elements.

If I want my filter or action to access the committed burst rate on
"this element", I simply write:
   getvar("frCircuitCommittedBurst.$0.$1")

The instance information is not required. We like to say that this
provides instance-independence.

Another example:
   // The following will shut off any unprovisioned access port for
   // security policy.
   Filter: !roleMatch("gold") && !roleMatch("bronze")
           && !roleMatch("trunk")
   Action: setvar("ifAdminStatus.$0", 2, Integer)

How about the following per-circuit filter that selects all circuits
who's committedBurst is greater than their port speed:
   getvar("frCircuitCommittedBurst.$0.$1") > getvar("ifSpeed.$0")

Notice how no instance information is needed even when we're accessing
a different but related element (the parent port).

If we added the element type rptrPortEntry, now we'd be executing
policy on repeater ports, for example:
   if (getvar("rptrPortAutoPartitionState.$0.$1") == 2) //partitioned
     ...

RFC1516 requires multiple repeaters to be placed in different
contexts. No problem. This multi-context agent will add the following
information to the internal element database:

internal element database
     element                    context
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135
4    rptrPortGroupIndex.1.1     "repeater1"
5    rptrPortGroupIndex.1.1     "repeater2"
6    rptrPortGroupIndex.1.2     "repeater1"
7    rptrPortGroupIndex.1.2     "repeater2"

The same policyScript code can now be executed and run correctly
without any knowledge that sometimes it is running in a different
context. Whenever "this element" is on repeater2, the agent
automatically directs the getvar() to inspect repeater2.

What we called instance-independence above now starts to look like
complete address-independence. (I think the guys who coined the term
instance-independence would claim they had this in mind all the
time).

Taking it further, if I wanted to do a proxy-agent implementation to
policy-manage some closed systems that don't implement the PM MIB, the
proxy-agent extends it's discovery to discover off-box elements (a
simple table walk can accomplish this). Now I extend the internal
element database a bit more:

internal element database
     element                    context         address     auth
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135
4    frCircuitIfIndex.1.67      ""              a.b.c.d     ***
5    frCircuitIfIndex.1.69      ""              a.b.c.d     ***
6    rptrPortGroupIndex.1.1     "repeater1"
7    rptrPortGroupIndex.1.1     "repeater2"
8    rptrPortGroupIndex.1.2     "repeater1"
9    rptrPortGroupIndex.1.2     "repeater2"

and now whenever "this element" is entry #4 or #5 above, getvar()
builds an actual SNMP PDU and sends it to a.b.c.d instead of doing a
local get. The script doesn't need to have any knowledge of the
location of the element it is acting on.
    
It seems to me we're onto something big here. We're writing policies
and the code is much simpler than we're used to because all
instance/addressing has been abstracted out. It's simplified to the
point where we don't know or care what element we are operating on or
where it is.  And the policies that we write can run on local agents
or proxy agents without re-write (if we add a proxy-agent later, just
install our existing policy database on it).

There *are* some things we need to do to some of the support tables in
the PM MIB to facilitate this and I'll outline them in another note.

Steve

---

From: Jon Saperia <[email-masked]>
Date: Thu, 05 Apr 2001 07:45:35 -0400

> operations or that it is not worth it to do the work to detail it?

Pablo, yes to both. Since work has been done in some areas, I will be
the last one to ask to revisit that. I wanted to be sure we did not
over-complicate the capabilities table because I thought it would not
produce any benefit and is inconsistent with how the table is now
defined. That is one entry for an entire entity, not at an instance
level. Contexts are another way of sub-dividing.

I think we are ok on this now.
/jon

Thanks,
/jon
--

---

From: Jon Saperia <[email-masked]>
Date: Thu, 05 Apr 2001 07:49:10 -0400

Wayne, I replied to this in responding to Pablo's original message.
Remember my concern was mostly in regard to the capabilties table which
is clearly out of scope for this 'out-of-box' function.

With regard to other areas of the system that do 'proxy' I like you feel
this should be a specialized local function. The cost of including such
facilities in the standard in my view makes it more complicated than the
benefit it produces.
/jon

Thanks,
/jon
--

---

From: Jon Saperia <[email-masked]>
Date: Thu, 05 Apr 2001 08:28:52 -0400

The problem with proxy has been the configuration of the adminstrative
infrastructure to support it. I believe the solution is more expensive
than we think. If it were not it would be more in use than I expect it
is today. I do not object to the function as long as it neither slows or
work or makes the solution much more complex.
/jon

Thanks,
/jon
--