Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-model-automation-framework-06

Ines Robles <mariainesrobles@googlemail.com> Sun, 11 October 2020 10:03 UTC

Return-Path: <mariainesrobles@googlemail.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 B12013A0829; Sun, 11 Oct 2020 03:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 zv955WJCEYkJ; Sun, 11 Oct 2020 03:03:13 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 7926C3A0820; Sun, 11 Oct 2020 03:03:13 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id f8so7449650vsl.3; Sun, 11 Oct 2020 03:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AhPfaZrGEZ4AwNsvtQmBwDU8YVUtHwoN+hfRkm3eVRo=; b=IqZB6KHhNi/2woE8pqbGGlHMP85JQoaXRHpIYcCSdYHyNXVUT2ihdfzOLlt637p53L Gq13WaFH+dt2X3mQVQ68KLMbmIK5tdolzKGSt+KXkqdI0BFVu8rKzp3dDbk2xQsLEQfX jccndYDy3Kzuy4ctfunlAddpSOxL/FtdXhsrY4YvFxGHqjzSQNPVDTPaRhP97NgaoPLx LBXWYpzlXcMCXxmOQhueOKYD3IceFUTzDMoMqa3vuV801CTwR8KBxR50ioj7c61wDHUk 5ReY75HVjALMK/QhdDjCOEPQ2KwAXmgi5vmICbA+DOejFVB/jYGmEtiP1nbrKhQiqssh GSjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AhPfaZrGEZ4AwNsvtQmBwDU8YVUtHwoN+hfRkm3eVRo=; b=MiIlFH6HKQjurlrHryk3K+xZ8H3LLrddeVmEpL1iRJJUztrZaUoKEl63ErRch6q/N3 HYb3erYhPA9cPtmQCsNR1/y/t/vxrXCwjuYclOuBJ8EHs+N8j+/9PM5UG+rZa0Tk+EGx 0aB0WPWpt/IF/U8yqXJCp88N7lY8HZ2m3nk9c1Gaabo9yqeT4YwCCdWRQDhuPOtrdWqR Rk4aI/B0eKbNQ11ryZlNTXqLaBT5jzgE0T8K0N6Vcwow3Yig6CxVTN02BR2+8Vnsk9gE co9SBO0YtulATGOjMkW2I44F776SpJJ0vF6b67quVe7ztLYPDBSHuNIaC9iEDcpef7M8 oigA==
X-Gm-Message-State: AOAM532MniUrDOReTkp05pgTDhz3QsjpYCx2N359onrAMqOjxuJfj8XY MmvaWjXjjNtEryze/iqRzcAT1qKAZiscXSAzqpo=
X-Google-Smtp-Source: ABdhPJyyxAbX/gWGX+fjX3QWWwgPZt1uTYYJFhQbrwWpk+JW6Q9zvk78NSAPYzoXuTmRdrjf6kAlnIk7s3TcCmW+17A=
X-Received: by 2002:a67:cd03:: with SMTP id u3mr12203780vsl.3.1602410592327; Sun, 11 Oct 2020 03:03:12 -0700 (PDT)
MIME-Version: 1.0
References: <160219726151.7069.6476351560272708886@ietfa.amsl.com> <16977_1602230670_5F80198E_16977_251_3_787AE7BB302AE849A7480A190F8B93303155BAC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <16977_1602230670_5F80198E_16977_251_3_787AE7BB302AE849A7480A190F8B93303155BAC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sun, 11 Oct 2020 13:02:36 +0300
Message-ID: <CAP+sJUejn4D-O6mJoVb32ijJJWLpgjbBMzpwCwTwS3S+Wb_viw@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "draft-ietf-opsawg-model-automation-framework.all@ietf.org" <draft-ietf-opsawg-model-automation-framework.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023dd3205b1624aa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/R2aPgsEqqa7TtDxId8vtjTjgVdY>
Subject: Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-model-automation-framework-06
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: Sun, 11 Oct 2020 10:03:17 -0000

Hi Med,

Thank you very much for addressing my comments. Please find my answers
below.



On Fri, Oct 9, 2020 at 11:04 AM <mohamed.boucadair@orange.com> wrote:

> Hi Ines,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Ines Robles via Datatracker [mailto:noreply@ietf.org]
> > Envoyé : vendredi 9 octobre 2020 00:48
> > À : gen-art@ietf.org
> > Cc : opsawg@ietf.org; draft-ietf-opsawg-model-automation-
> > framework.all@ietf.org; last-call@ietf.org
> > Objet : Genart last call review of draft-ietf-opsawg-model-
> > automation-framework-06
> >
> > Reviewer: Ines Robles
> > Review result: Ready with Issues
> >
> > I am the assigned Gen-ART reviewer for this draft. The General Area
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > For more information, please see the FAQ at
> >
> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >
> > Document: draft-ietf-opsawg-model-automation-framework-06
> > Reviewer: Ines Robles
> > Review Date: 2020-10-08
> > IETF LC End Date: 2020-10-08
> > IESG Telechat date: Not scheduled for a telechat
> >
> > Summary:
> >
> > This document describes an architectural framework for service and
> > network management automation, with respect of service, network and
> > device level.
> >
> > I have some concerns as detailed below that I would like to be
> > addressed before publication
> >
> > Major issues: None
> >
> > Minor issues:
> >
> > a-Introduction:
> >
> > "framework...that takes advantage of YANG modeling technologies" -->
> > how does it take advantage?
> >
>
> [Med] We can add this NEW text:
>
> Concretely, the following benefits can be provided:
>
>    o  Allow for vendor-agnostic interfaces to manage a service and the
>       underlying network.
>
>    o  Move from deployment schemes where vendor-specific network
>       managers are required to a scheme where the entities that are
>       responsible for orchestrating and controlling services and network
>       resources provided by multi-vendor devices are unified.
>
>    o  Ease data inheritance and reusability among the various
>       architecture layers promoting thus a network-wise provisioning
>       instead of device-specific configuration.
>
>    o  Dynamically fed a decision-making process (e.g., Controllers,
>       Orchestrators) with notifications that will trigger appropriate
>       actions allowing thus to continuously adjust a network stats (and
>       thus devices) to comply the intended service.
>
> Do we need to say more?
>

