Re: [Rtg-yang-coord] Operational State Modeling
Nadeau Thomas <tnadeau@lucidvision.com> Fri, 15 May 2015 17:11 UTC
Return-Path: <tnadeau@lucidvision.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 841001A8773
for <rtg-yang-coord@ietfa.amsl.com>; Fri, 15 May 2015 10:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xhpW7psOm9Ym for <rtg-yang-coord@ietfa.amsl.com>;
Fri, 15 May 2015 10:11:37 -0700 (PDT)
Received: from lucidvision.com (lucidab1.miniserver.com [64.71.170.115])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id E5D201A8768
for <Rtg-yang-coord@ietf.org>; Fri, 15 May 2015 10:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com;
s=default; t=1431709849;
bh=KoXzyiVVl/za8VfwKO+kP+zjabBKak8Pw654vYfpZkU=;
h=Subject:From:In-Reply-To:Date:Cc:References:To;
b=MFFGVv39fNQk/rPI6/WCT/nV0DhgtGtcAvXTHzRlPzRPROyVll//y0hJCzVeIIy8o
dr01CygmYw9rHmNqpeL2aVxHd7TqFKvMvatKhJgcuWWTLWW/nezBbzljJyFLL2qTET
4ONJYA8JAr0//LYY2xUUADnX+Lqf9QPTWP2lF4i4=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS))
x-ip-name=50.255.148.181;
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Nadeau Thomas <tnadeau@lucidvision.com>
In-Reply-To: <CABCOCHQYr=-MV=5Mwsj1puDYU24pEnpmF-EcdYb-w-dj0=qTVw@mail.gmail.com>
Date: Fri, 15 May 2015 13:11:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2C3C9E7-3D50-4866-A359-CA08CB23922E@lucidvision.com>
References: <D177E7E1.1AC4C%acee@cisco.com>
<CAJK7ZqLp4_dOVMcSMXP3juZHHeQJ6iLGkryJ8t6gs2Mcn=Ez5Q@mail.gmail.com>
<20150513103509.GA59689@elstar.local>
<D481ED34-84C4-455D-8CE5-36D01A5264CC@lucidvision.com>
<20150515085228.GA4024@elstar.local>
<0EDEDDB6-40EA-47AF-AA5A-E7212445CCF8@lucidvision.com>
<CABCOCHQYr=-MV=5Mwsj1puDYU24pEnpmF-EcdYb-w-dj0=qTVw@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.2098)
X-Authenticated-User: tnadeau@lucidvision.com
X-Info: aspam skipped due to (g_smite_skip_relay)
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=23 Stars=0 Good=0 Friend=0 Surbl=0
Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 0, in=31, out=0,
spam=0 Known=true ip=50.255.148.181
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/MsdfQtCW8ty1SzIQgVJbbtNfsgE>
Cc: "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>,
"Acee Lindem \(acee\)" <acee@cisco.com>, Xufeng Liu <xufeng.liu@ericsson.com>,
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>,
Anees Shaikh <aashaikh@google.com>
Subject: Re: [Rtg-yang-coord] Operational State Modeling
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG
models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>,
<mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>,
<mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2015 17:11:39 -0000
> On May 15, 2015:12:28 PM, at 12:28 PM, Andy Bierman <andy@yumaworks.com> wrote: > > On Fri, May 15, 2015 at 9:14 AM, Nadeau Thomas <tnadeau@lucidvision.com> wrote: >> >> I don’t think the open config guys are asking for refactoring for purely aesthetic reasons. These guys operate some of the world’s largest networks with tens of thousands of devices, so I’d hope that their asking to move things around is in order to make interacting with those things at that scale better. >> > > > I think Juergen and I and others are pointing out that it > would be better to solve this problem by adding an > operation to NETCONF. RESTCONF already has the > ability to retrieve just "content=nonconfig”. This is reasonable option/solution. What do the open config folks think? > Replicating config as operational state in all the data models > is not a good idea. Using arbitrary NP containers called > "config" and "state" (instead of the YANG config-stmt) > is not a good idea. I think you are saying that, but the others are clearly not, so we need to listen to their reasons before discounting them as less efficient. Remember that the operators are users not implementing these models so they need to understand if the boxes/servers they are using can do this and what the costs are. If after they weigh the relative costs, they feel the return on that investment in say RAM on those servers is ok, then we need to think carefully about why we would not want to support that. Remember, even though you as a server/compiler vendor might think its not a great idea, they might be willing to pay the price for say memory, to store the operational state. —Tom > > >> —Tom > > Andy > >> >> >>> On May 15, 2015:4:52 AM, at 4:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >>> >>> On Wed, May 13, 2015 at 09:13:37AM -0400, Thomas D. Nadeau wrote: >>>> >>>> Speaking as an individual, while what Juergen says is true, that does not mean that existing models can never be refactored. >>>> >>> >>> Refactoring for the sake of 'it looks nicer' (for some definition of >>> nice) likely does not meet the bar. We are talking about APIs here >>> with multiple independent implementations and applications sitting on >>> top of these APIs. >>> >>> /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/> >>> >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
- [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling Russ White
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Acee Lindem (acee)
- Re: [Rtg-yang-coord] Operational State Modeling Anees Shaikh
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Thomas D. Nadeau
- Re: [Rtg-yang-coord] Operational State Modeling Andy Bierman
- Re: [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling Xufeng Liu
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf
- Re: [Rtg-yang-coord] Operational State Modeling Anees Shaikh
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Christian Hopps
- Re: [Rtg-yang-coord] Operational State Modeling Ladislav Lhotka
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Acee Lindem (acee)
- Re: [Rtg-yang-coord] Operational State Modeling Nadeau Thomas
- Re: [Rtg-yang-coord] Operational State Modeling Andy Bierman
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf
- Re: [Rtg-yang-coord] Operational State Modeling Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Operational State Modeling Nadeau Thomas
- Re: [Rtg-yang-coord] Operational State Modeling aldrin ietf