RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt

[massadb@netscout.com]

I think Andy's general premise is correct in wanting to reduce complexity
and encourage progress. Why is support for C64 not considered a new feature
among the "new features" to be implemented? DSMON is not finalized so
that's a good place to start.

I also agree with a previous email that suggests dropping the 32-bit
counter enitrely, not just the overflow. That would would make it even more
simple. Otherwise, how does the NMS know if 32 or 64 bit is supported.
Would we then need a capabilities indicator?






"Les Bell" <Les_Bell@eur.3com.com>@ietf.org on 10/03/2000 04:58:04 AM

Sent by:  rmonmib-admin@ietf.org


To:   Andy Bierman <abierman@cisco.com>
cc:   rmonmib@ietf.org, mibs@ops.ietf.org
Subject:  RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt




Hi Andy,

I agree with Ofer Goren that it is not a simple compile switch to support
SNMPv2C/v3 for the majority of implementations.

But I would go a bit further and suggest that you should continue to
support the
overflow counters in new MIBs.  If you don't, then I believe they will be
defined in proprietary MIBs by the majority of vendors that cannot easily
support SNMPv2C/v3.  This will make it more difficult for the NMS people
everywhere.

It is true that there are a few SNMPv2C/v3 implementations out there that
could
be used as a replacement for the many SNMPv1 implementations that are out
there.
However I would find it difficult to justify the cost of purchasing a third
party SNMPv2C/v3 implementation and porting it into an existing product.
Even
taking a 'free' implementation requires significant development effort to
port,
adapting it to interface to an existing product, or adapting the rest of
the
software to the new SNMP interface.  Why should I have to divert resources
to
this work when I could implement new features instead, where the end-user
will
see as a more direct benefit.

If you have an agent and NMS that both support SNMPv2C/v3, then you always
have
the option of not implementing the overflow counters in your agent.  The
MIB
compliance statements can make it clear that it is required to implement
either
the 64-bit counters or the 32-bit overflow counters, but it is not required
to
implement both.

We have an existing solution to the 64-bit counters that works well with
existing equipment.  Let's not break it.

Les...





jay@netscout.com on 03/10/2000 07:53:47

Sent by:  jay@netscout.com


To:   "Ofer Goren" <ogoren@nortelnetworks.com>
cc:   Andy Bierman <abierman@cisco.com>, rmonmib@ietf.org, "Ofer Goren"
      <ogoren@nortelnetworks.com>, mibs@ops.ietf.org (Les Bell/GB/3Com)
Subject:  RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt





Hi Andy,

It makes more sense to me that we propose this change for all new drafts
and let the old ones
stay as they are. Many vendors have already  implemented existing drafts on
both the
agent side as well as the application side and to make such a fundamental
change at this
stage presents quite a bit of a problem. It may be as simple as recompiling
the code with a
v2-enabled stack for some but for some others it may be as complex as
rewriting the code.
One should also not forget the retesting  involved so as to ensure that all
is well in terms of
functionality, compatibility with one's own  application, compatibility
with third-party
applications etc. So, I would suggest that we leave the existing drafts as
they are (eg. DSMON)
and implement the new idea only for freshly proposed drafts.

Regards

Jay







"Ofer Goren" <ogoren@nortelnetworks.com>@ietf.org on 10/02/2000 04:26:33 AM

Sent by:  rmonmib-admin@ietf.org


To:   Andy Bierman <abierman@cisco.com>, rmonmib@ietf.org
cc:   "Ofer Goren" <ogoren@nortelnetworks.com>
Subject:  RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt




Hi.
The majority of the SNMP agents used today do not support SNMPv2C/v3. I can
tell you that our application uses the overflow counters for that reason.
It should take some time to upgrade the SNMP agent in use to the newer
version. Hence, I think that the WG should implement the new behavior only
for the next drafts, and not for the ones in progress (such as DSMON).

Regards,

Embedded SW Team Leader
Email





       : ogoren@nortelnetworks.com
Phone number: +9723-6456023
Fax number  : +9723-6479579
ESN         : 826-6023
http://www.nortelnetworks.com
----------------------------------------------------
If you lend someone $20, and never see that person again,
it was probably worth the investment.

 -----Original Message-----
From:   Andy Bierman [mailto:abierman@cisco.com]
Sent:   Sun, October 01, 2000 6:24 PM
To:     rmonmib@ietf.org
Subject:        [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt

Hi,

I would like to propose that it is time to stop duplicating Counter64
objects in MIBs with a "Counter32/Overflow32 pair". It is time to
require SNMPv2C support in applications to access 64-bit counters.

I would like to remove all of the "overflow counters" from the DSMON MIB,
(such as dsmonStatsInOvflPkts or dsmonStatsOutOvflOctets).  The 32-bit
versions should remain, because DSMON could obviously be implemented on
a device that doesn't need 64-bit counters.

For devices that implement the Counter64 version of a counter object, the
corresponding Counter32 version must also be present, and should equal the
lower 32 bits of the 64-bit version at all times.

Furthermore, it shall be the policy of the RMONMIB WG that no such
"overflow counters" will be published in any future work.

Any objections to changing the DSMON MIB and/or establishing this policy
for the WG?

Andy

_______________________________________________
RMONMIB mailing list
RMONMIB@ietf.org
http://www.ietf.org/mailman/listinfo/rmonmib