[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: message to nanog
There are (at least) two groups of folks currently unhappy with the
current state of configuration of network devices.
1. operators
- use expect scripting, may be happy w/out channels and async notifications
-> this is what Eliot's msg is intended to clarify
- esp for operational data gathering (recall Grover Browning's
comments at NANOG 28) notifications aren't necessary.
- larger operators have in-house oss development teams which may fit
better into the next group
2. oss vendors (including large operators internal systems
and device vendors' oss offerings)
- also forced to use expect for many devices and have to deal
with async events related to configuration changes via syslog
or snmp traps today
I'm wary of treading the same ground over again.
We polled operators in the room (IETF 56) wrt the XMLCONF draft
which had mandatory channels and optional notifications,
and they said they supported it.
One option we've discussed is rewording the NETCONF draft
such that a transport like SSH wouldn't require the use of
notifications or explicit channels. It would instead be
a logical operation channel over a single transport connection
with no notifications and no rpc-abort/progress.
However NETCONF would not preclude use the additional capabilities of
other transports (BEEP) to allow notifications to be sent via another
channel. Seems like this should make both groups reasonably happy.
Comments?
Rob
On Tue, Nov 18, 2003 at 04:07:33PM +0100, Wijnen, Bert (Bert) wrote:
> > Reading this message, I wonder if it makes sense to ask operators
> > these questions without some explanation of the tradeoffs involved...
> > The notifications question may be fairly straightforward, but do we
> > expect engineers who haven't read the netconf specs to understand
> > the concept of "channels" and to know what benefits they have, what
> > complexity they add, etc?
> >
> And the question is first (I think):
> - do you plan to have multiple things going on in paralel
> - if so is having multiple connections an issue?
>
> > Bert had mentioned the possibility of sending a longer questionnaire
> > to operators (I think he meant the ops-dir) regarding their need for
> > various netconf features. Bert, are you still planning to do that?
> >
> I hope so. But we need the WG to come up with the list.
>
> > If so, we might want to combine these questionnaires and send the
> > same questions to both ops-dir and nanog. What do folks think?
> >
> I think that is what we should do.
>
> Bert
> > Margaret
> >
> > > -----Original Message-----
> > > From: owner-netconf@ops.ietf.org
> > [mailto:owner-netconf@ops.ietf.org]On
> > > Behalf Of ext Eliot Lear
> > > Sent: Monday, November 17, 2003 2:00 PM
> > > To: netconf
> > > Subject: message to nanog
> > >
> > >
> > > At the plenary, we agreed that I would draft a message to
> > > NANOG to ask
> > > for feedback on features such as notifications & channels.
> > > Here is my
> > > first cut at such a message. Let me propose that if we don't
> > > get enough
> > > responses, we actually go to NANOG and do a presentation.
> > >
> > > Subject: YOUR opinions needed for Network Configuration Protocols
> > > Reply-to: netconf@ops.ietf.org
> > >
> > >
> > > Dear NANOG folk,
> > >
> > > The NETCONF working group of the IETF is currently developing a
> > > collection of protocol specifications for the configuration
> > > of network
> > > elements. This work originated from a roadshow that many of
> > > us went on
> > > to learn what operators of different types want in such a
> > > protocol. Now
> > > we would like to checkpoint with you on some of the
> > contents of those
> > > specifications.
> > >
> > > The protocol itself is split into two parts: an abstract set of
> > > functions, and a binding to specific protocols, including
> > > SSH, BEEP, and
> > > SOAP over HTTP(s). Each protocol has its pluses and minuses.
> > >
> > > As envisioned, the base protocol supports an option for
> > > notifications.
> > > The idea is that a manager would be notified of
> > configuration-related
> > > events, such as a card insertion or removal, and act
> > appropriately to
> > > configure the element. The envisioned format of
> > > notifications is either
> > > reliable syslog from RFC 3195 or something similar. Because
> > > notifications are asynchronous, one writes code that implements a
> > > dispatch mechanism that discriminates on the type of event.
> > > Notifications would be an option that not all managers
> > would have to
> > > implement.
> > >
> > > The working group is attempting to determine whether notifications
> > > should remain as part of the base specification. Here are
> > > the choices
> > > facing the group:
> > >
> > > Option A. Leave them in as currently specified, and require all
> > > protocol mappings to support them.
> > > Option B. Allow them to be asynchronous, but don't use RFC
> > 3195, and
> > > require all mappings to support them.
> > > Option C. Remove them entirely from the specification and
> > > let vendors
> > > implement RFC 3195 or other notification mechanisms as they
> > > see fit (for
> > > instance, existing syslog).
> > >
> > > Do you have an opinion on which of these options you would like?
> > >
> > > Related, the NETCONF base protocol currently makes use of the
> > > notion of
> > > channels. Channels are a basic concept in the BEEP protocol,
> > > and they
> > > exist in SSH as well. However, use of multiple channels in
> > > SSH is not
> > > supported in common SSH applications. They are completely
> > absent in
> > > HTTP, and so the notion of a session would have to be
> > > introduced in the
> > > mapping.
> > >
> > > Channels provide a number of benefits. First, they divorce
> > > the idea of
> > > who is the session initiator and who is the device manager.
> > > This means
> > > that either the network element or the manager could initiate a TCP
> > > connection. This is useful when NATs and firewalls exist between a
> > > device and the manager. Channels are also necessary to
> > > implement a way
> > > to determine progress of a configuration operation.
> > >
> > > The working group has three choices:
> > >
> > > Option A. Keep channels in the base document and require
> > > each mapping
> > > to support them.
> > > Option B. Make channels optional.
> > > Option C. Remove channels from the base protocol and allow
> > their use
> > > in the protocol bindings.
> > >
> > > Which option do you prefer?
> > >
> > > If you would like to read the entire set of documents, you
> > will find
> > > them by going to the NETCONF working group charter page:
> > > http://www.ietf.org/html.charters/netconf-charter.html
> > >
> > > Eliot
> > >
> > > --
> > > 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/>
> >
>
> --
> 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/>