<ines> Ok, that is great, thank you </ines>

>
> > b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE,
> > E2E
>
> [Med] OK.
>
> >
> > c- Section 3.1:
> >
> > It would be nice to add clarification: Data models can be classified
> > .... -> Data models in the context of ..... can be classified...
> >
>
> [Med] Agree. Changed to "Data models in the context of network management".
>

<ines> Ok,  thank you </ines>

>
> > d- Figure 3: The box Device includes Device Modeling. Should be
> > added in Device as another box for "Resource Orchestration"? (As
> > e.g. Service has Service
> > Orchestration)
> >
>
> [Med] Resource orchestration/allocation is more on the network level. The
> network model definition says the following:
>
>       It can be used by a network operator to allocate resources (e.g.,
>       tunnel resource, topology resource) for the service or schedule
>       resources to meet the service requirements defined in a Service
>       Model.
>
> Of course some of this may be distributed, but I don't think that we need
> to overload the document with this.
>

<ines> Ok,  it is fine for me, my question was more related to device
resources e.g. sensors/actuators as device resources </ines>

>
> > e- Section 4, Figure 4:
> >
> > e.1- [RFC8309] divides the Service Model into two categories:
> > Customer Service Model and Service Delivery Model
> >
> > How these categories are descripted into the Service Lifecycle in
> > the Figure?
> >
>
> [Med] Customer Service Model are used at the service layer. See for
> example this mention in the document:
>
>    L2SM and L3SM are customer Service Models as per [RFC8309].
>
> We are not using "Service Delivery Model" as this may not be specific.
> Please refer to the following from 8309:
>
>    Some of these models are classified as network service
>    delivery models (also called service delivery models or network
>    configuration models depending on the level at which they are
>    pitched), while others have details that are related to specific
>    element configuration and so are classed as network element models
>    (also called device models).
>
> We are using: network and device models for better clarity.
>

<ines> Ok,  thank you </ines>

>
> > e.2- in the Device Level: Should be added Accounting Management and
> > Security Management [RFC5706]?
> >
>
> [Med] These can also be aggregated at the network level. I'm hesitating to
> add a mention about this as this is usually dispatched among many modules
> (including defining thresholds and notifications). We do cite YANG examples
> to manage ACLs (RFC8519).
>

<ines> Ok</ines>

>
> > e.3- In the explanation of the Functional Blocks and Interactions
> > section, why the following blocks are not defined/explained in the
> > subsections?: *Service Assurance *Specific Service
> > Creation/Modification *Specific Service Optimization *Specific
> > Service Assurance
>
> [Med] We don’t repeat "Specific-*" as we do say the following:
>
>    The end-to-end service lifecycle management is technology-independent
>    service management and spans across multiple network domains and/or
>    multiple layers while technology specific service lifecycle
>    management is technology domain specific or layer specific service
>    lifecycle management.
>
> We also include in the description of the journey among layers. For
> example, the service creation section says:
>
>    If the request is accepted, the service orchestrator/management
>    system maps such service request to its view.  This view can be
>    described as a technology specific Network Model or a set of
>    technology specific Device Models and this mapping may include a
>    choice of which networks and technologies to use depending on which
>    service features have been requested.
>
> That is basically about "Specific Service Creation".
>
> Will double check, though.
>
>   <ines> Ok,  thank you. But what about the service Assurance? </ines>


> >
> > f- Section 6: I think it would be nice to explain the security
> > considerations based on the possible attacks/threats/privacy to
> > Service Level, Network Level and Device Level. In other words,
> > explains the vulnerabilities for each part of the entities that
> > conform the proposed framework.
> >
>
> [Med] Some considerations apply to all of the layer, but I will see
> whether/how to capture this better.
>

<ines> Ok,  thank you </ines>

>
> > g- Does this framework applies to the management plane, right?
>
> [Med] YANG can be used to tweak forwarding tables/install paths. Some
> consider this as part of the control plane. YANG can also be used to
> request services (e.g., customer-facing interface).
>

<ines> Ok,  thank you </ines>

>
> >
> > h- What do you think about policies, e.g.[rfc8328], should it be
> > applied here?
>
> [Med] We used to have this text bit we removed it as there is not
>
>    o  Generic Policy Model:
>
>       The Simplified Use of Policy Abstractions (SUPA) policy-based
>       management framework [RFC8328] defines base YANG modules
>       [I-D.ietf-supa-generic-policy-data-model] to encode policy.  These
>       models point to other device-, technology-, and service-specific
>       YANG modules.  Policy rules within an operator's environment can
>       be used to express high-level, possibly network-wide, policies to
>       a network management function (within a controller, an
>       orchestrator, or a network element).  The network management
>       function can then control the configuration and/or monitoring of
>       network elements and services.
>
> But removed it as there is not wide support of this framework.
>
>   <ines> Ok,  thank you </ines>


> >
> > Nits/editorial comments:
>
> [Med] Fixed all of these. Thanks.
>
> >
> > cutsomer-facing -> customer-facing
> >
> > data module --> data model?
> >
> > expand OSS/BSS -> Operations Support System (OSS) or a Business
> > Support System
> > (BSS)
> >
> > Thank you for this document,
> >
> > Ines.
> >
> >
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>