Subject: Re: Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Tue, 21 Oct 2008 09:09:48 +0300 (EEST)

On Mon, 20 Oct 2008, The IESG wrote:
> The IESG has received a request from the Dynamic Host Configuration WG
> (dhc) to consider the following document:
>
> - 'DHCPv6 Bulk Leasequery '
>   <draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2008-11-03. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt

First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery 
(RFC5007), now we have DHCv6 Bulk Leasequery.  And someone seems to be 
proposing DHCPv4 bulk leasequery as well 
(draft-dtv-dhc-dhcpv4-bulk-leasequery).

RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. 
And if you look at the reasoning there, some of these are not even 
valid anymore for bulk leasequeries.  I remain unconvinced.  A far 
better solution would seem to be define a smaller MIB just for 
querying leases so implementing it would be trivial.  Bulk 
leasequeries just underline the fact that SNMP and MIB data models are 
being reinvented inside DHCP.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Marcus <[email-masked]>
Date: Tue, 21 Oct 2008 09:55:14 +0200

On Tue, Oct 21, 2008 at 8:09 AM, Pekka Savola <[email-masked]> wrote:
> First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery (RFC5007), now we have DHCv6 Bulk Leasequery.  And someone seems to be proposing DHCPv4 bulk leasequery as well (draft-dtv-dhc-dhcpv4-bulk-leasequery).
>
> RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. And if you look at the reasoning there, some of these are not even valid anymore for bulk leasequeries.  I remain unconvinced.  A far better solution would seem to be define a smaller MIB just for querying leases so implementing it would be trivial.  Bulk leasequeries just underline the fact that SNMP and MIB data models are being reinvented inside DHCP.
>
> --

I am not an expert on SNMP, but the only way I could imagine that
working, would be by using queries for MIBs which would look like
this:

get <MIB>.<querytype>

As the query type can be a relay id, link-address or remote id, this
would look a bit strange to me. I know and use SNMP mostly for
querying specific, predefined counters or tables, not variable entries
in the MIB tree. Also all implementations I know, use UDP not TCP for
SNMP queries and replies.
The DHCPv6 Bulk Leasquery proposal looks like a logical next step to me.

Marcus

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Oct 2008 08:36:22 +0300 (EEST)

I was hoping some folks more intimate with SNMP and IETF management 
frameworks would chime in here, but I'll respond to clarify:

On Tue, 21 Oct 2008, Marcus wrote:
> in the MIB tree.

If I understand what you want to achieve, what you want is supported 
and indeed used by lots of MIB modules out there.  This is useful and 
indeed we use it regularly with e.g. BGP and IP forwarding MIBs:

$ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46
IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = INTEGER: netmgmt(3)
IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 = INTEGER: local(2)

> Also all implementations I know, use UDP not TCP for SNMP queries 
> and replies. The DHCPv6 Bulk Leasquery proposal looks like a logical 
> next step to me.

An open-source SNMP implementation (net-snmp) is at least available. 
SNMP over TCP is defined in RFC3430. The systems under consideration 
already support TCP, just the TCP SNMP server part is missing; this 
should be trivial to implement if there is a need -- the lack of 
implementation efforts seems like an indication that UDP with 
retransmissions is usually "good enough".

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 22 Oct 2008 10:17:14 -0700

On Wed, Oct 22, 2008 at 08:36:22AM +0300, Pekka Savola wrote:
> $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr 

This essentially would be identical to DHCP leasequery, minus the
bulk.  Even if transported via TCP, on the wire it would look like
a single client->server GETNEXT, waiting for a server->client reply
before sending the next one.  One PDU and one OID in it at a time.

snmpbulkwalk is a minor improvement; a single UDP reply can contain
many iterated GETNEXT's, or similarly over TCP.  There is still a
'pause' between the client's request and reply.

What the leasequery bulk methods are looking for is "all at once."
The objective is to fill the socket at maximum window size.  I am
not aware of a means to do this with SNMP considering the kinds of
data in DHCP lease tables, and the usual ways MIBs are constructed.

> ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46

This kind of underlines a qualm with SNMP data management (as opposed
to network management).

For each iterated GETNEXT or GETBULK both rely upon a fixed point in
the database ("node n"), which was present in the database and was
the last PDU in the server's reply in the previous packet.  But it may
not be present in the database at the time the next request is made.

