Re: [OPSAWG] Service Assurance for Intent-based Networking Architecture and YANG modules

Vladimir Vassilev <vladimir@lightside-instruments.com> Mon, 18 November 2019 03:42 UTC

Return-Path: <vladimir@lightside-instruments.com>
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 7F59C120096 for <opsawg@ietfa.amsl.com>; Sun, 17 Nov 2019 19:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.434
X-Spam-Level: *
X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.onmicrosoft.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 xYWkla3sCzZD for <opsawg@ietfa.amsl.com>; Sun, 17 Nov 2019 19:42:04 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150041.outbound.protection.outlook.com [40.107.15.41]) (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 739D812004C for <opsawg@ietf.org>; Sun, 17 Nov 2019 19:42:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SK7KMOdTUUehEu5vRWceNvKRy0fWgFMcNKiivwFpng1AppRWZkZJD7k+ap9WKOQiecH64egxGe0XYE2i4eQI1jIfTXOAc99uG5HklWf85KyciJbQrR+3b86fVL6ODejOCTbaRN3hT2uzWOKsxK9D/NA/7iMfqRbOMWOhwBJg2BBbIwXx50DBKBpzj/w5AQ4LApltsctXSUcqJevjjDlLdxIA5q59uWnyQnpCtrZUDImOymSSpvvBvcYhnhMOF9zKW8fyCvN/R/wkOyQwRypMYWd+3SPf6uvtGXWMFtab+2jjSdeyfjmLnbjqOVQ7cgoKRYly8CDqzEYCZozSzOkeAQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O2nT0qr0OVCfEnOxDuxbIeiObAouC3I6f+yHvSwAyp4=; b=Wh6+T+msZieXlzh137tCJDBMt4eIE+HH47GLG3gjCoGbrsjwvn9TKKQAZv3QN6VUa1tnUoNG58jqeiN7/jOWuVLCKEntCpipRuaUvvJoVuluMFxLVywMLJtwdAB8fXU9AplMyMXojZyPTo0GJ1vH+AfSpRv4o5WU3diII89Gk4hXPRMbalZyi6HmMWSqLjWHQJqMwfa8qu50rCFp81msp9JVJx7DfaTyxsAxIWG4CGWHJbHLWloC42xAr3Ic9TxN1kIu//zgIGdT4WQlQr1CJO6DqaQFOHVvJz6R3jQvxYo2zN1nCemedqlsn2cUjxcRIZ5zUiGZcBP34kh1Nw7xcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O2nT0qr0OVCfEnOxDuxbIeiObAouC3I6f+yHvSwAyp4=; b=j3sidfjqeJBhi7bjdK6IEg2kMoCo4gz/H0NIoUYGCLMv+7IcTOigaO0CKmsRFj2zR1ljL9AsLBy7zvzmRjmXNAUhMux7X0qL8KFKr2HpR9+nfdWhRGoihcu12/nppzIffNOfaTdZX+MP6+IZ+NRZAlLpX11XcYcz7jTifo4FyDk=
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com (20.179.33.207) by AM0PR08MB4530.eurprd08.prod.outlook.com (20.179.33.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 03:42:01 +0000
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641]) by AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641%3]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 03:42:01 +0000
From: Vladimir Vassilev <vladimir@lightside-instruments.com>
To: Benoit Claise <bclaise@cisco.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Service Assurance for Intent-based Networking Architecture and YANG modules
Thread-Index: AQHVncIitDrzCE9neU6qtDmYvhQ+4Q==
Date: Mon, 18 Nov 2019 03:42:00 +0000
Message-ID: <444c9317-97a4-35be-a037-9ee27039bb01@lightside-instruments.com>
References: <d0a4cbc9-3468-045b-69fe-02595dac76a9@cisco.com> <22b32a1a-8faf-7a85-fab5-7f164c581766@cisco.com>
In-Reply-To: <22b32a1a-8faf-7a85-fab5-7f164c581766@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: SG2PR01CA0119.apcprd01.prod.exchangelabs.com (2603:1096:4:40::23) To AM0PR08MB4369.eurprd08.prod.outlook.com (2603:10a6:208:13e::15)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=vladimir@lightside-instruments.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [118.200.4.77]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: defe8349-3bbf-44ef-e71b-08d76bd9451e
x-ms-traffictypediagnostic: AM0PR08MB4530:
x-microsoft-antispam-prvs: <AM0PR08MB453008AF0D0FE154AF7C888F9B4D0@AM0PR08MB4530.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(39830400003)(396003)(199004)(189003)(25786009)(31686004)(76176011)(6486002)(8676002)(6436002)(81156014)(2501003)(966005)(52116002)(99286004)(5660300002)(386003)(316002)(4326008)(66476007)(66066001)(66446008)(6116002)(66556008)(14454004)(3846002)(66946007)(26005)(6506007)(102836004)(8936002)(110136005)(186003)(86362001)(7736002)(6246003)(508600001)(446003)(229853002)(31696002)(81166006)(2616005)(11346002)(64756008)(305945005)(6512007)(486006)(6306002)(2906002)(476003)(256004)(36756003)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4530; H:AM0PR08MB4369.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: lightside-instruments.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Jp4FGKNUpQp4PzAGy8WZIucs/wohpPfAEj/KqWoeWX4s81YRx+BMRQ+3emtA5ya+e95InvhLrfqznpWkZBIWsrCYdf9V7yBLQWHhHtqCmZacVGUUAILJ89nf2mFnLnFU1MeS6nHOh6mJ7/VtYHnGgC3dl1bnSXF+rhopv87Hbf0E+lOIJDsNvWEaDHEidRUr2wnZJgD4PiImIScTeNt0ZNjlPvrH4mz5aitCiha8LLtQifYLU2Fpdaiuv7aK35UqXQFYPFxOaLKXKH/2zB/iX6NMftqpyrK6RkGg+htQz8e2715xMugFBduJlR/XtiZiDJSBPA4im4cuz8qXhIGfV8vrZjSIZjfm4ZZoczF0c1p/8U1oWTQPeILW30T0AUFDagpCU8I7n37pyVA1Vfq0MMKNubkpZA3FmcE4EmNOZjO1CPmw6t/mb/qEXI9myuSf
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F2A52567CA36BC4F8E84A47D3867337E@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: lightside-instruments.com
X-MS-Exchange-CrossTenant-Network-Message-Id: defe8349-3bbf-44ef-e71b-08d76bd9451e
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 03:42:00.9851 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c0326317-f373-4461-a96f-7946e0abb603
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xORVH1X3JcUpYHgOQnB1cIYFhNhgfH9tQ3foA2YTOHnxyP7WY3gtKfQ56IuHmXONxDrYu0ewjt1i8vuxNw0xbRAGzeuvkI3slIPuBo0o28S1tg+TWv+9Un5VrPhwY7ku
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4530
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/79-icITU9aTQHZgcXtWp89jEtGk>
Subject: Re: [OPSAWG] Service Assurance for Intent-based Networking Architecture and YANG modules
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: Mon, 18 Nov 2019 03:42:07 -0000

Hi Benoit,

I read the drafts. In the context of rfc8199 the 
ietf-service-assurance.yang module seems to be designed as Network 
Service YANG Module. However the concept of a service is general enough 
to cross into the domain of Network Element YANG Modules. There is a 
similar need for service management on the network element level. 
systemd for example used as default service manager on Debian systems 
among others aims to provide uniform interface to management of services 
on network elements and its data model can be mapped to a general YANG 
module with augmentation specific to the network element context.

Do you think the idea of extending the scope with a very abstract module 
(with top level container /ietf-services:services) to both domains of 
Network Service and Network Element modules is relevant for this draft?

Vladimir

On 17/11/2019 09.31, Benoit Claise wrote:
>
> Dear all,
>
> We updated the drafts, based on the feedback received so far.
> https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-architecture/, 
> version 1
> https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-yang/, 
> version 2
>
> Regards, Benoit
>
>> Dear all,
>>
>> Let me introduce these two new drafts:
>>     - draft-claise-opsawg-service-assurance-architecture-00
>>     - draft-claise-opsawg-service-assurance-yang-01
>>
>> The first document describes the architecture for Service Assurance 
>> for Intent-based Networking (SAIN). This architecture aims at 
>> assuring that service instances are correctly running. As services 
>> rely on multiple sub-services by the underlying network devices, 
>> getting the assurance of a healthy service is only possible with a 
>> holistic view of network devices. This architecture not only helps to 
>> correlate the service degradation with the network root cause but 
>> also the impacted services impacted when a network component fails or 
>> degrades.
>>
>> This second document complements the architecture by providing open 
>> interfaces between components, meaning YANG modules.
>>
>> Feel free to read, review, and provide your feedback.
>>
>> Regards, Jean & Benoit
>>