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

Re: Update to Netconf Notifications Draft



Martin Bjorklund wrote:
Hi,

A comment on section 3.8, interleaving messages.

The larger issue that is still unresolved is how
important this feature is to have.  The extended RPC
approach is much simpler, at the cost of the resources
for an additional session.  The extended RPC approach
is also much better for the 'ping' scenario than
a special notification type for 'RPC reply'.

We still have a high-level disagreement on the relative
engineering cost trade-offs of using 2 sessions vs. sharing
1 session for operations and notifications.

IMO, we are pretty far from a clean standard.
The eventual solution will need to provide for
proper standard read-create data models, specify
a reasonable architecture and security model,
and be as simple as possible, with a small number
of options.

We also need to explain why it is so important that
the NMS get copies of notifications in NETCONF sessions,
as opposed to using a mgr-2-mgr API to get the same information
from a notification receiver application (e.g., syslog +
SNMP trap server).

Some people have also suggested that we explain in the RFC
why a special NETCONF notification system is needed
in order to solve the network configuration problem.


Andy



Suppose the manager sends a large copy-config and at the same time the
agent sends a large notification.  If care is not taken, the write()
call on each side can block, and we would get deadlock.  To avoid
this, the manager and/or agent could be required to use non-blocking
io, and - while writing the large message - read from the session and
buffer internally.  Alternatively, the agent could use two threads.

Should any of this be specified?  Does a client application which
supports interleaving messages have to use non-blocking io in order to
be compliant (or should the agent handle this)?


/martin

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>




--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>