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

Alia Atlas <> Tue, 31 July 2012 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2977121F86EF for <>; Tue, 31 Jul 2012 09:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O2zE-UDPq9zE for <>; Tue, 31 Jul 2012 09:56:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0DEE521F86E8 for <>; Tue, 31 Jul 2012 09:56:05 -0700 (PDT)
Received: by yenq13 with SMTP id q13so6796266yen.31 for <>; Tue, 31 Jul 2012 09:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c2o4pXNZPuoNyVa66iwRCvvAZdbHC9gckpuNK5/yAy8=; b=nDtT9e5iN0CDW7fsXT/f17tIYqTYTGrFmVPUjnHKvkf/mYLw8/EsKtpzuWX7xYNT7H 0cpqNvLFipt31DVsLUSZEMcU2NM0yLlGPVQ4muB+4HM94mt7zSm/3catguE6t/E9ArDC b03cs6MHiSygCCr2FIjsUnYCAp50FYRx5YQzMO9l93ZjgABsIR36jJNmdWMjY4AxgPBV 8piU/9GAKDrDxYoaPT5CpGVnR/pWEwltBVb+2a0PFxyRAnAcY0XU58v6ISwloiZ+Da2g ZkxZIUNShbbaavliQ3VcpiNhwQOAJZKamwXjhBNBsdq7aVM6G/12ydXF6qw0qJe0Di3I qvpw==
MIME-Version: 1.0
Received: by with SMTP id os10mr1304631igc.17.1343753764993; Tue, 31 Jul 2012 09:56:04 -0700 (PDT)
Received: by with HTTP; Tue, 31 Jul 2012 09:56:04 -0700 (PDT)
In-Reply-To: <20120731144930.GA78451@elstar.local>
References: <20120731144930.GA78451@elstar.local>
Date: Tue, 31 Jul 2012 12:56:04 -0400
Message-ID: <>
From: Alia Atlas <>
To: Juergen Schoenwaelder <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2012 16:56:07 -0000

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.


On Tue, Jul 31, 2012 at 10:49 AM, Juergen Schoenwaelder
<>; wrote:
> Hi,
> reading through the problem statement posted at
> 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
> 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:
> :   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.
> :   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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <>
> _______________________________________________
> irs-discuss mailing list