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

Re: message to nanog

To: Rob Enns <rpe@juniper.net>
Subject: Re: message to nanog
From: Andy Bierman <abierman@cisco.com>
Date: Thu, 20 Nov 2003 13:34:49 -0800
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, Margaret.Wasserman@nokia.com, lear@cisco.com, netconf@ops.ietf.org
In-reply-to: <20031120194404.GA17431@sapphire.juniper.net>
References: <7D5D48D2CAA3D84C813F5B154F43B15502FB7D53@nl0006exch001u.nl.lucent.com> <7D5D48D2CAA3D84C813F5B154F43B15502FB7D53@nl0006exch001u.nl.lucent.com>

At 11:44 AM 11/20/2003, Rob Enns wrote:
>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?

I agree with your characterization of the two types of users
of NETCONF.  I think the proposal made in Minneapolis solves
the problem nicely:
  - the operation channel is mandatory
  - the management and notifications are optional

This provides for a NETCONF-LITE for script writers
which is just a simple connection-oriented RPC mechanism,
and a more complete management protocol for application
developers.



>Rob

Andy



>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/> 


--
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/>

Follow-Ups:
- Re: message to nanog
  - From: Eliot Lear <lear@cisco.com>

References:
- RE: message to nanog
  - From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Re: message to nanog
  - From: Rob Enns <rpe@juniper.net>

Prev by Date: Re: message to nanog
Next by Date: Re: message to nanog
Previous by thread: Re: message to nanog
Next by thread: Re: message to nanog
Index(es):
- Date
- Thread