Subject: [Last-Call] Genart last call review of draft-ietf-opsawg-model-automation-framework-06

From: Ines Robles via Datatracker <[email-masked]>
Date: Thu, 08 Oct 2020 15:47:41 -0700

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?

b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE, E2E

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

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)

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?

e.2- in the Device Level: Should be added Accounting Management and Security
Management [RFC5706]?

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

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.

g- Does this framework applies to the management plane, right?

h- What do you think about policies, e.g.[rfc8328], should it be applied here?

Nits/editorial comments:

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.

---

From: <[email-masked]>
Date: Fri, 9 Oct 2020 08:04:29 +0000

Hi Ines, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Ines Robles via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 9 octobre 2020 00:48
> À : [email-masked]
> Cc : [email-masked]; draft-ietf-opsawg-model-automation-
> [email-masked]; [email-masked]
> Objet : Genart last call review of draft-ietf-opsawg-model-
> automation-framework-06
> 
> Reviewer: Ines Robles
> 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.
> 
> 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?

> b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE,

[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".

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

> e- Section 4, Figure 4:
> 
> e.1- [RFC8309] divides the Service Model into two categories:
> Customer Service Model and Service Delivery Model
> 

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

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

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

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

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

> h- What do you think about policies, e.g.[rfc8328], should it be

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

> Nits/editorial comments:

[Med] Fixed all of these. Thanks.

> Thank you for this document,

_________________________________________________________________________________________________________________________

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.

---

From: Ines Robles <[email-masked]>
Date: Sun, 11 Oct 2020 13:02:36 +0300

Hi Med,

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

>       thus devices) to comply the intended service.

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

> [Med] Agree. Changed to "Data models in the context of network management".

<ines> Ok,  thank you </ines>

> [Med] Resource orchestration/allocation is more on the network level. The
> network model definition says the following:
>

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

> We are using: network and device models for better clarity.

<ines> Ok,  thank you </ines>

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

> We also include in the description of the journey among layers. For
> example, the service creation section says:
>
>   <ines> Ok,  thank you. But what about the service Assurance? </ines>

> whether/how to capture this better.

<ines> Ok,  thank you </ines>

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

>   <ines> Ok,  thank you </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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Mon, 12 Oct 2020 06:40:59 +0000

Hi Ines,

Thank you. A new version that takes into account all reviews, including yours can be seen at:

URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework

Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07

Please see also inline.

Cheers,
Med

De : Ines Robles [mailto:[email-masked]]
Envoyé : dimanche 11 octobre 2020 12:03
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: Genart last call review of draft-ietf-opsawg-model-automation-framework-06

Hi Med,

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

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

[Med] Thank you for the clarification. This is a sub-component of the overall “Device Modelling”. Please refer to “A.4.2.  Device Management”. We don’t want to overload figure 3 with many internal components.

Will double check, though.
  <ines> Ok,  thank you. But what about the service Assurance? </ines>
[Med] A new sub-section was added.

---

From: Ines Robles <[email-masked]>
Date: Mon, 12 Oct 2020 11:41:44 +0300

Hi Med,

Thank you very much for the provided information. I have updated my gen-art
review.

BR,

Ines

On Mon, Oct 12, 2020 at 9:41 AM <[email-masked]> wrote:

> URL:
> https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework
>
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07
>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07
>
>
>
>
> Please see also inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Ines Robles [mailto:[email-masked]]
> *Envoyé :* dimanche 11 octobre 2020 12:03
> *À :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> *Cc :* [email-masked]; [email-masked];
> [email-masked];
> [email-masked]
> *Objet :* Re: Genart last call review of
> draft-ietf-opsawg-model-automation-framework-06
>
>
>
> Hi Med,
>
>
>
> [Med] Thank you for the clarification. This is a sub-component of the
> overall “Device Modelling”. Please refer to “A.4.2.  Device Management”. We
> don’t want to overload figure 3 with many internal components.
>
>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 22 Oct 2020 08:47:14 -0400

Ines, thanks for your reviews. Med, thanks for making the updates. I entered a No Objection ballot.

Alissa

> On Oct 12, 2020, at 4:41 AM, Ines Robles <mariainesrobles=[email-masked]> wrote:
> 
> Hi Med,
> 
> Thank you very much for the provided information. I have updated my gen-art review.
> 
> BR,
> 
> Ines
> 
> On Mon, Oct 12, 2020 at 9:41 AM <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ines,
> 
>  
> 
> URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt <https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt>
> Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ <https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework>
> Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07 <https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07 <https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07> 
> 
>  
> 
> Please see also inline.
> 
>  
> 
> Cheers,
> 
> Med
> 
>  
> 
> De : Ines Robles [mailto:[email-masked] <mailto:[email-masked]>] 
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked] <mailto:[email-masked]>>
> Cc : [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art