[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update to Netconf Notifications Draft
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
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'.
Altough I personally prefer the endless RPC model for events, I don't
think it's "much simpler", at least not from an implementation point
of view. The agent side might be simpler in some case (e.g. it
doesn't have to deal with a modify command), but on the other hand the
manager side needs to synchronize events if it wants to emulate a
modify operation.
The manager has to synch notifications to operations
using 2 or 3 different protocols now. I am talking
about 2 sessions of the same protocol instead.
It is true that the manager design has to allow for more than
one active session per agent. This doesn't seem much harder
than allowing for more than one active session (to
different agents).
The agent already has code to keep multiple sessions from
stepping on each other. For mixed-mode, it needs additional
code to provide the same sort of safeguards within a session
as well.
I changed the name from "endless RPC" to "extended RPC"
because it does end if so requested.
BTW, there is absolutely no difference at all from
a NMS implementation POV, between an agent that is
sending an extended rpc-reply (e.g., <notification>
element sent as needed) and an agent that is sending
the contents of a <get> reply really, really, slowly....
There is no requirement at all that any portion of a
NETCONF PDU be transmitted within a certain period of time.
Managers and agents need to deal with this fact.
Also, even if the model in Sharon's draft is used for events, the
endless RPC can still be used for ping-like commands.
Yes, you can already do this -- without changing a single
word in the NETCONF spec.
/martin
Andy
--
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/>