Re: [Lsr] When to augment LSR base YANG modules...

tony.li@tony.li Fri, 29 March 2019 08:31 UTC

Return-Path: <tony1athome@gmail.com>
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 C105112051B for <lsr@ietfa.amsl.com>; Fri, 29 Mar 2019 01:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fm1LKQNr9-Z0 for <lsr@ietfa.amsl.com>; Fri, 29 Mar 2019 01:31:50 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D4112046C for <lsr@ietf.org>; Fri, 29 Mar 2019 01:31:47 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id q16so1554531wmj.3 for <lsr@ietf.org>; Fri, 29 Mar 2019 01:31:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jo/VclBp2baJtGtMXgU0C4JJob8JNuBM8EfnVF4683M=; b=FA9dMlXM3OvC8TmmrKh7zeJ5ShNAvVKQZVkp06xIKTCKD32AaTVnYxT0rVgAoX8INM RC50+sGmaI3Fr8srBEF5ro7kKLRw+/OWQs0GThhA/9e1uNgq/jxW6uMKPqmb6PEg1QeW 33DUkw0VBXsD3l/lbgrcqLwrYtMALKkikd0vB6fCv2qMJZfaCE1c/6jz+TphMlxUSzbd EWLhFTlku0MEL7uVpkXHeEW5IzPJRYHKQ02Y4ZHQDvIJGvEcSC3bquxKeCLJWxi3+LZ3 ssCDVJWqp0hADgHT8oeU963yGXQrcBcmeliWUoe9WRQQ1fh0Svp9QNZTdX95UteuT/5F HA8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Jo/VclBp2baJtGtMXgU0C4JJob8JNuBM8EfnVF4683M=; b=afaerNnH5avzuBpkym+2ebHl9oicr3HqomQov/Q9zp+s4qGejnsbJxAsq1XZ8su9rT osM02aHtLxTp+52Ksfmw7V0YSfTCTZftDRH4jNro4SBoydxMt3Vb3D+7CSUQ4ntn+Ucx 7kpzrp5V5CW742RfGleGPsN5/pjiOPPf2hkFSnt59F9YU3OZoeBXqVh7s8wFsIPViR02 daf7ROrbUe45tHJpXnL7FeRk8Ao2+HjPQ40Sm2KV3o+OK2rdNo7y6E+s3MeIv+JT+oaJ nZDhIEIXnet2mbWzjmdghOtliXGZTTTouoM8M9MhrVhHe786TjBRmTBTicgnbiEGuajw aKsQ==
X-Gm-Message-State: APjAAAWq9PNvAIHIRqTataUT0bA+NWNi+G37Qnzvugm60irVwuetCX1s bbsw+qYV+mY/10pqazhmWBbKbfKTiEU=
X-Google-Smtp-Source: APXvYqyDRCjfeEGaFURihSnwt18qUaBFQdw/Wyny/MgXu6ES2YwTLqu2ig2m/t9O+eTKnQQoTJVXaQ==
X-Received: by 2002:a1c:7a03:: with SMTP id v3mr2544806wmc.58.1553848305776; Fri, 29 Mar 2019 01:31:45 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:f837:b7ed:f2ac:3602? ([2001:67c:370:128:f837:b7ed:f2ac:3602]) by smtp.gmail.com with ESMTPSA id n11sm1639661wrt.63.2019.03.29.01.31.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 01:31:45 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: tony.li@tony.li
In-Reply-To: <sa6wokiayd9.fsf@chopps.org>
Date: Fri, 29 Mar 2019 09:31:36 +0100
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li>
References: <sa6wokiayd9.fsf@chopps.org>
To: Christian Hopps <chopps@chopps.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/EkSWNIR8sq5ZLW0MXf4pfFeV1ho>
Subject: Re: [Lsr] When to augment LSR base YANG modules...
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: Fri, 29 Mar 2019 08:32:01 -0000

Chris,

One concern is simply one of scale: doing this will increase the size of the document.  At what point do things become sufficiently awkward that we want to have a separate, concurrent document.

In other words, if the requirement is for concurrent delivery, is co-location really a requirement?

Regards,
Tony


> On Mar 29, 2019, at 9:17 AM, Christian Hopps <chopps@chopps.org> wrote:
> 
> 
> The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data, I brought up the issue of when and how the base modules should be augmented to add new TLV types to the model, suggesting it be done inline and with the RFC that adds the new feature/functionality to the protocol.
> 
> I'll go farther here and say this should apply to all the YANG required for management of the new feature, and it should all be added inline with the feature (i.e., in the same draft). In other words new features/functionality should include the YANG augment required to manage said features/functionality.
> 
> This has been suggested/tried previously with SNMP with varying (low) levels of success. The difference here is 1) YANG additions (a new module perhaps just augmenting the base) is easy, whereas SNMP wasn't. Additionally, operators weren't using SNMP to fully manage functionality (e.g., not doing configuration) so a requirement for extra work was harder to justify. Operators *do* want to fully manage their networks/servers with YANG though.
> 
> The argument against this during the meeting was that it would create many small modules. I don't find this compelling (i.e., "so"? :)
> 
> Assume I'm an operator -- the actual consumer of this management stuff:
> 
> - If I'm going to use this new feature X, I need to be able to manage it. So I need it YANG for it. Not only do I need any new TLV data in the operational state, but I need the configuration and any other operational state right along with it. Otherwise each vendor has to add new YANG to their vendor modules, or the feature is useless to me. I can't use something if I can't turn it on.
> 
> - I don't care about having many smaller modules that augment the base module -- at all. Quite the opposite actually, when new functionality is accompanied by it's own module it provides me a simple way to see if that functionality is present as the module will be present in the YANG capabilities announced by the device.
> 
> I'd be interested in hearing reasons we (as a WG) shouldn't just expect a YANG module (even if it's small) to be included with drafts that add new functionality.
> 
> Thanks,
> Chris.
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr