Re: [Supa] updating SUPA framework draft

[Zhoutianran <[e-mail]>]

Hi Chongfeng,

I made this change because of my read from the charter that SUPA data model can “be input to a network management function (within a controller, an orchestrator, or a network element)”.
System architecture varies. Indeed you mentioned one case.
In principle, network element can also accept policy. But whether to show on this figure depends on the scope of SUPA.
Do you imply the device policy is out of the SUPA scope?

Best,
Tianran

From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, November 26, 2016 9:48 PM
To: diego.r.lopez; Zhoutianran
Cc: [e-mail]; Jonathan Hansford; Liushucheng (Will); supa
Subject: Re: Re: [Supa] updating SUPA framework draft


Hi,  Tianran,

I agree with your modification,which will help to describe the role of policy defined in SUPA with our network. I have one additional comment, since that network intelligence will be held by upper-layer components, such as Orchestrator and Controller, and the low-layer network element in the data plane will mainly focus on data forwarding, so I think SUPA DM will be the input of Orchestrator and Controller, not Network Element.

Thank you!

Chongfeng Xie



________________________________
[e-mail]<mailto:[e-mail]>

From: Diego R. Lopez<mailto:[e-mail]>
Date: 2016-11-23 17:28
To: Zhoutianran<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Liushucheng \(Will\)<mailto:[e-mail]>; SUPA list<mailto:[e-mail]>
Subject: Re: [Supa] updating SUPA framework draft
Hi,

Just to express my full support to this suggested change. It directly reflects how we are using SUPA in our implementation of a smart network management engine.

Be goode,

On 23 Nov 2016, at 04:16 , Zhoutianran <[e-mail]<mailto:[e-mail]>> wrote:

Hi Will and all,

As from my previous comments, the figure 2 need to reflect:
1. SUPA data model can “be input to a network management function (within a controller, an orchestrator, or a network element)” as in the charter.
2. The design time and run time.

So I would suggest to modify the figure 2 as follows. SUPA designed YANG data models can be the input for management functions, and automatically generate interfaces and data stores. During the run time, components communicate with data instances for management and monitoring.

                             +
                             |  SUPA Policy Model
                             |
                             |  +----------------------------------+
                             |  | Generic Policy Information Model |
                             |  +----------------------------------+
                             |        D                 D
                             |        D   +-------------v-------------+
+----------------------+     |        D   | ECAPolicyRule Information |
| OSS/BSS/Orchestrator <--+  |        D   | Model (EPRIM)             |
+----------^-----------+  |  |        D   +---------------------------+
           C              |  |  +----+D+------------------------+D+---+
           C              +-----+     D   SUPA Policy DM         D    |
+----------v-----------+     |  | ----v-----------------------+  D    |
|  EMS/NMS/Controller  <--------+ | Generic Policy Data Model |  D    |
+----------^-----------+     |  | ----------------------------+  D    |
           C              +-----+              D                 D    |
           C              |  |  |     +--------v-----------------v--+ |
+----------v-----------+  |  |  |     |  ECA PolicyRule Data Model  | |
|  Network Element     <--+  |  |     +-----------------------------+ |
+----------------------+     |  +-------------------------------------+
                             |
                             +


Best,
Tianran

From: Supa [mailto:[e-mail]] On Behalf Of Liushucheng (Will)
Sent: Thursday, November 17, 2016 4:49 PM
To: SUPA list; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Supa] updating SUPA framework draft

Hi all,

After a long off-list discussion, we are doing our final review of -01 version of Framework draft after comments addressed and figures updated,  and will submit -01 version soon. Thanks to many reviewers, especially to Jonathan Hansford for his very detailed review. I'm writing to summarize these comments we received as well as our off-list discussion conclusions to keep the group updated.

The main technical comments are about the three figures.( Which make sense as this is a framework draft :))
Figure 2:  added C arrow from GPDM and EPDM to controllers, changed the sentence explaining D arrow.
Some issue still under discussion: 1. whether we should show all the cases in charter 2. whether we should split the design time and running time in this figure. Welcome the group to give opinions.

Figure 3: Policies are used to control the management of resources and services, while data from resources and services are used to select and/or modify policies during runtime. Therefore, Lines (1)&(2) connecting policy to resource and policy to service are the same, while Line (3) connecting resource to service is different as it’s navigable only from resource to service

Also there is one comment requesting to reconstruct the section 2.3, and we addressed in the upcoming version.

There are also a couple of editorial issues were pointed out, especially the email from Jonathan helped us a lot in improving written English and remove the misleading sentences. Many thanks!

Detailed comments and response are also showed below starts with Will et al.:"

---start---

         From: "Jonathan Hansford" <jonathan at hansfords.net<http://hansfords.net/>>

         ·         General

         o   The phrase “the GPIM (or the combination of the GPIM and the EPRIM)” or its equivalent appears a number of times throughout this document so clearly it is important but, coming to SUPA cold, I failed to understand its importance. If there is a need to constantly repeat this phrase, could it not do with further explanation?

