[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-irtf-nmrg-snmp-tcp-06.txt


Juergen Schoenwaelder wrote:
> >>>>> Lauren Heintz writes:
> Lauren> I have some suggested changes to this TCP model that may allow
> Lauren> it to be "bolted" onto the existing infrastructure with few,
> Lauren> if any, changes or augmentations to existing RFCs/MIBs....
> Just to be clear: The current document only describes the simple model
> where "the guy who has something to say is responsible to open the
> channel". The appendix only documents options that were discussed and
> lists some trade-offs we identified.

One might also argue that "it's the guy who needs something
who is the one who should open the connection."  Currently,
notification generators can't even send things until the
tables are configured by the notification-receivers (or
by someone on their behalf).  I sort of view the action
of configuring as being the first event in a transaction
(as opposed to the first notification).  Why not use the
same connection to configure as the one which data is received

There are also tradeoffs with the approach of the notification
generator initiating connections:

  - that model attempts to initiate connections even when the
    target is temporarily off-line (perhaps they want a
    permanent config to remain in place so it's there
    whenever it's needed).

  - connection mgmt is a task more suitable for the
    notification receiver.  Even if retry/timeout
    objects are provided by a notification generator,
    what happens after they expire the final time and
    no more connections are ever attempted?  Does the
    notification receiver (which was temporarily offline
    or had to be brought down for a few hours because of
    a problem) then need to delete the config and then
    reenter it to "reset" the notification generator so
    that connections will once again be attempted?  Or are
    snmpTargetTable entries automatically deleted once
    it seems they are not useful?  Where is the "reset"
    button so that the targets may again connect?  With
    the other model, such a reset button is not needed.
> [...]
> Lauren> - notification receivers need to be able to initiate a
> Lauren> connection.
> I think this is the core of your comments, so lets focus on this one
> first. Can you please justify the requirement? Why is it needed? What
> is missing if this feature is not there?

I'm suggesting it is technically possible
and politically desirable to allow notification
gen's and/or receivers to initiate the connection.

I think it's justified by previous discussions wherein
several (not just one or two) other people voiced similar
strong desires to have this feature -- not to mention that
arbitrary decisions to choose something different
doesn't justify the opposite argument.  In short, I think a
whole class of potential users are being shut out by not
allowing notification receivers to open connections.  In fact,
I believe the entire telecom market prefers the kind of
model I suggest (where 1000's of NE's are NOT actively
trying to initiate connections with targets that may or
may not be there).  I'm sure I will hear loud protests
over that claim if I am wrong!  :-)  I think the TL1
connection model teaches some lessons we ought to listen (no
pun intended) to if we want SNMP to succeed in telecom.
> Regarding <draft-irtf-nmrg-snmp-tcp-06.txt>, do you think there are
> flaws in the discussion of this point in the last paragraph of the
> appendix? If a notification originator accepts a new connection, does
> it in your opinion have to match a preconfigured snmpTargetTable or
> not? If not, how to you populate a new entry in the snmpTargetTable?

First, I think the draft and the general model therein
is very useful and valuable, so I hope my suggestions
aren't taken as blanket criticism.  The appendix seems
to invite discussion on these other matters, and I assumed
that's one reason you added it, and that's why I did so! :-)

I think my suggestions in the previous email indicate
how I would hope to see things work in this matter.
In summary: I think preconfigured snmpTargetTable
entries are needed (same way things work now with UDP);
I think combination command-generator/notification-receiver
appls need to be able to use one connection for both
purposes (same way TL1 works) and this implies
that notification-receivers also need to be able to
initiate connections; we need to simplify connection mgmt
issues on the agent side; and there's no reason (I think)
that we need to modify current SNMP methods to accomodate

So, assuming we preserve the model where notification
generators MAY initiate connections (something I believe
many telecom users will not like), WHY NOT also allow
notification generators to initiate connections?


> /js
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>