Subject: [Supa] review of draft-klyus-supa-proposition-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 19:15:01 +0200

Hi,

while I have quite some comments (see below), let me first state again
that I really very much appreciate the effort to converge on a single
document that helps to explain what SUPA is about. Thanks to Maxim for
stepping up to hold the pen on this. Please understand my comments as
constructive input in order to improve the consistency of the document.

/js

* Structure

  I think the structure is a bit confusing. I think the terminology should
  become section 2, subsection 1.2 should become section 3, and then the
  framework section becomes section 4 etc.

* Abstract

  - Should the first sentence be replaced with the first sentence of the
    charter to be consistent?

  - I do not understand what the last sentence in the abstract refers
    to; there is no such mapping work in the charter.

* 1. Introduction

  - s/would benefit/benefit/

  - In the charter, we use the term 'network elements' instead of
    'devices', 'network devices' or 'network entities' and I propose
    we do the same throughout this I-D.

  - What does it mean that 'network elements should be as simplified
    (abstracted) as possible'? And what is 'the application'?

  - We are not 'developing a methodology'. We had this is earlier
    versions of the charter and this got removed since this
    formulation was not perceived well.

  - You do not manage or automate anything by having an information
    model since an information model is conceptual. What you can
    implement and later use to solve problems are concrete data
    models. The wording on the 4th paragraph can be improved.

  - I think ', including the set of information models required to
    construct an extensible, policy-based framework' can be removed
    (it does not add anything that has not already been said).

  - The same applies to the 5th paragraph - remove it since it does
    not add anything new.

* 1.1 Problem Statement

  - There is a certain risk that the examples mentioned here make
    policy sound QoS specific which I think should be avoided. I want
    policies that can express things like "routers and switches must
    not accept passwords for logins" (and example for a security
    policy that is not tied to a network service).

  - There should be a distinction between policies embedded in the
    configuration of network elements and the policies discussed here,
    see the charter text. This affects the last paragrapgh in section
    1.1.

* 1.2 Requirements

  - I miss the point of this section. It largely repeats what has
    already been said. Hence, I suggest to remove it. Instead, an
    argument should be added why information models are needed.

  - The last point in the requirements section I disagree with. The
    goal is not to 'specify how to map' but instead to provide the
    corresponding YANG data models.

* 2. Terminology

  - You do not define NE, NC, NM, NS. In particular, I am not sure I
    understand the difference made between NC and NM. I suggest you
    define all terms.

  - The term 'service specific abstraction' does not seem to be used.

  - I find the term SUPA policy difficult to read. Why do we need a
    _SUPA_ policy? And here is another instance of managed entities
    that probably should be networked element.

  - Would it not make sense to import some of the terms from RFC 3198?
    I think it does.

  - I am not sure why we need this model mapping definition or how
    this is relevant (since it is not part of the current proposed
    SUPA charter).

* 3. Framework

  - What does 'can enable existing IETF frameworks, including but not
    limited to I2RS and L3SM' mean? Perhaps simple remove this
    sentence.

  - I do not understand Figure 1. What is communication between a data
    model and a controller? What does 'references' mean? Why is everything
    (nearly everything) contained in a 'Service Management' box?

  - The definition of 'Generic Policy Data Model' is at odd with the
    definition of a Data Model.

  - I do not understand the indentation structure of the text.

  - Text talks about a Policy Manager (not a defined term) but that is
    not visible in Figure 1.

  - s/now considered/considered/

  - The ECA/Goal distinction does not seem to refer to Fig. 1 - so why
    is the text here?

  - I would remove references to some of the -supa- I-Ds. This will
    lead to questions since topology work now takes place in I2RS. And
    the current charter does not talk about topology work so we should
    not do this here either.

  - What does this mean? 'NM/NC may also communication with a network
    management system to retrieve the above information'.

  - A SM does not push a data model. All it can do is to push data
    defined according to a format defined in a data model.

  - I do not understand the mapping blocks in Figure 2. For ECA rules,
    you have a rule interpreter doing the work. For declarative rules,
    you have essentially a search system to find configurations that
    are valid solutions for the given goal(s).

  - I am having an issue with the many mappings. Instead, we should
    make it clear that policy will translate to changes of data models
    embedded in network elements. Somehow the mapping bullets read a
    bit like we are open ended and not focused.

  - First paragraph on page 14: You do not communicate data models
    in the way described there.

  - What does 'is locally managed (e.g., via CLI, SNMP, or NETCONF)'
    mean? What is _local_ here?

  - Please call SGPIM simply GPIM (to be consistent with the charter
    text).

  - Section 3.4 seems to be add odd with other pieces of text. I
    thought there is a generic policy information model and then there
    are two extension information models. Then all these three are
    mapped to data models.

  - I think we should try to remove repetive text and instead provide
    a strong argument why both forms of policy are needed. It is
    stated several times what the plan is but there is likely
    reasoning missing why we do this.