This requires the database models used by the servers to be able to
find a "reliable sorting", where the previously-valid-now-invalid
OID can still be used as an index to provide continuation; it can
still grant the next OID.

This essentially is a problem, or at least a facility not present in
some DHCP databases, which caused us to motivate away from UDP based
bulk queries (the original bulk leasequery proposal was more similar
to snmpwalk in this regard, and this was a concern raised by
implementers).

In addition...

SNMP likes to present a single table of a single variable at a time.
I suppose we could overcome this by having the DHCP lease information
in an 'blob of octets' rather than in classical SNMP variable form
(INTEGER etc), so you only have one MIB to walk.  But it seems foreign
to SNMP to do so.

The problem is that most leasequery clients are not positioned to
allocate fields of temporary memory in order to make sense of SNMP's
kind of "scatter-gather" approach to this kind of data transfer.

To make sense of SNMP MIBs you have to develop some strategy to
receive multiple datapoints from different locations and times.

For example, you start by walking a table of "index" advertisements,
where you receive an 'index number' that can be used into other MIBs
to find variables associated with that database entry.

For each of these indexes you discover, you could then queue single
GET PDU's for each separate variable you were interested in (lease
state, lease expiration time, ...).

There are 'performance alternatives' from there, and they are
fantastic to entertain because so many SNMP server implementations
will outright crash if too many PDUs are queued in a single packet
(others corrupt their replies if there are more than single PDU's).

This becomes more problematic when you consider that some leasequery
clients are going to want only a subset of the MIB's total contents.
The question truly is "what leases did I have in my table before I
rebooted?"  Such filtration in an SNMP MIB model I think would be
done on the client end, not on the server end, meaning the client
still must traverse some entire MIB one PDU (GETNEXT or GETBULK) at a
time.

This is different from the proposed bulk leasequery models, where the
server writes to the TCP socket "all at once", with all data for a
given lease spatially located in the same position in the TCP stream,
and a primitive query language ("by query type") to provide subsets.

This doesn't mean a standard DHCP MIB isn't a bad idea for entirely
different reasons.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 22 Oct 2008 21:15:01 -0700

Hi -

> From: "David W. Hankins" <[email-masked]>
> To: "DHC WG" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 22, 2008 10:17 AM
> Subject: Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) to Proposed Standard
...

> (INTEGER etc), so you only have one MIB to walk.  But it seems foreign

Uh...  One of the useful features of tables is to organize related information
into conceptual rows with common INDEX values.  I'm not sure where
"a single table of a single variable at a time" comes from - GetBulk
certainly has no such limitation.

...
> state, lease expiration time, ...).

That would be a spectacularly inefficient implementation strategy.
I should hope there's nothing in the SNMP RFCs that would be
read as encouraging such wasteful behaviour.

