Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Christian Hopps <chopps@chopps.org> Wed, 01 April 2020 02:00 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8310F3A0FC9 for <lsr@ietfa.amsl.com>; Tue, 31 Mar 2020 19:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kS5Hn51l8gty for <lsr@ietfa.amsl.com>; Tue, 31 Mar 2020 19:00:21 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEB3D3A11D8 for <lsr@ietf.org>; Tue, 31 Mar 2020 18:59:36 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 12B6F60961; Wed, 1 Apr 2020 01:59:35 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <80a8f83c76d447dda48280495b3a80a7@huawei.com>
Date: Tue, 31 Mar 2020 21:59:34 -0400
Cc: Christian Hopps <chopps@chopps.org>, wangyali <wangyali11@huawei.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F0E8437-5D82-4FAC-A061-69E56E1E161D@chopps.org>
References: <1520992FC97B944A9979C2FC1D7DB0F404DB1AD4@dggeml524-mbx.china.huawei.com> <MW3PR11MB4619361A2CA3A402A44914E5C1FE0@MW3PR11MB4619.namprd11.prod.outlook.com> <1520992FC97B944A9979C2FC1D7DB0F404DB2336@dggeml524-mbx.china.huawei.com> <68249E56-5702-4C15-9748-439E43F3EB0E@chopps.org> <1520992FC97B944A9979C2FC1D7DB0F404DEFC14@dggeml524-mbx.china.huawei.com> <A937FECB-2013-403E-89B2-47971514F6CF@chopps.org> <80a8f83c76d447dda48280495b3a80a7@huawei.com>
To: Tianran Zhou <zhoutianran@huawei.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/HDjb6EnqSZV-pYW6CmKV8wP1HP0>
Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 02:00:23 -0000


> On Mar 31, 2020, at 9:28 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> ZTR> Let's not boil the ocean to compare NETCONF/YANG or routing protocol, which is better. But I did not see the modification to routing protocol with some TLVs is a heavy work, or more complex than NETCONF/YANG.  I see both are available and useful.

I'm not sure what you mean by boiling the ocean. I'm saying that YANG is built and intended for querying capabilities and configuring routers. Why isn't that where you are looking first for configuring your monitoring application?

You don't see the major difference between writing a YANG model vs modifying all of the standard IETF routing protocols?

Thanks,
Chris.