[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: message to nanog
> 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/>