Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
Adrian Farrel <adrian@olddog.co.uk> Thu, 28 May 2020 17:14 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB323A0786; Thu, 28 May 2020 10:14:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HolV3pxLD5Ac; Thu, 28 May 2020 10:14:35 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 532D63A07FC; Thu, 28 May 2020 10:14:35 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04SHEWtm032449; Thu, 28 May 2020 18:14:32 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4357E22042; Thu, 28 May 2020 18:14:32 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 381192203A; Thu, 28 May 2020 18:14:32 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.26.18]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 04SHEUEI026468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2020 18:14:31 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'tom petch' <ietfc@btconnect.com>, "'Joe Clarke (jclarke)'" <jclarke=40cisco.com@dmarc.ietf.org>, 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>
Cc: 'opsawg' <opsawg@ietf.org>
References: <AM6PR06MB565337CF2FB735B53D6B52F7FDB70@AM6PR06MB5653.eurprd06.prod.outlook.com>, <465E792F-A57A-4AE1-AA0E-E791F7422D74@cisco.com> <DBAPR07MB70168C271FFA086694263208A0B00@DBAPR07MB7016.eurprd07.prod.outlook.com>, <082901d634f4$071ca270$1555e750$@olddog.co.uk> <DBAPR07MB701619C7BCAE0146BFFA8618A08E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB701619C7BCAE0146BFFA8618A08E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Date: Thu, 28 May 2020 18:14:30 +0100
Organization: Old Dog Consulting
Message-ID: <08f801d63513$7435c520$5ca14f60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQCwpi9GXLazLV8vDSmdHS8jTf+WIwIakqg5AsN97f0Bnx+RuAJKpxNgqsKQdIA=
Content-Language: en-gb
X-Originating-IP: 84.93.26.18
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25446.007
X-TM-AS-Result: No--12.066-10.0-31-10
X-imss-scan-details: No--12.066-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25446.007
X-TMASE-Result: 10--12.065800-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbPVY7U3NX8JgjHhXj1NLbjBGM2uNXRqsUntc SBXe4RfNLCZ9BMQnIAzwj4rmuuCW0KUbmoH82o2LRow8EUpfIBT348e2CE/wYiNGK7UC7ElM1BQ t3e1Ue9ef8/YPaAgxt9S0/VWYjmrVz9rcswokmUtM0MpnLn+G9IyFtOxfKxTflpIVTIzuzyTNOr LVpht+CGXZRtAS18INjKWFjszMoOo5k+DXbT4GgZVRzPxemJL0cylhNIofIQgEbIN19XhAM7/bN gL2ReUKeMUurcvXLsros7IkKKuHv1DV9sDqOQY/8irf7wNB3SgX2zxRNhh61bEtLGRAe3PG88Pc KqOpBmbTwn2wXZU5/qdhC2OTf6ksnkog8bUDkQ1crmR4Jr5uaCfDg9CC16hQS8QrgUwl2ioaCsK 0kBES8W+YEnKBAth8TpmbQLBEmRTzm/7LINKYQC9cBNSlgvYqrXkuON8pnlFnTVyFJgv5K7kZ5i ts6AuCCfm0n2SoUiKKrvMV4jkF7Jp0IVNeJxIBtGM0cBDUM42lAfiiC1VA/YDpStszePepck8Uj Ff3XBKqIs8sVzoaYOi14QXG1sdFjISMJ2rDx/vXoVX7FjNhBUIWf+N2wEvZmCzV/tUW/EwerWfb PfVl6fA4ZrCwHjTVmiBaFXD928EYv4PCknmy9fWjzI5GHHH5dNmQukSciLjb4C+yr/MvQV5XKvM z90rKketQXklsD7s02Mi1c0/N1FjGUjVa6enrC/xRU+mwjW/KhROoEXUTm1hmwlJEPq7xseDGNu 6ZSS99WIDmpAlYRC8+k/GsEhBIyeDVadfSfUieAiCmPx4NwGNn8XPiALIbsQhKhYApN4wMyrfP9 j+C1d934/rDAK3zhG2qikEpQGVrq2bvKb9HxFAAMhLQ3b0asQdjQf1S/6Zy/j2w3AQRzCYk344x ru8o
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/E8oYDLwGwnSxfZ7HGSurcUU8bp4>
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 17:14:39 -0000
OK, thanks, that's clear. I *think* (I was on the call where this was discussed) that it was exactly the worry about importing a whole module that led to the suggestion of having a separate module just for common types. As I understand it, there was a desire to have a common type used in several modules, but some implementers felt that this would lead them to have to import the whole module (not just the type). The idea of a separate module certainly has some risks associated: not capturing the right things; including too much "stuff"; forcing commonality where none exists. There is, as you suggest, an alternative that each module goes its own way and there is no sharing. I *think* we received a strong steer that sharing is a good idea. Best, Adrian -----Original Message----- From: tom petch <ietfc@btconnect.com> Sent: 28 May 2020 17:26 To: 'Joe Clarke (jclarke)' <jclarke=40cisco.com@dmarc.ietf.org>; 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>; adrian@olddog.co.uk Cc: 'opsawg' <opsawg@ietf.org> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions From: Adrian Farrel <adrian@olddog.co.uk> Sent: 28 May 2020 14:29 Hey Tom, Is there a typo in your email? You said... > So carving out the current types (etc) will likely lead to a bad > outcome; it is a question of looking carefully across the range > of documents to see what is, or is likely to be common. I wondered whether you intended a "not" in there somewhere. <tp> Adrian, no, no 'not' was intended. The danger is taking e.g. the 50 or so pages of identity, typedef, grouping in L2NM and assuming that they form a good starting point or, worse still, making a logical OR of the four documents under consideration and to create a monster document and assuming that that is a good basis. Critical assessment is what is needed IMHO. Sometimes it is better to create your own version of vpn-id or ODUC than import a hundred pages of someone else's in order to get them. Tom Petch If you wrote what you intended, could you explain a little further what the danger is? Best, Adrian -----Original Message----- From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of tom petch Sent: 26 May 2020 17:05 To: Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; Oscar González de Dios <oscar.gonzalezdedios@telefonica.com> Cc: opsawg <opsawg@ietf.org> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org> Sent: 21 May 2020 15:43 2. L3NM Revision of the three main issues: Implementation Report by Cisco. It has two main issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110) - Common module to have all the L3NM specific requirements. Type-like module. [Anton]: It makes implementation simpler. Does not generate unnecessary dependencies [Adrian]: It depends on if we need module for specific types, to avoid unnecessary imports. Also don't you only need to import types, not the entire module? [Qin]: With L3SM we did not take an augmentation approach. If there are common types defined in both models, then we may need to find the common components. We should decouple of L3SM. [Sriram]: Prefer to have a separate type-file for the specific parameters. [Oscar]: Define a common type-file for the service models. [Qin]: Is it possible to manage it as an independent draft? [Oscar in github issues]: After the discussions, it seems reasonable to have a separate Yang module to contain the types. The suggestion is to write the module to cover the four service models (client service models, l3sm, l2sm and Network service models, l2nm, l3nm). It seems reasonable to include this module in l3nm draft instead of creating a new one to avoid dependencies. Samier, Dan and Anton to collaborate for a first version of the split As chair, I want to call this out since it sounds like the authors made a decision here, and I want to make sure the whole WG has a chance to weigh in. In reading these minutes and issue #110, I can see the value of a types module to avoid what may be confusing imports, but I want to know if anyone on the WG has a different opinion. <tp> Joe The four documents are not spelled out but referred to in shorthand and while I think I know which are intended, that IMHO needs spelling out. In principle, a common types is a no-brainer provided it is done early enough - before anything becomes an RFC! - and with limited enough scope. NETMOD got it right but did have decades of SMI experience to go on, RTGWG got it right, with TEAS it is less clear while layer0-types has changed much over its short life - is it right now? May be. So carving out the current types (etc) will likely lead to a bad outcome; it is a question of looking carefully across the range of documents to see what is, or is likely to be common. The higher up the stack you go the more likely items are to be common but equally the more likely it is that someone has been there already. And if you look at existing types modules, it took a while for the penny to drop but they end up as separate I-D, better still with a different author to the importing I-D; a no brainer really. Tom Petch Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg =
- [OPSAWG] Minutes of L3NM/L2NM module discussions Oscar González de Dios
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Joe Clarke (jclarke)
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Oscar González de Dios
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Roque Gagliano (rogaglia)
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… tom petch
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Oscar González de Dios
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Adrian Farrel
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… tom petch
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Adrian Farrel
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Italo Busi
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… tom petch
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Adrian Farrel
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Italo Busi
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Qin Wu
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Roque Gagliano (rogaglia)
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Qin Wu
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Roque Gagliano (rogaglia)
- Re: [OPSAWG] Minutes of L3NM/L2NM module discussi… Oscar González de Dios