> (others corrupt their replies if there are more than single PDU's).

I'm not sure what you're trying to say here.  An SNMP message (which
would normally be carried in a single UDP datagram) by definition
contains exactly one SNMP PDU.

> still must traverse some entire MIB one PDU (GETNEXT or GETBULK) at a

This depends on the design of the MIB module in general, and the
selection of the INDEX elements in particular.  Choosing INDEX
elements for a MIB module is *not* the same problem as selecting
indexes for a database.  The use cases for information access, such
as "what leases did I have in my table during time period X" are also
important.  Sometimes it makes to have "shadow" tables that do
nothing but provide re-ordered access to the table with the "real"
data - but this requires careful thought about what the high-frequency
or high-value use cases are.

Randy

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Oct 2008 08:47:57 -0700

> certainly has no such limitation.

I don't remember referring to GetBulk, and I don't understand why I
would have.

If you don't know where "a single table of a single variable at time"
comes from, then walk the 'interfaces' mib on any system at your
convenience.  Note how 'ifDescr', 'ifInOctets', and etc are all
organized with spatial locality, but the data for "interface 5" is
not.  This spatial locality does not track with common application
temporal locality requirements, which wants all the details for one
conceptual object at once so that it may continue with processing it,
rather than waiting.

> read as encouraging such wasteful behaviour.

Efficiency is often subjective.  Are you optimizing for simplicity
of design (using one walk to traverse an entire mib), or are you
optimizing for the lowest latency to complete configurations?  Are
you optimizing out variables you have no interest in (most MIBs are
half extra data you don't require)?  What kind of device are you
querying?

On some models of router, for example, a SNMP query causes a message
to be sent over their own 'control bus' to fetch all statistics for
a single interface.  The most recent control command is cached,
because it was designed to be used for a CLI command to display a
single interface's data.  The typical snmpwalk or even bulkwalk
scenario means every interface is queried multiple times; once for
each table they appear in.  This kills the cached object, by using
none of its locality, and overworks the command bus.  Even if the
router's cache were larger, it would have to be equal in size to the
number of (physical and virtual) interfaces in order to have even one
hit.

An application trying not to live in 1985 might find itself doing,
as I describe, a kind of dance to get out of SNMP's spatial locality
mindset.  In this case, you would query all the data you required
pertaining to one interface at a time, before moving on to the next
interface.

An application requiring not to live in 1985 definitely will find
itself queuing more than one packet to a single SNMP server at a
time.  In this case, walking some number of tables in one session,
while queuing query packets filled to the brim with GET's for all
specific relevant data for each interface in series.

Unless you're querying a Cisco Catalyst, in which case queuing more
than one packet at a time is foolish; the Cat will drop the second
packet if it is busy with a request already, and you'll have to sit
in retransmission hell.  But I'm getting sidetracked.

The advantages here I am describing are twofold;

1) The object for "interface 5" is read in the least time possible,
  even though the time to read the entire dataset remains constant
  (due more to RTT than to bandwidth).  "interface 5" can move on to
  the next stage in processing while SNMP data continues to flow,
  rather than waiting for the walk to finally reach the last table of
  variables.

2) The router is not flagellated needlessly, resulting in a lower
  time to complete the operation overall.

> contains exactly one SNMP PDU.

Possibly this is a kind of brain damage that arises from the SNMP
library I once used, which describes multiple query commands in one
packet as PDU's, even if they are labeled internally to SNMP as being
'variable bindings' attached to the end of the PDU.  I wind up using
the terms interchangeably as a result.

> selection of the INDEX elements in particular.

I don't see how any SNMP MIB design cleverness can get around "the
SNMP way" of requiring strictly ordered datasets for GETNEXT support.

But good luck with that, and I look forward to reading your DHCP MIB's
draft.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2008 09:41:49 -0700

Hi -

> To: <[email-masked]>
> Sent: Thursday, October 23, 2008 8:47 AM
> Subject: Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) toProposed Standard
...
> conceptual object at once so that it may continue with processing it,

An application that relies on "walking" a MIB to retrieve information
in this way is *seriously* broken, IMO.  The whole point of the way
INDEXes work in SNMP (and the reason the variable binding list
can hold multiple variable bindings) is so that one can access
a bunch of variables (with same or different index values, from
the same or from different MIB modules) in a single request.
SNMP has its limitations, but "spatial locality" is a non-issue here -
an application design that requests information it doesn't need in
an order which is not useful is the fault of the application designer,
not the protocol.

> > state, lease expiration time, ...).

Spectacularly bad design.  It would make much more sense to only
ask for the interfaces of interest (if known) in the first place, and in
any case, asking for the individual variable bindings one at a time
is just silly, if you'll pardon the harsh language.

> of design (using one walk to traverse an entire mib),

Hardly recommended, particularly since there are some boxes
which do not respond correctly to GetNext, resulting in a situation
where a naive GetNext walk won't terminate.  (Also, some
implementations which followed the letter of the early RMON specs
would result in the same behaviour.)

> or are you
> optimizing for the lowest latency to complete configurations?

Using multiple variable bindings does more that reduce
latency due to the number of round trips.  It also significantly
reduces the per-variable processing cost at both ends (encryption,
authentication, for example) subagent/master agent interaction
(AgentX exchanges, for example) and, for correlated indexes,
may also result in managed device cache advantages.

>  Are
> half extra data you don't require)?

Yet another reason why doing blind MIB walks doesn't make much sense
for management applications.

>  What kind of device are you querying?

Shouldn't matter, though in general the more management information
available in the device, the bigger the advantages to being smart
about what one asks for.

> single interface's data.

This is a good example of why asking for one variable binding at a time
in a MIB walk is not a good idea, and why asking for multiple variables
with correlated indexes in a single SNMP PDU makes sense.

