Re: [irs-discuss] IRS problem statement and NETCONF/YANG

[Alia Atlas <[e-mail]>]

Hi Juergen,

Thanks very much for your informative email.  I certainly have more
reading to do on NetConf and would welcome help in correcting the
perspective in the appendix about NetConf.

It sounds like NetConf could be a good candidate protocol when we get
there.  As I've said, we've got to focus on clearly describing the
problem and vertical use-cases; then we should be able to think about
and evaluate protocol possibilities.

Of course, it'd be useful to have a good accurate and up-to-date
understanding of the capabilities of each protocol before then.

If you have time and interest, I'd be happy to chat off-line tomorrow
and have more NetConf/Yang clue installed.

Alia

On Tue, Jul 31, 2012 at 10:49 AM, Juergen Schoenwaelder
<[e-mail]> wrote:
> Hi,
>
> reading through the problem statement posted at
>
> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>
> I noticed a number of statements concerning NETCONF and YANG that
> probably need to be corrected. For more background where NETCONF and
> YANG is, you may want to consult the tutorial slides posted at
>
> http://cnds.eecs.jacobs-university.de/slides/2012-ietf-84-netconf-yang.pdf
>
> and consult the documents referenced in the slides. Some more detailed
> comments:
>
> :   Finally, the IETF's Network Configuration (or NetConf) protocol has
> :   made many strides at overcoming most of the limitations around
> :   configuration that were just described.  However, the lack of
> :   standard data models have hampered the adoption of NetConf.
>
> The NETMOD working group has been chartered to work on common core
> data models and currently has core data models for the configuration
> of network interfaces, ip interfaces and a core routing configuration
> data model in WG last call:
>
> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-04
> http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-05
> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-05
>
> :   While NetConf has solved many of the deficiencies present in SNMP in
> :   terms of configuration, it still does not satisfy a number of
> :   requirements needed to manage today's routing information.  First,
> :   the lack of standard data models have hampered the adoption of
> :   NetConf; a significant amount of per-vendor customization is still
> :   needed.  The transport mechanisms that are currently defined (e.g.,
> :   SOAP/BEEP) for NetConf are not those commonly used by modern
> :   applications (e.g., ReST or JSON).
>
> The default to implement transport for NETCONF is SSH. There is
> another transport over TLS. The BEEP and SOAP transports are on their
> way to be declared historic. That said, there is work underway to
> define a JSON / REST API to YANG modelled NETCONF data stores.
>
> http://tools.ietf.org/html/draft-bierman-netconf-yang-api-00
> http://tools.ietf.org/html/draft-lhotka-yang-json-00
>
> :   NetConf primarily facilitates configuration rather than reading of
> :   state or handling asynchronous events.
>
> Not sure what primarily facilitates means but NETCONF does support all
> three functions. NETCONF allows read access to all existing SNMP
> instrumentation of devices.
>
> :   NetConf matches up to the key needed aspects as follows
> :
> :   Multiple Simultaneous Asynchronous Operations:   Not Possible
>
> The NETCONF protocol tags RPC invocations with a message-id that is
> echoed back in RPC replies, allowing asynchronous operations. NETCONF
> also provides global and partial locks to properly deal concurrent
> operations received via multiple channels.
>
> :   Configuration Not Re-Processed:   Not Possible
>
> I simply do not understand the definition of this aspect. You document
> says:
>
> :   Configuration Not Re-Processed:   When an IRS operation is processed,
> :      it does not require that any of the configuration be processed.
> :      I.e., the desired behavior is orthogonal to the static
> :      configuration.
>
> A clarficiation is needed what you mean with this. Anyway, NETCONF
> distinguishes between different configuration data stores. If you want
> to distinguish between changes that affect only the current behaviour
> but not say the next startup behaviour (i.e. the changes do not
> persist), then this is already supported by NETCONF.
>
> Perhaps your concern is that making a change requires to reprocess the
> whole configuration? In that case, this is clearly not required
> anywhere by the NETCONF protocol specification. In fact, the
> edit-config operation allows to send detailed configuration change
> sets to a NETCONF server.
>
> :   Duplex:   Not Possible - strict pull model.
>
> NETCONF does have support for event notifications that are pushed by
> the device. The initiation of the session is client to server for the
> existing transports - but this is mostly a property of the transports.
> Some vendors use non-standard extensions for the SSH transport to
> support device initiated sessions.
>
> :   High-Throughput:   Unlikely - Can depend on configuration size
>
> Well, this is ill defined in the first place. Your definition is:
>
> :   High-Throughput:   At a minimum, the IRS Agent and associated router
> :      should be able to handle hundreds of simple operations per second.
>
> So what is a "simple operation"? I am rather optimistic that it is
> possible to do some "simple operation" in NETCONF at the requested
> speed. To be useful, you really need to be more precise.
>
> :   Responsive:   Unlikely - Can depend on configuration size
>
> Again, this is under specified. Your definition is:
>
> :   Responsive:   It should be possible to complete simple operations
> :      within a sub-second time-scale.
>
> I am sure NETCONF servers easily respond within a sub-second
> time-scale. We have several implementors here at the IETF, I
> am sure they can provide more concrete information about the
> efficiency aspects.
>
> :   Multi-Channel:   Not Possible
>
> NETCONF allows to use multiple SSH or TLS sessions (hence multiple TCP
> sessions) and it provides the needed coordination primitives. In
> addition, the SSH transport can be used to run multiple SSH channels
> multiplexed over a single TCP session.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss