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

Benoit Claise <bclaise@cisco.com> Wed, 27 November 2019 13:47 UTC

Return-Path: <bclaise@cisco.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 F32F01200A4 for <opsawg@ietfa.amsl.com>; Wed, 27 Nov 2019 05:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZYuchz6h8Shr for <opsawg@ietfa.amsl.com>; Wed, 27 Nov 2019 05:47:09 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDFC120122 for <opsawg@ietf.org>; Wed, 27 Nov 2019 05:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8247; q=dns/txt; s=iport; t=1574862429; x=1576072029; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=a1UinT0OnVkpx3ZKQx/UFKfzkntpqq1QbcJtewHmQ9s=; b=ThQKu2NJjjEj4dQD3PHJCTLMwwKv21jjbFvTRHTIgK/D6HM4e0RX5v3V Y8e/Yh+kEeP6EbqbA/il6E6uGYjuSB2GPEBzRtH4UGBpZXmsOE9WkLKDj +h4WNfQgBpIT4Bl0EYD7PyzQ4VUUY+CG+Q9pqF/q3tYDRro50JyWEu9Cx 0=;
X-IronPort-AV: E=Sophos; i="5.69,135,1571702400"; d="scan'208,217"; a="19631351"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2019 13:47:07 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) (authenticated bits=0) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPSA id xARDkx0f015970 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Nov 2019 13:47:07 GMT
To: Vladimir Vassilev <vladimir@lightside-instruments.com>, "opsawg@ietf.org" <opsawg@ietf.org>
References: <d0a4cbc9-3468-045b-69fe-02595dac76a9@cisco.com> <22b32a1a-8faf-7a85-fab5-7f164c581766@cisco.com> <444c9317-97a4-35be-a037-9ee27039bb01@lightside-instruments.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <6d77785f-0225-87c9-854c-d4f2053906ae@cisco.com>
Date: Wed, 27 Nov 2019 14:46:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <444c9317-97a4-35be-a037-9ee27039bb01@lightside-instruments.com>
Content-Type: multipart/alternative; boundary="------------B8FEA01C01ACDD36AEF51B68"
Content-Language: en-US
X-Authenticated-User: bclaise
X-Outbound-SMTP-Client: 10.55.221.36, ams-bclaise-nitro3.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/AM_M00dqE8PdgNj4y12RTYAUCPw>
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: Wed, 27 Nov 2019 13:47:11 -0000

Hi Vladimir,

Thanks for your feedback.
> 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.
Yes, but not exclusively
> 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.
Yes.

> 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?
The question stems from the "service" definition, which might have 
multiple facets.
You can configure a service and this service is actually a service for 
someone else:
      - the IGP for L3VPN
     - a device for an IGP
     - a DHCP for a device
     - An IPFIX service on a device
     - etc.
The assurance graph was created to be flexible and open, regardless of 
where the subservices are
Some subservices might be located on devices (device health, systemd, 
etc.), some in the network (IS-IS health) and some others linked to the 
orchestrator (network service health)

This is the reason why we created the generic top container as

	module: ietf-service-assurance

... applicable to both Network Service and Network Element.

If this is not clear from the text, feel free to let us know.

Regards, Jean & Benoit

>
> 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
>>>