>  The typical snmpwalk or even bulkwalk 
> each table they appear in.

Which is why I claim that applications that indulge in such silly behaviour
should not be encouraged.

>  This kills the cached object, by using

All very good reasons why doing blind, single-variable MIB walks
makes no sense.   Are there any commercial products that
do this routinely?  I'm not aware of any.

> pertaining to one interface at a time, before moving on to the next

This is normal practice - get all the information in one or two requests.

> specific relevant data for each interface in series.

No.  More normal behaviour is to put multiple variable bindings into
a single Get request.  It's perfectly reasonable to request data from
multiple tables in a single Get request, or to walk multiple tables
concurrently using GetNext or GetBulk.

> in retransmission hell.  But I'm getting sidetracked.

It sounds like you're assuming a strawman implementation strategy
that one might find in "toy" scripts, rather than an industrial strength
product.  Despite its warts, it's unfair to dismiss SNMP just because
it's possible to use it in spectacularly inefficient ways.  It'd be like
dissing HTTP because it can carry web pages that have no
useful content.

>   rather than waiting for the walk to finally reach the last table of

You're attacking a strawman.  Any sane implementation would request
all the interesting "interface 5" variables in a single PDU.

>   time to complete the operation overall.

You're atacking a strawman.  Blind MIB walks are not "management".
A sane implementation limits itself to asking for the information
it needs.

> the terms interchangeably as a result.

Variable bindings are contained inside the variable binding list, which is
contained inside and SNMP PDU, which is contained inside an SNMP
Message, which is transported using UDP or whatever.  If you're worried
about cache locality, RTT, or amortization of security costs, it makes
a huge difference.

...

The requirement for ordering is inherent in the protocol, and I agree
it makes interfacing with, e.g., an underlying SQL infrastructure (for
which "ordering" entails extra processing) a pain.  But the point is
that deciding which indexes to use needs to be driven by management
use cases, in order to minimize the situations in which one would need
to walk through an entire table to find the useful bits.

But for the most part you seem to be attacking a strawman - an
implementation strategy contrary to long-understood practice
in building SNMP-based management applications.

Randy

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 23 Oct 2008 12:36:45 -0700

Now I'm hearing you say what I'm saying, that is good, but we're not
quite done;

> is just silly, if you'll pardon the harsh language.

If a DHCP relay knew what leases were present in a DHCP server before
it issued a single SNMP packet, and of them which specific ones it
needed to know about, then it probably wouldn't need to issue an SNMP
packet at all.

Now you see the conundrum.  The process to use SNMP to meet
leasequery's ends (to find out what leases it needs to query about,
and then finally also do that) would be to use SNMP in precisely the
way we are both saying is idiotic!

I have to agree completely and wholeheartedly: SNMP is just broken
for this use case.

> to walk through an entire table to find the useful bits.

There simply is no usable index.  There is no database in our DHCP
implementation that is consistently sorted no matter what time (over
the runtime) you query it; in order to support GETNEXT to be able
to walk the various "lists of leases" and allow the clients to perform
the required discovery, we would have to change literally everything,
and vastly complicate our software.

It is work all around to shoehorn SNMP into this picture, for the
client, for the server, for everyone.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Oct 2008 18:35:13 -0700

Hi -

> Sent: Thursday, October 23, 2008 12:36 PM
> Subject: Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk Leasequery) toProposed Standard
...

> needed to know about, then it probably wouldn't need to issue an SNMP
...
Finally, getting to the use cases: what criteria most frequently determine
the set of "interesting" (for management purposes) leases?

Randy

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 24 Oct 2008 07:46:29 -0700

> the set of "interesting" (for management purposes) leases?

Why does it matter if we've already agreed that SNMP's autodetection
mechanisms are shit?

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 24 Oct 2008 09:26:37 -0700

> do this routinely?  I'm not aware of any.

This is a tangential issue, so I wanted to reply separately, and
later.

I worked for a backbone company a few years ago, I started there
around the turn of the most recent century, which used SNMP for
billing-related data.  When I started, I would say their system
was a nightmare (and they knew it).  Customers were even in the
know, and would routinely dispute their bills knowing full well
the'd get free net.

