[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I have some suggested changes to this TCP model
that may allow it to be "bolted" onto the existing
infrastructure with few, if any, changes or augmentations
to existing RFCs/MIBs....
- In cases where a command generator also
is acting as a notification receiver, the model
should allow both kinds of transactions on the same
connection instead of forcing the entity to support two
connections. I believe a strict reading of this draft
suggests that two connections are required in such cases,
but maybe that's instead indicative of a need to reword
a sentence or two.
- notification receivers need to be able to initiate a
connection. This draft specifies that ONLY the
notification generator initiates the connection.
- I don't think a new UDP fallback mechanism is needed for
failure of notification delivery over TCP. It's inherent
with TCP connection mgmt in that when a notification receiver
detects a connection drop, it will know it needs to a) re-establish
transport (UDP and/or TCP) if possible/needed, and b) retrieve
whatever logs it desires in order to learn of any missing
notifications or to get back in sync with the managed device.
This approach has apparently worked well for telecom/TL1/etc,
so it will work here too. In any case, even if UDP fallback
is insisted upon, just let snmpTcp targets imply that TCP
is attempted first, and only if delivery fails, then deliver over
UDP is attempted (i.e. no new augmented MIB objects and
no change in rfc2573).
- I think a scalar MIB object should be included
somewhere that indicates the maximum number of new
connections available for an implementation. It can
be -1 if unlimited except for resource limitations.
Implementations should be free to specify maximum number
of supported connections.
- command responders and/or notification generators should
listen ONLY on TCP port 161 for new connections. In other
words, I don't think we need another port besides 161 and 162
if we adopt the other suggestions in this email.
- New connections that "match" an existing snmpTargetTable
are accepted and maintained until a command generator or
notification receiver explicitly drops them. Otherwise, the
connection will be maintained only for an implementation
defined period of time so the initiating entity can add a new
(and matching) snmpTargetTable entry(s) and thereby ensure the
new connection will continue to be maintained. As is the
current practice, this implies that notification receivers must
have pre-configured snmpTargetTable entries in order to receive
notifications (and to initiate and maintain a TCP connection).
- The current draft does not specify how accumulations of
connections that have NEVER seen activity get cleaned up.
The initial timeout feature provides this benefit. I
seem to recall that in TL1, a new connection is dropped after
a period of time if a UID/password is not successfully provided.
SNMP can do the same (metaphorically speaking) by requiring that
a matching snmpTargetTable entry pre-exists or gets newly added within
an implementation defined period of time.
- Long periods of inactivity alone should not determine whether a
connection gets dropped. Perhaps a notification receiver has
configured a notify filter that results in very few and
infrequent (but highly important) notifications to be sent.
- A std notification could be sent to alert initiating
entities that do not match an existing snmpTargetTable entry
that they MUST configure such an entry or else the connection
will be soon dropped. Also, if an entry gets deleted, this
notification can be sent on each pre-existing dependant connection
that will (as a result of the deleted entry) soon be dropped.
- As already specified, the model continues to support the
notification generator attempting to initiate the connection
if one doesn't already exist (regardless of who initiated it
earlier). However, I suggest that connection mgmt rules be
simplified so that notification generators will not attempt to
initiate a non-existing connection if it recently (duration
implementation defined) failed to do so. No retry/timeout
objects are necessary and can be implementation defined.
Juergen Schoenwaelder wrote:
> The NMRG has released another revision of the SNMP over TCP document,
> which may be relevant for this working group.
> We missed the cutoff deadline for an update of the compression
> document. But I hope to be able to circulate a new revision of this
> document on this list before the eos meeting in Minneapolis.