Subject: RE: Using entPhysicalIndex

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 16 Aug 2001 10:36:59 -0500

> From: Juergen Schoenwaelder [mailto:[email-masked]] 

>      If the source of the alarm is a logical interface, then the value
>      of the RowPointer must be the OID of the corresponding ifIndex
>      object. If the source of the alarm is a physical entity, then the
>      value of the RowPointer must be the OID of the corresponding
>      entPhysicalDescr object.
> 
> There might be other common things - perhaps we need also pointers 
> into the HOST-RESOURCES-MIB for processes and such things.

	...and pointers into the application MIB, and so on, and so on...

	AAAAARRRRGGGGHHHHHH!!!!!!!

	How will anyone be able to manage all this?  We are talking about
inserting a moving target for which forward comptaibility is impossible,
since implementors will constantly be wanting to add their favorite MIBs!

	...

	(Catches breath, waits for BP to drop)

	...

	Okay, let's take another look at all this.  There currently is no
standard IETF framework for physical location, nor is any work being done to
produce one.  The Entity MIB will not work for this purpose, since it
neither defines a deterministic algorithm for deriving its indexes nor
requires persistence across reboots for them.  In any case, tracking
entPhysIndex is pointless, since it will give us no information that we
don't need to track already.

	In order to determine the source agent for an alarm, we need to
track four pieces of information: the TDomain/TAddress pair and the
ContextEngineID/ContextName pair.  From these we can uniquely determine the
logical entity that sourced the alarm.  Determination of the physical entity
must be implementation dependent due to the lack of proper standard
framework; in any case, the information necessary to determine the hardware
must be contained within the alarm itself.  Due to the nonpersistent nature
of many key variables (e.g. ifIndex), I strongly recommend that we also
track engineBoots and engineTime as well, so that an NMS can determine if it
is capable of identifying the source using current information.

/|/|ike

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Aug 2001 18:07:21 +0200

>>>>> Ayers, Mike writes:

Mike> Okay, let's take another look at all this.  There currently is
Mike> no standard IETF framework for physical location, nor is any
Mike> work being done to produce one.  The Entity MIB will not work
Mike> for this purpose, since it neither defines a deterministic
Mike> algorithm for deriving its indexes nor requires persistence
Mike> across reboots for them.  

I do not understand why the Entity MIB should define an algorithm
for deriving its indexes.

Mike> In any case, tracking entPhysIndex is pointless, since it will
Mike> give us no information that we don't need to track already.

Please take breath and explain. I certainly would love to know which
port/module/... in my chassis caused an alarm.

Mike> In order to determine the source agent for an alarm, we need to
Mike> track four pieces of information: the TDomain/TAddress pair and
Mike> the ContextEngineID/ContextName pair.

I do not think this was the subject of the debate - but I may be wrong.

Mike> From these we can uniquely determine the logical entity that
Mike> sourced the alarm.  Determination of the physical entity must be
Mike> implementation dependent due to the lack of proper standard
Mike> framework; in any case, the information necessary to determine
Mike> the hardware must be contained within the alarm itself.  Due to
Mike> the nonpersistent nature of many key variables (e.g. ifIndex), I
Mike> strongly recommend that we also track engineBoots and engineTime
Mike> as well, so that an NMS can determine if it is capable of
Mike> identifying the source using current information.

[All identifiers we have only have a certain amount of stability.
 Having TDomain/TAddress does not help if you change the IP address
 after the alarm occured...]

/js