The short answer to your question, is that there exists today at
least one monitoring package, albeit not commercially nor even freely
available to the public (it is a private tool), which autodetects
all the interfaces and other monitorable variables on every router
in that backbone's network.  The only thing it knows about what it
is going to monitor, in advance, is the hostnames and community
string(s) of the devices it seeks to monitor.

It does this autodetect run once every 30 minutes, or when it restarts
or reconfigs, feeding the results of that search into a table of
'monitored OIDs', which expire out of the table after 90 minutes (or
if it gets an SNMP error indicating future queries would not be
fruitful).  If any device's sysUpTime.0 decreases (sysUpTime was
put at the top of every SNMP GET packet), it alone is re-
autoconfigured.

I would call that 'routine', but again this is fairly subjective.

The monitored OID dataset would be queried once every 30 seconds
(except the Catalysts, due to the limitation I mentioned earlier,
would take 35 seconds to run a single polling run, so they ran
every 60 to give them a breather...they phased the cats out over
time).  This unusually low polling interval was selected somewhat
arbitrarily; "Because we can."  The router polling run would only take
3 seconds (we had around 300 of them, I seem to recall).  It turned
out to have some advantages; 300 seconds is a long time to wait to see
changes in traffic graphs if you tweak BGP.  Collecting 10 datapoints
to make one billing datapoint meant we would generally not lose
anything if we missed a datapoint or even two.

Because we couldn't count on wide implementation of SNMPv2c among
our monitored devices, we used an initial SNMPv1 query against every
device for the sysObjectID (and a couple other things), and then
assigned one of several "handlers" that worked around quirks and
optimized the process for that particular breed of router or switch.

Both the autodection and polling strategies employed a technique
we found by benchmarking the routers and switches we used; we filled
an SNMP packet with as many variables as possible; so that the reply
packet would approach, but not exceed, 64KB, a UDP fragment.

It turns out that if you compared the time it took 50 SNMP packets
transmitted in parallel to be replied to, to the time it took a
single SNMP packet with 50 variables that had to be fragmented,
the faster approach was the single, fragmented, packet.  We used a
fine-tuned number of variables for each system, again keyed by
sysObjectID.

Sensing the remote system's available UDP buffer (again keying
this off of sysObjectID), we would queue multiple such monster
SNMP packets, guaranteeing that at all times throughout a single
polling run, the remote system had an SNMP packet in its buffer
to reply to, and in in the air in both directions, even with
retransmissions.

More information on the subject of autodetection...

On some of the handlers, we were able to capitalize on iterating a
series of GETs for every ifIndex from 0 up to ifCount-1 (usually on
ifName.*, but sometimes ifDescr.*, and even other times (those damn
Catalysts) on their enterprise-mib ifAlias.*, and then queuing
additional ifCount,ifCount+1,... GETs to the tail upon every reception
of an error (indicating a gap in ifIndex, which happens on hot swaps).
Successful replies indicated the interface existed, an entry was
created, and we'd start querying the actual data we wanted from other
tables.  This tail-inserting strategy meant there was a continuous
flow of valid configuration information from the remote end, something
neither GETNEXT nor GETBULK can supply.

But for example, there were switch implementations which used ifIndex
values that were contrived to survive reboots (a feature desired by
people who used the manually-configured SNMP software of the day),
which meant the ifIndex space was sparsely populated.

There was more than just the one MIB we wanted to monitor as well;
anyone with routers wants to know what their environmental monitoring
is saying...and are the fans running?  We are speaking of course of
the fabulous area of enterprise-specific MIBs.  For most of these,
we were able to enter in (in sourcecode) a set of manual extra
variables to monitor (ex: 7200s had exactly 3 temperature sensors and
precisely two power supplies, they were always at precisely the same
OIDs), keyed again by sysObjectID.  But for example, we couldn't do
this for MAC address accounting features, a feature commonly used to
track bandwidth traded with multiple peers on one interface.

The pain involved in autodetecting the MAC accounting MIB (because it
could change more frequently than once per half hour) successfully
kept me from using it.  That is a challenge that exceeded either my
interest or my ability, I'm not sure which.  I'm sure the ops team is
still using their expect script to fetch MAC accounting data out of
the routers' CLI.  I find that preferrable either way.

So, yes Randy, there are folks who use SNMP routinely in this way,
and there are also folks who refuse to use SNMP in this way.

The lesson is that madness is relative, and you must often do insane
things to avoid even more insane consequences.

---

From: Peter Dambier <[email-masked]>
Date: Fri, 24 Oct 2008 20:14:02 +0200

>> do this routinely?  I'm not aware of any.

Adding to David,

IASON originally did a lot with SNMP, because of catalysts :)