* 4. Application of Generic Policy-based Management

  - Some additional ideas for example policies (perhaps a bit more down
    to earth or easily linked to existing configuration data models:

       All routers and switches must have password login disabled.

    This one requires to resolve 'routers and switches' to a set of
    network elements and then to push the apropriate configuration
    to those network elements.

       All SNMP agents enable SNMPv3 and disable all other versions of
       SNMP.

    This maps directly to the leafs v1, v2c, and v3 in the ietf-snmp
    YANG data model (RFC 7407).

       All SNMP traffic is dropped unless it originates from or is
       directed to a an interface of a management system.

    This requires to resolve an interface of a management system to a
    list of IP addresses and then to create a set of suitable ACL rules
    that are configured on all network elements.

  - In the ECA section, we show equivalent ECA rules. I am not sure
    how useful this is. If we leave the impression that I can always
    translate a declarative statement to ECA rules, why would I need
    both? I would rather find different examples that naturally tie
    into events. John, any good ideas? Otherwise I will think a bit
    more about good down to earth examples.

* 5. Related Work

** 5.1.1

   - s/SUPA is an I2RS client, and/SUPA/

   - I fail to understand the use case discussion here. I suggest to
     simple remove the second paragraph.

   - The last paragraph is highly confusing. The fact that two people
     know a common language does not mean they communicate. I suggest
     this instead:

        It is envisioned that SUPA will use work produced by I2RS.
	This in particular applies to the topology work done in the
	I2RS working group since topology information is often
	necessary for the interpretation of SUPA policies.

** 5.1.2

   - This statement seems pretty much wrong:

        This
        model enables customers to configure the network elements via
        L3 VPN technologies.

     My understanding is that L3SM configures a service which then
     translates to network element configurations.

     Perhaps this is better?

       L3SM defines an L3 VPN service model that can be used for
       communication between customers and network operators. This
       model enables customers to request network services provided
       by L3 VPN technologies. The implementation of network serives
       is often guided by specific policies and SUPA provides a
       tool that can help with the mapping of L3 VPN service requests
       to L3VPN configurations of network elements.

** 5.1.3

   - Perhaps replace 'different levels of abstraction at multiple
     granularities' with 'different levels of granularities'

   - I suggest to remove the last sentence in 5.1.3. It is for me
     highly unlikely that end hosts pay attention to SUPA policies.

** 5.1.4

   - Add '(TEAS)' after the WG name so that acronym is defined.

   - Split the second sentence in the first paragraph:

     It covers YANG models for a traffic engineering database. In
     coordination with other working groups (I2RS), TEAS provides YANG
     data models for network topologies.

** 5.1.5

   - Add '(BESS) working group' after the WG name so that the acronym
     is defined and the sentence is complete.

   - The statement 'SUPA does not generate BGP configurations' may not
     be true; if SUPA provides a generic policy-engine that can lead
     to configuration changes of any YANG data model, then the policy
     engine will also be able to manipulate BGP configurations.

   - I can't parse the last sentence of this section. If I remove
     'that define', I can parse it but the statement remains rather
     abstract.

** 5.1.7

   - I am not familiar with NVO3 but as stated they do policies. If
     true, this section should explain how their policies related to
     SUPA policies.

** 5.1.8

   - There is no topology work anymore in the SUPA charter and hence
     the stated overlap likely should be removed. The first two
     paragraphs seem to largely overlap; please merge them into one.

   - The last paragraph talking about SFC seems to be a cut and paste
     error

** 5.2.1

   - Instead of naming an I-D inline in the text please use a
     reference.

** 5.2.2

   - Remove the line simply saying "MEF".

** 5.2.5.1

   - If you use the acronym GBP, you have to introduce it. Since it is
     only used once, perhaps simply expand it.

** 5.2.6

   - Strange line break.

** 5.2.7

   - s/. it uses/. It uses/

   - s/. Indigo agent/. The Indigo agent/

** 5.3

   - I do not understand the purpose of section 5.3 nor do I see why
     it fits under 'Related Work'.

* References

  Why is RFC7285 a normative reference? I actually wonder whether this
  document has any normative references at all (since it does not define
  anything normative).

* Authors List

  I suggest to follow the "RFC Series Editor statement on authorship"

  http://www.ietf.org/mail-archive/web/ietf-announce/current/msg14129.html

  that is Maxi and John and the authors designated as editors and
  everybody else becomes a contributor.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Jun 2015 23:59:41 +0200

Thanks Jürgen, the feedback is about right.

Regards, Benoit
>      to; there is no such mapping work in the charter.
Yep, I flagged that one as well.

---

From: John Strassner <[email-masked]>
Date: Mon, 8 Jun 2015 23:59:56 -0700

Dear Dan and Juergen,

thank you both for your very quick review of the draft. While the attached
draft is NOT complete, it is hopefully "better" and reflects your comments.

My additional sub-goals:

   a) reduce the amount of text (Benoit's comment) - right now, by over 4
pages.
   b) strive for consistency (especially with the revised charter)
   c) start to map the wiki Q&A into the draft

