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

Alia Atlas <akatlas@gmail.com> Tue, 31 July 2012 16:56 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2977121F86EF for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 09:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2zE-UDPq9zE for <irs-discuss@ietfa.amsl.com>; Tue, 31 Jul 2012 09:56:06 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE521F86E8 for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 09:56:05 -0700 (PDT)
Received: by yenq13 with SMTP id q13so6796266yen.31 for <irs-discuss@ietf.org>; Tue, 31 Jul 2012 09:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.50.216.202 with SMTP id os10mr1304631igc.17.1343753764993; Tue, 31 Jul 2012 09:56:04 -0700 (PDT)
Received: by 10.50.34.169 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: <CAG4d1rc1h57voSZdx643XfunzZhWVs8+YiSmKMPZHdb4SmDLUg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Content-Type: text/plain; charset=ISO-8859-1
Cc: irs-discuss@ietf.org
Subject: Re: [irs-discuss] IRS problem statement and NETCONF/YANG
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=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.

Alia

On Tue, Jul 31, 2012 at 10:49 AM, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de>; 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss