Subject: [nmrg] Review draft-irtf-nmrg-ibn-intent-classification

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Mar 2021 18:32:09 +0100

Dear all,

Thank you very much for this draft, which is rather complete. Good job.
I believe it's (almost) ready. There is a series of (mostly editorial) 
comments. I tried to provide proposals directly, when I felt inspired. I 
support moving this draft forward.

Regards, Benoit

  - Abstract:

    Up to now, there is no commonly agreed definition, interface or model of
    intent.

Well, there is a definition, indraft-irtf-nmrg-ibn-concepts-definitions-03  <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>
Also, I would not refer to RFC7575 in the abstract.

PROPOSAL:

    Intent is an abstract, high-level policy used to operate the network.
    Intent management system includes an interface for users to input
    requests and an engine to translate the intents into the network
    configuration and manage their life-cycle.

    This document discusses mostly the concept of network intents, but
    other types of intents are also being considered. Specifically, it
    highlights stakeholder perspectives of intent, methods to classify
    and encode intent, the associated intent taxonomy, and defines
    relevant intent terms where necessary. This document provides a
    foundation for intent related research and facilitate solution
    development.

- Section 1
After this section
    IETF [ANIMA  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-ANIMA>] defines intent as a declarative policy, but still lacks
    a more complete definition, a tentative format, and a life-cycle.
    Within ONOS [ONOS  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-ONOS>], intent is represented as a list of Command-Line
    Interface (CLI) commands that allows users to bypass low-level
    details on the network, such as flows or host addresses. ONF through
    its Boulder and Aspen projects focuses on Northbound Interface (NBI)
    semantics and intent models.

... I would add a section that refers todraft-irtf-nmrg-ibn-concepts-definitions-03  <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>
For example,

    More recently, the IRTF Network Management Research Group (NMRG) standardized
    the Intent-based Networking - Concepts and Definitions document,  <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>
    draft-irtf-nmrg-ibn-concepts-definitions-03.   <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>This document clarifies the
    concept of "Intent" and provides an overview of the functionality that is
    associated with it.  The goal is to contribute towards a common and
    shared understanding of terms, concepts, and functionality that can
    be used as the foundation to guide further definition of associated
    research and engineering problems and their solutions.

    The present document, together withdraft-irtf-nmrg-ibn-concepts-definitions-03  <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>,
    aims to become the foundation for future intent-related topic discussions regarding the
    NMRG.

And, I would remove the following sections at the end of the section:
    Currently, work is underway on unifying a common understanding of
    intent concepts and terminology. Concerning NMRG, [CLEMM  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-CLEMM>] is a
    document to present a definition for intent as higher-level
    declarative policy that operates at the level of network and services
    it provides. In addition, this document captures the differences
    between intent, policy and service.

    The present document, together with [CLEMM  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-CLEMM>], aims to become the
    foundation for future intent-related topic discussions regarding the
    NMRG.

-draft-irtf-nmrg-ibn-concepts-definitions-03  <https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/>  should be a normative reference

- I'm going to provide the same remark as for the draft-irtf-nmrg-ibn-concepts-definitions document.
See my email to the list a couple of days ago.

    o It must be vendor agnostic, in the sense that it abstracts the
       network capabilities, or the network infrastructure from the user,
       and it can be ported across different platforms.

What is a "user"? Is this a network operator, the administrator.
We should be consistent with this draft, ideally between the two drafts (a definition might be a plus)

- I would remove this section,
    Currently, work is underway on unifying a common understanding of
    intent concepts and terminology. Concerning NMRG, [CLEMM  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-CLEMM>] is a
    document to present a definition for intent as higher-level
    declarative policy that operates at the level of network and services
    it provides. In addition, this document captures the differences
    between intent, policy and service.

- Section 1.1
    Indentation issues with paragraph 2 and 3
    This document clarify => this document clarifies

- section 2
None of the RFC2119 is used in the document, you should remove this section