Regarding c):

STARTED A MAPPING OF THE Q&A TO THE PROPOSITION DRAFT
Q1
  •SUPA provides a generic infrastructure:      1., 1.2
  •will achieve an optimization and reduction:  1.3
  •the framework is generic and extensible...:  1., 1.3
  •no other WG in the IETF...:                  1.3
Q2
  •decouples the (abstract) information model:  1.3, 2.4
  •other policy work in the IETF:               1.2
  •SUPA focuses on policies that drive:         all
    SNMP policy example:                        1.2
Q7 and Q8 will go into section 4

Here is what I have incorporated from Dan and Juergen:

>From Dan:

1) FIXED (SUPA intro sentence was broken)
2) POSTPONED (can do tomorrow)
3) AGREED, NOT FIXED YET (IM instantiates to one or two DMs) However, I did
FIX this in 2.1.
4) Old age? :-)  (sure, we can reverse this)
5) I thought I made a good comparison of two documents that are almost 200
pages, but people didn't like it. I can try and trim this (or better yet,
copy my new smaller response from the wiki Q-A). (RFC3060 and 3460 in 5.1)
6) NOT FIXED YET (Conclusions - Value of SUPA) Note that I put a section
1.3 (Benefits) so that people could just read the first couple of pages and
declare victory...should we keep this and do the change, or just do the
change?

>From Juergen:

1) 7 items from Section 1 - ALL FIXED
2) 2 items from Section 1.1 - BOTH FIXED
3) 2 items from Section 1.2 - AGREED, REMOVED THIS SECTION

*<to make it easier to read, I split 1.1, Problem Statement, into two
sections: 1.1 (Problem Statement) and 1.2 (Proposed Solution).>*

4) Terminology. I DELETED the section. Benoit didn't seem to like it. I
agree that a value proposition that requires a terminology section is
probably a bad idea, as it is not easily digestible.

My thoughts:
    a) The one exception to this is the definition of declarative (intent)
policy. I would rather inline the definition.
   b) NetworkService is a very NFV-centric definition; I prefer the ZOOM
definition, but then you need to pull in more of the ZOOM framework, so I'd
rather delete it as Juergen suggested
   b) the rest of the terms are, I believe, not needed

5) Framework (now section 2)

   - sentence on IETF frameworks: FIXED
   - Figure 1 comments
      - Figure 1 FIXED
      - the data model gets passed from the service manager to the
controller
      - "references" means that in order to instantiate the data model, the
information model must be used
  - generic policy data model definition is fixed (earlier definition was
removed; it conflicted with draft-strassner-...)
  - indentation structure fixed (*NOTE: I deleted references to drafts that
are not mentioned; I think that this will only confuse the reader at this
point if they remain*)
  - Policy Manager comment: terminology is removed, and stated that it is
not visible because it can be located in multiple places. If you don't
agree, let's just delete the sentence.
  - s/now considered/considered/   FIXED
  - The ECA/Goal distinction does not seem to refer to Fig. 1...   FIXED
   - I would remove references to some of the -supa- I-Ds...  FIXED
   - What does this mean?...  FIXED
   - A SM does not push a data model...   FIXED

   - I do not understand the mapping blocks in Figure 2. For ECA rules,
    you have a rule interpreter doing the work. For declarative rules,
    you have essentially a search system to find configurations that
    are valid solutions for the given goal(s).
   <jcs> I agree with Juergen. I'm also starting to wonder why there is
            a functional entity discussion in the first place. I think we
got
            over-excited with merging text. I have removed this section
   </jcs

   - I am having an issue with the many mappings. Instead, we should
    make it clear that policy will translate to changes of data models
    embedded in network elements. Somehow the mapping bullets read a
    bit like we are open ended and not focused.
   <jcs> I agree with Juergen. Even if the text was focused, mapping is
            ***VERY DIFFICULT***. Look at QVT - it failed, and had some
            of the best minds in the world on it. Model-mapping is an open-
            ended problem, and I thought we agreed today NOT to do
            model mapping. Furthermore, it is not in the charter. More
reason
            to delete this text, which I did.
   </jcs>

   - First paragraph on page 14...   FIXED
   - What does 'is locally managed...   FIXED
   - Please call SGPIM simply GPIM...   FIXED

   - Section 3.4 seems to be add odd with other pieces of text. I
    thought there is a generic policy information model and then there
    are two extension information models. Then all these three are
    mapped to data models.
   <jcs> You are correct. I FIXED this. </jcs>

   - I think we should try to remove repetive text and instead provide
    a strong argument why both forms of policy are needed. It is
    stated several times what the plan is but there is likely
    reasoning missing why we do this.   FIXED