Will et al.: This means that policies can be defined using the GPIM directly, or using the combination of the GPIM and the EPRIM. If you use only the GPIM, you get a technology- and vendor-independent information model that you are free to map to the data model of your choice; note that the structure of a policy is NOT defined. If you use the GPIM and the EPRIM, you get a technology- and vendor-independent information model that defines policies as an event-condition-action (i.e., imperative) rule.

         ·         Page 2

         o   1. Introduction

         §  “the task of network operations and management applications and deploying new services” – is that one task and, if so, what is it? Should that read “the task of network operations and management applications and deploying new services”?

Will et al.: should be "the task of network operations and management applications deploying new services", fixed

         ·         Page 3

         o   1. Introduction

         §  s/indepednent/independent
Will et al.: fixed

         §  What is the term “snippet” intended to imply? Should it be defined somewhere?
Will et al.: A "snippet" is a small piece of information (e.g., part of a sentence that was cut out). We added this sentence at the term first used place for readers better understanding.

         o   2.1 Overview

         §  “The GPIM, as well as the combination of the  GPIM and EPRIM, are converted to generic YANG data modules.” Shouldn’t that be either The GPIM, as well as the combination of the  GPIM and EPRIM, is converted …” or “The GPIM and the combination of the  GPIM and EPRIM are converted …”?
Will et al.: Technically, you could have both. So "The GPIM, and/or the combination of the GPIM and the EPRIM, is converted...".

         ·         Page 4

         o   2.1 Overview

         §  For consistency with capitalisation, either e.g. “SUPA Generic & ECA Policy YANG Data modules” or “SUPA generic policy YANG data modules”
Will et al.: "SUPA Generic Policy and SUPA ECA Policy YANG data modules", fixed

         ·         Page 7

         o   2.1 Overview

         §  None of the arrows with Ds appear to be double-headed and not all of the arrows with Cs
Will et al.: You're right. The Ds should NOT be double-headed. However, the Cs can be; depends on context. So we removed the double-headed term for the sentence of Ds.

         §  Since lower down we have “ECA Policy Rule Information Data Model (EPRIM):” for consistency should we not also have “Generic Policy Information Model (GPIM):”?
Will et al.: yes, thanks, fixed

         §  “query, and implementation languages, and protocol” (appears twice) – should that be “query, implementation languages, and protocol”?
Will et al.: yes, thanks, fixed

         §  “policy rules for that are” – should that be “”policy rules that are”?
Will et al.: yes, thanks, fixed

         §  “dependent of” – should that be “independent of” or “dependent on”?
Will et al.: yes, thanks, fixed

         §  “policy rules derived from EPRIM, consist” – should that be “policy rules, derived from EPRIM, that consist”?
Will et al.: yes, thanks, fixed

         ·         Page 8

         o   2.1 Overview

         §  “Relationship among Policy, Service and Resource” (appears twice) – should that be “Relationship between Policy, Service and Resource”?
Will et al.: fixed. btw, policy is used to orchestrate and control resource and service management. However, the reverse is NOT true. Put another way:
   - Policies are used to control the management of resources and services
   - Data from resources and services are used to select and/or modify policies during runtime
Note that this latter relationship is currently missing from the previous version, so we merged them into the paragraph below this figure. We also updated the figure based on this point.


         §  Should the caption for Figure 3 end with “models”?
Will et al.: Yes, added. Please note that SUPA is trying to be model-driven. This means that you don't change code directly - you change models, which then generates the correct code.

         o   2.2 Operation

         §  “the goals to achieve” – would “the goals to be achieved” be better?
Will et al.: yes, thanks, fixed

         ·         Page 9

         o   2.3 The GPIM and the EPRIM

         §  The structure of this section feels a little odd. Item (1) appears to repeat a little of what is in the first two paragraphs and I wonder whether the section would be better structured if those two paragraphs were incorporated into item (1).
Will et al.: The first paragraph defines the purpose of the GPIM. The second paragraph says that since we have a common vocabulary, we can relate different actors that use different representations of policy to each other as a continuum. Without the common vocabulary, this would be impossible.

The  third paragraph is confusing and should be deleted.

Now, incorporate the gist of what was said in the two points in the first paragraph, as follows:

   The GPIM provides a common vocabulary for representing concepts
   that are common to expressing different types of policy, but which
   are independent of language, protocol, repository, and level of
   abstraction. Hence, the GPIM defines concepts and vocabulary
   needed by policy management systems independent of the form
   and content of the policy. The ERPIM is a more specific model
   that refines the GPIM to specify policy rules in an
   event-condition-action form



         ·         Page 10

         o   2.4 Creation of Generic YANG Modules

         §  “the addition of new, as well as editing of existing model elements” – should that be “the addition of new, as well as the editing of existing model elements”?
Will et al.: yes, thanks, fixed

         o   Pagination fails on the PDF version of this Internet-Draft. Is this page too long?
Will et al.: fixed now.

---cut---

Regards,
Will

_______________________________________________
Supa mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/supa

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Tel:    [phone]
Mobile: [phone]
----------------------------------