- section 3
      DB: Data Base (isn't database?)

- Some of the acronyms are not needed. See https://www.rfc-editor.org/materials/abbrev.expansion.txt
You should remove API, IP, IETF, etc. I haven't checked the full list.

- section 4
Use the exact 3 definitions from draft-irtf-nmrg-ibn-concepts-definitions and refer to it.

- section 5.1
Remove "Future versions of this draft will be kept aligned with [CLEMM  <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#ref-CLEMM>]."
No need for this sentence, as we're finalizing both drafts.

- The following paragraphs are redundant
    While it is easier for those familiar with different standards to
    understand what service, CFS, RFS, resource, policy continuum, ECA
    policy, declarative policy, abstract policy or intent policy is, it
    may be more difficult for the wider audience.

    An intent is mistaken by many to be just a synonym for policy. While
    it is easier for those familiar with different standards to
    understand what service, CFS, RFS, resource, policy continuum, ECA
    policy, declarative policy, abstract policy or intent policy is, it
    may be more difficult for the wider audience. Furthermore, those
    familiar with policies understand the difference between a business,
    intent, declarative, imperative, and ECA policy.

-
This
    would help us define intent interfaces, DSLs and models.
Expand DSL here. It's used a single time, so no need to have it in the acronym list.

- Section 5.2
The intro text mentions multiple times the "Solution and Actor" while the table mentions "Solution Intent Users".
Be consistent. See also my previous remark about the "user".

- improve this sentence:
    Therefore, Actors require different intent types,
    depending on their context, the so they participate in different use
    cases.

- section 5.3
Are there any loops in my network? => Are there any routing loops in my network?

- There are multiple bullet lists. Some time, you indent every words (btw, I wonder why) and sometimes you don't. Be consistent.

-
o to be notified about the problem before the user is aware
=> o to be notified about the problem before the end user is aware

-
o provide simple customer APIs for Value Added Services (operators)
=> o provide simple customer APIs for Value Added Services

-
    End-users cannot build their own services and policies without
    becoming technical experts and they must perform manual maintenance
    actions. Application developers and end-users/subscribers want to be
    able to:

End-users in which context? Carrier, DC, Enterprise?
In those 3, would an end-user build his own services? Maybe only in Carrier or an App developer in DC.
Is "end-users" the right term?
I refer to this table, which should really have a reference.
          +--------------------+------------------------------------+
          | Solutions          | Intent Users                       |
          +--------------------+------------------------------------+
          | Carrier Networks   | Network Operator                   |
          |                    | Service Designers                  |
          |                    | Service Operators                  |
          |                    | Customers/Subscribers              |
          +--------------------+------------------------------------+
          | DC Networks        | Cloud Administrator                |
          |                    | Underlay Network Administrator     |
          |                    | App Developers                     |
          |                    | End-Users                          |
          +--------------------+------------------------------------+
          | Enterprise Networks| Enterprise Administrator           |
          |                    | App Developers                     |
          |                    | End-Users                          |
          +--------------------+------------------------------------+

So maybe "customers/subscribers". That would inline with the following in section 5.4
	o Customer service intent

      		o   for customer self-service with SLA or add a service

      		o   for service operator orders
I would review all instance of user in the document to make sure you clearly define the term and clearly specify the related the "Solutions"

- the entire section 5.4, isn't a read from this table, in a different format, with some examples?
          +--------------------+------------------------------------+
          | Solutions          | Intent Users                       |
          +--------------------+------------------------------------+
          | Carrier Networks   | Network Operator                   |
          |                    | Service Designers                  |
          |                    | Service Operators                  |
          |                    | Customers/Subscribers              |
          +--------------------+------------------------------------+
          | DC Networks        | Cloud Administrator                |
          |                    | Underlay Network Administrator     |
          |                    | App Developers                     |
          |                    | End-Users                          |
          +--------------------+------------------------------------+
          | Enterprise Networks| Enterprise Administrator           |
          |                    | App Developers                     |
          |                    | End-Users                          |
          +--------------------+------------------------------------+

PROPOSAL, at the intro of section 5.4
	Next to the Intent Solutions and Intent Users, another way to categorize
	the intent is through the intent types. The following intent types need to
         be supported, in order to address the requirements from different solutions
	and intent users:

- section 6.2
This text is clearly related (and somehow redundant) to section 5.2.
Is this repeat intentional? Or the text should be moved?
If the former, clearly label it.
PROPOSAL: "Expanding on the introduction in section 5.2, ..."

-
Management personnel, such as network operators, may have the
=> Network operators may have the

- section 7
This chapter => This section
The three classifications in this draft => The three classifications in this document
be consistent between "Intent Solution" vs "intent solution" (throughout the entire doc)
Actually be consistent with capitalization throughout the entire doc. In section 7.1, I see both Solution Knowledge and solution knowledge

- section 7.1
Label the figure.
Btw, what do R and U stand for?

-

        7.3.1
        <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-intent-classification-02#section-7.3.1>.
        Intent Users and Intent Types

    The following table describes the Intent Users in Carrier Solutions
    and Intent Types with their descriptions for different intent users.

    +-------------+-------------+---------------------------------------+
    | Intent User | Intent Type |      Intent Type Description          |
    +-------------------------------------------------------------------+

 From the figure on p 20,
step 1 = carrier (coming from the title 7.3 Intent Classification for Carrier Solution)
step 2 = intent user
step 3 = intent type
step 4 = "Intent scope" from the figure on p. 20 but here it speaks about "Intent Type Description". Is this the same? Should be replaced by "Intent Scope"

I'm confused b/c 7.3.2 section title is "intent categories" while the content speaks about step 4 ("Intent Scope") to step 7
PROPOSAL at the beginning of section 7.3.1
	This addresses the step 1 (carrier), 2, and 3 from figure X

- section 7.3.2
PROPOSAL at the beginning of section 7.3.2
	This addresses the step 4 to 7 from figure X

What is the added value of mentioning C1, C2, Cx? These are just chocices of the previous table.
What is confusing to me. Are those values of Cx specific to Carrier, DC, Enterprise?
Let's take one example: Intent scope.
	* the figure mentions 4 options: Connectivity, Application, Security, QoS
	* I see from Carrier s 7.3.2
            Intent Scope: C1=Connectivity, C2=Security, C3=Application, C4=QoS
	* I see from DC:
            Intent Scope: C1=Connectivity, C2=Security, C3=Application, C4=QoS, C5=Storage C6=Compute
	* I see for Enterprise:
            Intent Scope: C1=Connectivity, C2=Security, C3=Application, C4=QoS
Good, there are not different per Carrier, DC, ENT and they are not overlapping.
I guess/hope that the properties are shared for DC, ENT, Carrier.
If this is the case, clearly mention it.

                                    +--------------------------------+
                                    |Carrier           Enterprise    |
                                +-->|Data Center                     |
                                |   +--------------------------------+
                                |   +--------------------------------+
                                |   |Customer                        |
                  +----------+  |   |Network or Service Operator     |
                +>+Solutions +--+   |Application Developer           |
                | +----------+   +->|Enterprise Administrator        |
                |                |  |Cloud Administrator             |
                | +----------+   |  |Underlay Network Administrator  |
                +>+Intent    +---+  +--------------------------------+
                | |User      |      +--------------------------------+
                | |Types     |      |Customer Service Intent         |
                | +----------+      |Strategy Intent                 |
                | +----------+      |Network Service Intent          |
                +>+Intent    +----->|Underlay Network Service Intent |
       +------+ | |Type      |      |Network Intent                  |
       |Intent+-+ +----------+      |Underlay Network Intent         |
       +------+ |                   |Operational Task Intent         |
                | +----------+      |Cloud Management Intent         |
                +>+Intent    +---+  |Cloud Resource Management Intent|
                | |Scope     |   |  +--------------------------------+
                | +----------+   |  +--------------------------------+
                |                +->|Connectivity      Application   |
                | +----------+      |Security          QoS           |
                +>+Network   +---+  +--------------------------------+
                | |Scope     |   |  +--------------------------------+
                | +----------+   |  |Radio Access      Branch        |
                |                +->|Transport Access  SD-WAN        |
                | +----------+      |Transport Aggr.   VNF      PNF  |
                +>+Abstrac   +----+ |Transport Core    Physical      |
                | |tion      |    | |Cloud Edge        Logical       |
                | +----------+    | |Cloud Core        Campus        |
                | +----------+    | +--------------------------------+
                +>+Life      |    | +--------------------------------+
                  |cycle     +--+ +>|Technical         Non-Technical |
                  +----------+  |   +--------------------------------+
                                |   +--------------------------------+
                                +-->|Persistent        Transient     |
                                    +--------------------------------+

And complete the picture: Intent Scope misses Storage Compute

- section 7.4.1
The intent user categories don't match the first table (while it does for the carrier)
          | DC Networks        | Cloud Administrator                |
          |                    | Underlay Network Administrator     |
          |                    | App Developers                     |
          |                    | End-Users                          |

- section 7.4.3
OLD:
    +---------+-------------+-----------------+-----+-----+-----+-----+
    |Intent   | Intent      | Intent          | DCN | DCN | ABS | L-C |
    |User     | Type        | Scope           | Res | Net |     |     |
    |         |             +-----------------+-----+-----+-----+-----+
    |         |             |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
    +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |Customer | Customer    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    |/Tenants | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    |         +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NEW:
    +---------+-------------+-----------------+-----+-----+-----+-----+
    |Intent   | Intent      | Intent          | DCN | DCN | ABS | L-C |
    |User     | Type        | Scope           | Res | Net |     |     |
    |         |             +-----------------+-----+-----+-----+-----+
    |         |             |C1|C2|C3|C4|C5|C6|C1|C2|C1|C2|C1|C2|C1|C2|
    +---------+-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |Customer | Customer    |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    |/Tenants | Service     |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    |         | Intent      |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
    |         +-------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

- section 7.5.1

    +--------------+-------------+-------------------------------------+
    | Intent User  | Intent Type |    Intent Type Description          |
    +--------------+---------------------------------------------------+
    | End-User     | Customer    | Enterprise End-User Self-Service or |
    |              | Service     | Applications, Enterprise may have   |
    |              | Intent      | multiple types of End-Users.        |
    |              |             | Example: Request access to VPN      |
    |              |             | service.                            |
    |              |             | Request video conference between    |
    |              |             | user A and B.                       |
    |              +---------------------------------------------------+
doesn't match with, in section 7.5.2
    +---------------+-------------+-----------+--------+-----+-----+
    | Intent User   | Intent Type | Intent    | Net    | ABS | L-C |
    |               |             | Scope     |        |     |     |
    |               |             +-----------+--------+-----+-----+
    |               |             |C1|C2|C3|C4|C1|C2|C3|C1|C2|C1|C2|
    +---------------+-------------+--+--+--+--+--+--+--+--+--+--+--+
    | End-User      | End-User    |  |  |  |  |  |  |  |  |  |  |  |
    |               | Intent      |  |  |  |  |  |  |  |  |  |  |  |
    |               +-------------+--+--+--+--+--+--+--+--+--+--+--+

Note: there are more mismatches between the two

- Also double-check the table against the 7.3 introduction.