Now, I pass the pen to Max. :-) We can take advantage of 12 hours of
difference in time zones. I can resume work tomorrow in the early
afternoon. I do think that we need to get something out hopefully by end of
Tuesday - otherwise, the IESG and IAB have no time to review.

regards,
John

On Mon, Jun 8, 2015 at 10:15 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

-- 
regards,
John

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Jun 2015 09:38:37 +0000

Hi John,

Thanks for the good work. Answering a couple of issues below.

Thanks and Regards,

Dan

From: John Strassner [mailto:[email-masked]]

5) I thought I made a good comparison of two documents that are almost 200 pages, but people didn't like it. I can try and trim this (or better yet, copy my new smaller response from the wiki Q-A). (RFC3060 and 3460 in 5.1)

DR – the first bulleted paragraph in the wiki seems sufficient (and necessary) to me. We need to address the issue, as this is what comes closer to ‘prior IETF art’ and Benoit also raised the issue.

6) NOT FIXED YET (Conclusions - Value of SUPA) Note that I put a section 1.3 (Benefits) so that people could just read the first couple of pages and declare victory...should we keep this and do the change, or just do the change?

DR – yes, it does not really matter too much where it is place. If you make it 1.3 we do not need 6. I would just call it ‘value’ rather than ‘Benefits’ (stronger word).

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 9 Jun 2015 19:00:37 +0000

Dear all,

Here is my part of changes combined with Johns’ edition.

Juergen comments:

/Max: FIXED

/Max: FIXED

* 5. Related Work

** 5.1.1

/Max: FIXED

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.2

        This

     Perhaps this is better?

/Max: I do not agree on both so I fixed with my own sentence. FIXED

** 5.1.3

/Max: FIXED

/Max: FIXED

** 5.1.4

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.5

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.7

/Max: I checked NVO3 charter and documents and I can find even something close to policies.
They have couple documents about security however there is no any policy considered.
So I’m not sure what we should explain here.

** 5.1.8

/Max: FIXED

/Max: FIXED

** 5.2.1

/Max: FIXED

** 5.2.2

/Max: FIXED

** 5.2.5.1

/Max: FIXED

** 5.2.6

   - Strange line break.

/Max: FIXED

** 5.2.7

   - s/. it uses/. It uses/

/Max: FIXED

/Max: FIXED

** 5.3

/Max: I agree and prefer to delete it at all. FIXED

* References

* Authors List

/Max: FIXED

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

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

--
BR,
Max

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: John Strassner <[email-masked]>
Date: Tue, 9 Jun 2015 13:42:23 -0700

Thanks Max, I will take the pen back.

NOW would be a good time for people to give us feedback. :-)

Max, do you want me to submit IFF I finish tonight? Or hand back to you? I
realize it is very late in Moscow...

regards,
John

On Tue, Jun 9, 2015 at 12:00 PM, Maxim Klyus <[email-masked]> wrote:

>  ------------------------------
> The information transmitted herein is intended only for the person or
> entity to which it is addressed and may contain confidential, proprietary
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the material
> from any computer.
>
>

-- 
regards,
John

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 9 Jun 2015 21:49:02 +0000

Hi John,

It's up to you, I'm ready to catch up,  we can wait some additional comments, but I think we should submit it
tommorow anyway, because time is critical for us and everbody expect to see some results.

BR,
Max
________________________________
From: John Strassner [[email-masked]]
Sent: Tuesday, June 09, 2015 11:42 PM
To: Maxim Klyus
Cc: Juergen Schoenwaelder; Romascanu, Dan (Dan); [email-masked]
Subject: Re: [Supa] review of draft-klyus-supa-proposition-00

Max, do you want me to submit IFF I finish tonight? Or hand back to you? I realize it is very late in Moscow...

regards,
John

On Tue, Jun 9, 2015 at 12:00 PM, Maxim Klyus <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Juergen comments:

/Max: FIXED

/Max: FIXED

* 5. Related Work

** 5.1.1

/Max: FIXED

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.2

        This

     Perhaps this is better?

** 5.1.3

/Max: FIXED

/Max: FIXED

** 5.1.4

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.5

/Max: FIXED

/Max: FIXED

/Max: FIXED

** 5.1.7

** 5.1.8

/Max: FIXED

/Max: FIXED

** 5.2.1

/Max: FIXED

** 5.2.2

/Max: FIXED

** 5.2.5.1

/Max: FIXED

** 5.2.6

   - Strange line break.

/Max: FIXED

** 5.2.7

   - s/. it uses/. It uses/

/Max: FIXED

/Max: FIXED

** 5.3

* References

* Authors List

/Max: FIXED

--
BR,
Max

--
regards,
John