Subject: RE: Using entPhysicalIndex

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Aug 2001 20:22:35 -0400

hi

Here are some random thoughts and ramblings on the current thread:

Fault against component, as appose to just system, is very important.

Whether or not things like ifIndex and entPhysical index are algorithmically
determined or random numbers should be transparent to managers.  If the
manager becomes dependent on your algorithm, then you can't change it.
It's often necessary to change the algorithm to support unforeseen new
features.
We generally don't assume consistent ifIndices across reboots, and since we
can correlate logical and physical interfaces, we don't need to.
These sort of smarts require either the entity MIB or some propriety
equivalent.

In general, I think we need a finite way to determine "stuff" on a system.
This
was my original point which started all this - the resource identification
system
in the condition MIB and the ARC mib is not consistent.  In a perfect word,
we would
have a maximum of half a dozen things which all identifiable things within
the system
could be identified with one of.  There would also be appropriate mapping
tables
between all of these.

For example

1) Logical - ifIndex
2) Physical - entPhysicalIndex
3) Applications - sysApplInstallPkgIndex
4)-6) etc

If there are things which can't be identified with one of these, I'd like to
see us either
  1) extend 1-3 to support items
  2) identify/define 4-6

This also allows us the potential to identify a pair of objects which could
be used
to uniquely identify resources within a system
  resourceType INTEGER { ifIndex (1), entPhysicalIndex (2),
sysApplInstallPkgIndex (3) ... }
  resourceType Integer32

In general, resource identification is a trade-off between flexibility and
consistency/predictability.
If it's not flexible enough, it obviously can't be used in all cases.  If
it's not consistent/predictable,
then manager/operator use is either expensive or impossible.

Good
-----
1) Enumerated Integers
  - efficient
  - consistent
  - predictable - identified in one source
  - extensible via IANA
  - cheap to support
  - does not support vendor extensions, but the value of "other" and an
additional
    proprietary object can go a long way.

Not as Good
------------
1) Strings
  - infinitely extensible - including vendor
  - inefficient - potentially long 
  - extremely inconsistent 
  - extremely unpredictable
  - expensive for manager to support on multiple systems due to
inconsistency
2) OIDs/RowPointers
  - extensible - including vendor
  - inefficient - potentially long
  - consistent
  - predictable, but from potentially infinite sources
  - medium expense for managers to support - need to track down OID
definitions

It would be nice if we could do a best current practice on this or
something.  
Of course that would mean we would all have to all agree ;-)

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 19 Aug 2001 20:40:03 -0400

hi

Oops.  Slight correction - I'll blame the jet lag.

Sharon> Good
Sharon> -----
Sharon> 1) Enumerated Integers
Sharon>   - efficient
Sharon>  - consistent
Sharon>  - predictable - identified in one source
Sharon>  - extensible via IANA
Sharon>  - cheap to support
Sharon>  - does not support vendor extensions, but the value of "other" and
an additional
Sharon>    proprietary object can go a long way.

I was confusing type identification with resource identification here.
Of course, plain old integers are what you want here.  The plain old
integers are likely going to require supporting objects, which I'd like
to be enumerated integers.  

What ifindex/ifType does so well is decouple to identifier from additional
information.  It makes the identifier quite flexible and usable in other
MIBs.
Hopefully I've decoupled them in this email now.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 21 Aug 2001 12:27:12 -0400

hi

[Anni] If we consider that an alarm is an indication
of a abnormal condition of a managed resource, then
I don't think there are big difference between alarm
and conditions.  Following this definition,
the active alarm table (Sharon & Dan's) would be an
a subet (some condition does not generate alarm) and
an abstraction (in their application, detail
information are listed in another table).

The architecture shown in the Condition MIB is a 
starting points, of course it needs more works, :-).
Mike and Disman members, I would like to get 
your views.
[/Anni]

Based on discussions in Minneapolis, I had expected the 
condition MIB to differentiate itself a bit more than it 
has so far.  As I mentioned in London, I was expecting to 
see condition profiles of some sort and perhaps a tight coupling
with ARC.

I think, as currently defined, conditions could be supported using
the Alarm MIB as follows, especially now that we are looking
at supporting an alarmClearedTable:

1) Transitory conditions are treated as alarms of infinitely small
   duration

2) Non-interesting conditions are issued with a low alarm state
   value or a severity of warning.

Am I missing something? Is there more to it than this from a MIB
perspective? We had agreed we were solving two different problems,
but so far the solutions look rather similar.

Sharon

---

From: "Ayers, Mike" <[email-masked]>
Date: Tue, 21 Aug 2001 13:05:39 -0500

> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Sunday, August 19, 2001 05:23 PM

> Here are some random thoughts and ramblings on the current thread:

<SNIP/>

	What you propose is that we create a framework for identifying
physical source.  There has already been an attempt to do this, the chassis
MIB WG, which was, as I understand it, one of the IETF's more spectacular
flameouts.  I think an attempt to perform such work is WAY outside the scope
of this WG.  Rather, we should simply ensure that whatever framework we
provide is flexible enough to incorporate whatever standard the IETF may yet
produce.

/|/|ike

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 21 Aug 2001 14:40:01 -0400

hi

<Mike>
</Mike>

No, not quite.  

First off, I was talking about both physical and logical
things.  Pretty much anything that could be discussed. 
From a fault perspective, this means anything that can experience
an alarm.

Second, I am suggesting that we try and use what we have, and NOT
define new stuff.  I think ifIndex, entPhysicalIndex and that application
index cover a large percentage of the cases. Anyone know of any big holes 
that leaves?

I did suggest that if there were things not covered by the three existing
things named, that we try and address that.  I agree that this is well
beyond the scope of this working group.  I'm just trying to avoid a
situation
where the existing stuff only covers 95% of the situations so we do it our
own "super flexible" way instead of trying to work within or fix the
existing 
framework. This results in a more expensive solution for the
manager/operator.

Sharon