Re: Blog: YANG Really Takes Off in the Industry

Dean Bogdanovic <deanb@juniper.net> Tue, 02 December 2014 02:54 UTC

Return-Path: <deanb@juniper.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530ED1A000E for <ietf@ietfa.amsl.com>; Mon, 1 Dec 2014 18:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 50EPWDgWAD2W for <ietf@ietfa.amsl.com>; Mon, 1 Dec 2014 18:54:53 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2795C1A00A6 for <ietf@ietf.org>; Mon, 1 Dec 2014 18:54:53 -0800 (PST)
Received: from BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) by BN1PR05MB092.namprd05.prod.outlook.com (10.255.199.25) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 02:54:30 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 02:54:29 +0000
Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.145]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.84]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 02:54:28 +0000
From: Dean Bogdanovic <deanb@juniper.net>
To: Tim Wicinski <tjw.ietf@gmail.com>
Subject: Re: Blog: YANG Really Takes Off in the Industry
Thread-Topic: Blog: YANG Really Takes Off in the Industry
Thread-Index: AQHQDXWjTnozmsgPSE+qdeYcA4j0zJx7beOAgAABfACAAAZTAIAAAQgAgAAk6wA=
Date: Tue, 02 Dec 2014 02:54:28 +0000
Message-ID: <0BFD0B22-EC45-473F-8E7A-7FB608B60E6F@juniper.net>
References: <54770BA5.5060603@cisco.com> <809EFD2B-A845-46B7-A394-A9C9E5393CD5@piuha.net> <547874D6.1090001@cisco.com> <7890AE32-F7A9-4C32-9C3D-8251E70B1F29@lucidvision.com> <m2sigyhpxc.wl%randy@psg.com> <8BBBDF7F-00A0-44BD-AA64-DA7044D35012@lucidvision.com> <C51AC247-C16D-4452-874E-0D97BDB009EB@juniper.net> <547D0AEA.4020309@gmail.com>
In-Reply-To: <547D0AEA.4020309@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.1510)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423;
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(479174003)(377454003)(24454002)(189002)(51704005)(101416001)(92566001)(106116001)(105586002)(92726001)(50986999)(76176999)(93886004)(66066001)(95666004)(99286002)(88136002)(104166001)(87286001)(87936001)(20776003)(2656002)(106356001)(36756003)(83716003)(40100003)(89996001)(33656002)(46102003)(19580395003)(19580405001)(99396003)(77096004)(107046002)(120916001)(50226001)(122556002)(4396001)(31966008)(57306001)(110136001)(77156002)(21056001)(93916002)(62966003)(64706001)(97736003)(86362001)(68736005)(82746002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <D00009226366CF41AA31759E116A0B45@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB092;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/2lMwgsd464KUPFl186Ef0LpNmt0
Cc: IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 02:54:55 -0000

On Dec 1, 2014, at 7:42 PM, Tim Wicinski <tjw.ietf@gmail.com>
 wrote:

> 
> 
> On 12/1/14 7:38 PM, Dean Bogdanovic wrote:
>> 
>> On Dec 1, 2014, at 7:15 PM, "Thomas D. Nadeau" <tnadeau@lucidvision.com>
>>  wrote:
>> 
>>> 
>>>> On Dec 1, 2014:7:10 PM, at 7:10 PM, Randy Bush <randy@psg.com> wrote:
>>>> 
>>>>> the “MIB Doctor” model we are using is not going to scale out to the
>>>>> numbers of Yang models that are in need of advice or review, nor will
>>>>> be scale in terms of progressing models through the IETF’s RFC
>>>>> process.  The fact is that we simply do not have enough Yang Doctors
>>>>> to cover all of the models in question, despite our best efforts.
>>>> 
>>>> is this a sign that we do not have enough medical care or that we are
>>>> unleashing an unarchitected epidemic of overly device-specific snmp with
>>>> the syntax changed?
>>> 
>>> 	Speaking from my own personal opinion, it seems that operators are finding this stuff useful and are
>>> demanding that people build products with it.
>> 
>> I agree with you on this one. See it from multiple operators in Americas and EMEA (haven't seen in APAC personally). Operators have been translating their service configurations into YANG and are looking how to adapt their service models to proprietary operator models. For them, having standard config models, would make it much more easier to translate their service models and let the vendors worry about translation from standard to proprietary models.
>> 
>> Dean
>> 
>> 
> 
> 
> What is the IETF when many of the newer networking companies do not find YANG worth investing in? 

As far I know Arista has their own proprietary schema language (as many other companies have it too), that describes their data model. Arista uses that schema to generate binding to be able to access all objects generated from the data model from python.
If they use their proprietary or use IETF YANG to describe the data model is a decision companies have to make by them self. There is a benefit to have a standardized language that everyone is able to understand.

>  I'm thinking of Arista as a good example of a networking vendor that (i've been told) feels supporting YANG makes them less agile than their APIs.

this is one part I don't understand. Why adding another language would make them less agile?

Dean
> 
> tim