Subject: Re: open issues in agentX MIB

From: "Smitha Gudur" <[email-masked]>
Date: Fri, 31 Jul 1998 15:29:41 PDT

>From [email-masked] Fri Jul 31 15:03:58 1998
>Received: from mithatch-ultra.cisco.com (mithatch-ultra.cisco.com 
[171.69.50.33]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id 
PAA29758; Fri, 31 Jul 1998 15:02:54 -0700 (PDT)
>Received: from cisco.com (localhost [127.0.0.1]) by 
mithatch-ultra.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) 
with ESMTP id PAA12637; Fri, 31 Jul 1998 15:02:54 -0700 (PDT)
>Sender: [email-masked]
>Message-ID: <[email-masked]>
>Date: Fri, 31 Jul 1998 15:02:53 -0700
>From: Mike Thatcher <[email-masked]>
>X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u)
>MIME-Version: 1.0
>To: Smitha Gudur <[email-masked]>
>Subject: Re: open issues in agentX MIB
>References: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Smitha Gudur wrote:
>
>> Hi, Mike,
>>
>> There is relationship between sessionID defined in RFC2257 and
>> the agentxSessionIndex.
>>
>> Current description for agentxSessionIndex includes:
>>
>> "Index values assigned for a given registration are constant for the
>> lifetime of this table."
>>
>> is inappropriate and needs to be removed.
>>
>> The other part of the description is consistent with the RFC.
>>
>> "A unique index for the subagent session. Note that if a
>> subagent's session with the master agent is closed for
>> any reason its index should not be re-used, therefore,
>>
>
>However the RFC does not restrict the reuse of sessionID.
I agree, it does not restrict the usage but says that it should
be globally unique over all its sessions if master agent supports
multiple transports. 

The description has to be changed to make it unique across all the 
sessions that the master agent supports instead of saying it cannot be 
reused. 

smitha

>MikeT

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: "Smitha Gudur" <[email-masked]>
Date: Mon, 03 Aug 1998 10:28:49 PDT

>From [email-masked] Sun Aug  2 02:19:22 1998
>Received: (from uucp@localhost)
>	by almond.bmc.com (8.8.8/8.8.8) id EAA02950
>	for <[email-masked]>; Sun, 2 Aug 1998 04:19:21 -0500 (CDT)
>Received: from firewall.bmc.com(192.245.162.250)
>	by almond.bmc.com via smap (V2.0)
>	id xma002666; Sun, 2 Aug 98 04:18:40 -0500
>Received: (from uucp@localhost)
>	by dresden.bmc.com (8.8.5/8.8.6) id EAA18517
>	for <[email-masked]>; Sun, 2 Aug 1998 04:18:02 -0500 (CDT)
>Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via 
smap (3.2)
>	id xma018019; Sun, 2 Aug 98 04:17:22 -0500
>Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65])
>	by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA07541;
>	Sun, 2 Aug 1998 04:17:40 -0500 (CDT)
>Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100])
>	by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA04388
>	for <[email-masked]>; Sun, 2 Aug 1998 01:02:27 -0700 (PDT)
>Received: (from uucp@localhost)
>	by cashew.bmc.com (8.8.8/8.8.8) id DAA08809
>	for <[email-masked]>; Sun, 2 Aug 1998 03:02:24 -0500 (CDT)
>Received: from agni.wipinfo.soft.net(164.164.6.20)
>	by cashew.bmc.com via smap (V2.0)
>	id xma008791; Sun, 2 Aug 98 03:02:08 -0500
>Received: from scan.wipinfo.soft.net by wipinfo.soft.net 
(SMI-8.6/SMI-SVR4)
>	id NAA18037; Sun, 2 Aug 1998 13:27:25 -0500
>Received: from 192.9.100.151 by scan.wipinfo.soft.net (InterScan E-Mail 
VirusWall NT)
>Received: from opel ([192.9.52.22])
>	by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id NAA26354;
>	Sun, 2 Aug 1998 13:34:01 +0530
>From: "Ashish Hanwadikar" <[email-masked]>
>To: "Bob Natale" <[email-masked]>
>Cc: "Agentx" <[email-masked]>
>Subject: RE: open issues in agentX MIB
>Date: Sun, 2 Aug 1998 13:32:36 +0530
>Message-ID: <[email-masked]>
>MIME-Version: 1.0
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
>Importance: Normal
>In-Reply-To: <[email-masked]>
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
>Content-Type: multipart/mixed;
>	boundary="----=_NextPart_000_0085_01BDBE1A.0436A880"
>
>
>
>Ashish K Hanwadikar
>Senior Software Engineer,
>Wipro Infotech, Technology Solutions,
>Bangalore
>INDIA
>
>-----Original Message-----
>From: Bob Natale [mailto:[email-masked]]
>Sent: Saturday, August 01, 1998 4:29 AM
>To: Martin Jacobsson
>Cc: Smitha Gudur; [email-masked]
>>At 7/31/98 11:56 PM, Martin Jacobsson wrote:
>
>Hi Martin,
>
>>Section 2, goal 4 says:
>>
>>- Provide statistics about the protocol operation such
>>as the number of packets to and from each subagent
>>
>>This information is not available through the mib as defined.
>>One option is to add agentxSessionInPackets and
>>agentxSessionOutPackets to the session table. And another is
>>to add agentxConnInPackets, agentxConnOutPackets,
>>agentxConnProtocolErrors and agentxConnParseErrors
>>to the connection table. All as Counter32's.
>
>First, let me note that there is considerable sentiment to
>keep this MIB relatively minimal.
>
>Second, you are right, if state such purposes (and the
>one you quote seems like a sound one to me).  The approach
>that I would like to propose for this purpose is to add
>an agentxResponseTable.  This would be indexed by
>agentxSessionID and consist of a set of objects (with
>syntax of GAUGE32, I suggest), one for each of the possible
>AgentX-Response-PDU res.error codes (including no_error).
>
>Such a table would handle overall (by simple summing),
>connection-specific (by mapping back to agentxConnectionTable
>via the agentxConnIndex in the corresponding agentxSessionTable
>row, and session-specific traffic and error counts for all
>active sessions.
>
>>Then a port table would be nice, so that it is possible to see
>>what ports the master agent accepts connections from
>
>I think this can be had now, via the agentxConnTransportDomain
>and agentxConnTransportAddress objects in the agentxConnectionTable.
>No...?
>
>>and if it listens on any nondefault ports.
>
>I'll pass on that one (I don't really see the need for it).
>
>>A typical unix master agent will listen on both tcp port
>>705 and unix-domain socket "/var/agentx/master".
>
>True...and the two objects mentioned above would, I think,
>tend to reveal that, given at least one active connection
>from each domain.
>
><Ashish> given at least one active connection .. That is the hitch. 
Suppose,
>the sub agent wants to know which transport should he use to 
communicate
>with the Master Agent? If no connections are active, then it is very
>difficult to known on which transport domains the Master Agent is 
listening.
>I think it will be generally be useful from the Sub Agent and Sub Agent 
API
>developers point of view to add an agentxListenTable to the AgentX MIB.
>I guess such a table was there in the DPI from which AgentX derives its
>inspiration.

