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

<bruno.decraene@orange.com> Tue, 16 April 2019 09:11 UTC

Return-Path: <bruno.decraene@orange.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 8B8EC120103 for <lsr@ietfa.amsl.com>; Tue, 16 Apr 2019 02:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SoXENlqltyrb for <lsr@ietfa.amsl.com>; Tue, 16 Apr 2019 02:11:01 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE27212009C for <lsr@ietf.org>; Tue, 16 Apr 2019 02:11:00 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 44k0366Vwvz10GX; Tue, 16 Apr 2019 11:10:58 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 44k0364lVxzDq7F; Tue, 16 Apr 2019 11:10:58 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 16 Apr 2019 11:10:54 +0200
From: bruno.decraene@orange.com
To: LITKOWSKI Stephane OBS/OINIS <stephane.litkowski@orange.com>, Christian Hopps <chopps@chopps.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] When to augment LSR base YANG modules...
Thread-Index: AQHU5gfWFrH1aZ8KFUyJeKNGsFiT8qY+g01wgAASurA=
Date: Tue, 16 Apr 2019 09:10:53 +0000
Message-ID: <1639_1555405858_5CB59C22_1639_269_1_d84a822b-0e60-4730-aaeb-d23008dad637@OPEXCAUBM42.corporate.adroot.infra.ftgroup>
References: <sa6wokiayd9.fsf@chopps.org> <15693_1555401096_5CB58987_15693_333_25_9E32478DFA9976438E7A22F69B08FF924C1ED7D2@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <15693_1555401096_5CB58987_15693_333_25_9E32478DFA9976438E7A22F69B08FF924C1ED7D2@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/meDuJFudQrEc_D8afOsszACmJcA>
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: Tue, 16 Apr 2019 09:11:03 -0000

Hi,

I don't know anything about yang (module) so everything looks easy from 10000 feet. Yet, my 2 cents.

> I think the main requirement (speaking as an operator) is to get the YANG part (ops+cfg) standardized at the same time.

+1 to Stéphane & Christian

Whether this is done in the same document or via a normative reference to another document is less of an issue, but I think that many IGP extensions typically require a very small extension to the yang model hence could be done in the same document.

> While YANG is easy to write, it could still scare pure IGP guys that are focused on protocol encodings

Probably the first draft could be "hard", but given an existing model/example, I would assume that most IGP extensions would be reasonably similar in term or yang additions.

 > I'm a bit worried about having too many tiny modules
[...]
> we have few (or even no) experience today on managing modules revisions

I think that we need to start walking to gain experience, and then define yang/whatever extensions to improve on either/both of those problems. On the first point, possibly a meta model could reference a set of tiny models, but regardless of the details, I trust yang people to find a solution.
In all cases, I don't think those problems would disappear by taking another path. (except deferring yang extensions for... ever). I don't think that delaying yang revisions every N years would be easier as the authors of the IGP extensions are probably the best persons to define the cfg/operational objects needed for their extensions.

In all cases, thank you Christian for raising the point.

Regards,
--Bruno

-----Original Message-----
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Tuesday, April 16, 2019 9:52 AM
To: Christian Hopps; lsr@ietf.org
Subject: Re: [Lsr] When to augment LSR base YANG modules...

Hi,

On one hand, I'm a bit worried about having too many tiny modules (finding the right module name to get the right feature, managing prefixes...). The good thing I see is that we could mandate in each LSR draft the YANG management part so both are published at the same time. While YANG is easy to write, it could still scare pure IGP guys that are focused on protocol encodings -> this implies that people may need to rely on people with YANG skills to write the management section.

On the other hand, we have few (or even no) experience today on managing modules revisions, do we also foresee some level of complexity ? The issue I see if we update the main YANG base module is that the timing may be different from the protocol encoding spec. Also, are we ready to publish a revision for each tiny feature ?(why not but who takes the pen ? Speaking as editor of ISIS yang module, I'm not really ready to have the pen to modify it for the rest of my life ;)

I think the main requirement (speaking as an operator) is to get the YANG part (ops+cfg) standardized at the same time. 


Brgds,


-----Original Message-----
From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Christian Hopps
Sent: Friday, March 29, 2019 09:17
To: lsr@ietf.org
Cc: chopps@chopps.org
Subject: [Lsr] When to augment LSR base YANG modules...


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.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.