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

[Ines Robles <[e-mail]>]

Hi Med,

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



On Fri, Oct 9, 2020 at 11:04 AM <[e-mail]> wrote:

> Hi Ines,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Ines Robles via Datatracker [mailto:[e-mail]]
> > Envoyé : vendredi 9 octobre 2020 00:48
> > À : [e-mail]
> > Cc : [e-mail]; draft-ietf-opsawg-model-automation-
> > [e-mail]; [e-mail]
> > 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.
>
>