There are other ways of finding out, which port the Master agent is 
listening. In unix environment, netstat and other commands would do the 
work.

One suggestion, is such a table instead of being repeated in every MIB
of agent/subagent protocol(s), it would be nice to have this table
in SNMP which allows the user to know which agent protocols and ports  
these are listening to, at any time.

smitha

>Thanks
>Cordially,
>
>BobN
>------------ ISO 9001 Registered Quality Supplier -----------
>Bob Natale         | ACE*COMM              | 301-721-3000 [v]
>Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
>[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
>------------- Free downloads at www.winsnmp.com -------------
>
>

---

From: "Matt White" <[email-masked]>
Date: Tue, 04 Aug 1998 09:31:19 -0400

--On Tuesday, August 04, 1998, 1:28 AM -0400 "Bob Natale"
<[email-masked]> wrote: 

> Avoiding re-use of small integer indices has simply become a matter
> of "good practice" where other factors do not dictate otherwise.
> 
> (Note that, as has already been said, we can only do our best to
> avoid re-use, not mandate it...given the (logically possible) case
> of the long-running master that wraps...so far, we have not mandated
> "monotonically increasing", but that is also a good idea in this case...
> and, in any case, the active SessionID values in a given invocation
> of the master agent must be globally unique.)

I suppose.  I'm not experienced enough with this to have any first hand
experience with reusing integer indices causing problems.  Which is of
course why I chose to reuse them in the first place.

> At the bake-off, one implementation out of five under test (to the
> best of my knowledge) had taken the approach of quickly re-using
> SessionID values.  The developers were able to make the switch
> to the "avoid re-use" model in a matter of minutes.  That's just
> a single data point, I know; I realize that there may be many
> valid reasons why anyone else's mileage may vary.

Well, it's not quite that trivial in my case, but I imagine that it's
probably not more than a day of coding to replace my dynamic arrays with
hash tables.  Our memory footprint will probably increase, but if that is
the worst thing that happens to me this year...

> In any case, we'll be spending a little time fixing up one
> thing or another in our AgentX implementations for a while
> yet.  :-)

Yeah, I was mostly just being grumpy when I made my orginal post.

-Matt