We used Open Source snmpwalk because that was the easiest way to go.

When we added boxes and MIBs we got into trouble and out of memory.

As David observed, SNMP used to be slow and consumed a lot of cpu on
both the monitor and the monitored boxes.

We dropped SNMP finally when we moved away from the catalysts.

IASON never went commercial but is in the Open Source now and still very
pre beta.

Kind Regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 24 Oct 2008 12:19:56 -0700

Hi -

> Sent: Friday, October 24, 2008 9:26 AM
> Subject: a modern-day SNMP use
...
> I would call that 'routine', but again this is fairly subjective.

Doing this does *not* require blind MIB walks.  One can discover
the set of supported MIBs (from a set of MIBs one knows how
to manage - there's little point in discovering a MIB one does
not know how to manage) with a relatively small number of
GetNext requests, where the number of probes needed ends up
being (favorably) proportional to the number of MIBs actually
supported by the device.  Interfaces can be discovered even
more economically, thanks to GetBulk and the "non-locality"
you complained about in an earlier message.

...
> fine-tuned number of variables for each system, again keyed by

None of this is surprising, and is consistent with what other products do.

...
...

??? You'd end up with far fewer exchanges using GetBulk.  GetNext would
never require more exchanges, and under some circumstances (sparse
ifIndex allocation, for example, as you mentioned below, or access control
limitations) would require fewer. The approach you describe sounds like
a lot of clever for no net gain.

But the net of all this is that, as ugly as it is, SNMP can be used efficiently and
effectively, and we shouldn't confuse shortcomings of some tools with
shortcomings of the protocol or data models.  They have enough real
ones of their own; we don't need to fret about imaginary ones and spend
time knocking down strawmen.  Some of this discussion reminds me of early
claims that CMIP was spectacularly inefficient.  Turns out that protocol
can be implemented with roughly the same code size and effort as
SNMP, and is quite cheap to parse and encode; the "inefficiency"
folks were so worried about was a quirk of an early, freely-available
implementation, not something inherent in the protocol.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 24 Oct 2008 12:31:40 -0700

Hi -

> Sent: Friday, October 24, 2008 7:46 AM
> Subject: Re: [dhcwg] LastCall:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6Bulk Leasequery)toProposed Standard
...
...

I'm not part of your "we".  Someone who cares can give the rest of
the tutorial.

Randy

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 24 Oct 2008 18:38:42 -0700

On Fri, Oct 24, 2008 at 12:31:40PM -0700, Randy Presuhn wrote:
> I'm not part of your "we".

Wow, this is a situation I did not anticipate.

You know about all the handstanding, all the backwards thinking,
all the extra overhead in putting scatter/gather to work.  And
you think that's the way it should be.

> Someone who cares can give the rest of
> the tutorial.

Yeah, I don't think I can help you either.  We're both failures as
teachers.

---

From: Marc Manthey <[email-masked]>
Date: Sat, 25 Oct 2008 17:24:20 +0200

> IASON never went commercial but is in the Open Source now and still  

hello peter and karin

if you add me  [ 1 ]  to your "developer list " on sourceforge [ 2 ]  
with the right privileges
i would like to add  the documentation from iason [ 3 ] to your  
sourceforge site and
"commit " the latest source, i´ve learned a bit in the past days about  
CVN
and i would like to assist in my spare time. ;)

greetings  from cologne to Moerlenbach

Marc

  [ 1 ] https://sourceforge.net/users/manthey08/
  [ 2 ] https://sourceforge.net/projects/iason/
  [ 3 ] http://iason.site.voila.fr/Iason/

-- 
"In a world without walls or fences, who needs Windows and Gates?"

Les enfants teribbles - research and deployment
Marc Manthey - head of research and innovation
Hildeboldplatz 1a D - 50672 Köln - Germany
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
jabber :[email-masked]
blog : http://www.let.de
ipv6 http://stattfernsehen.com
xing : https://www.xing.com/profile/Marc_Manthey