Subject: [nmrg] draft-irtf-nmrg-ibn-concepts-definitions: feedback

From: Benoit Claise <[email-masked]>
Date: Sun, 7 Mar 2021 18:09:45 +0100

Dear all,

I wanted to review, part of the RG Last Call, the 
draft-irtf-nmrg-ibn-intent-classification.
As a first step, I started by reviewing 
draft-irtf-nmrg-ibn-concepts-definitions.
I understand that the Last Call for this document, so up to chairs to 
decide what to do with this feedback.
I like this document. Nevertheless, here is some feedback. And sorry if 
this has been already been discussed on the mailing list (I'm not 
completely up to date)

-
OLD:
  This document is a product of the IRTF Network Management Research 
Group (NMRG). It reflects the consensus of the RG, receiving reviews 
from 8 members and explicit support from 14 (beyond the authors). It is 
published for informational purposes.
NEW:
   This document is a product of the IRTF's Network Management Research 
Group.

Justification
Obviously, it reflect the consensus. If not, we have a problem :-)
Mentioning the number of supporting persons will not add any more weight 
of this document, once published
And finally, the proposed sentence would be inline with other NMRG RFCs

-
"Generate in-situ OAM data and network telemetry across for later 
offline analysis whenever significant fluctuations in latency across a 
path are observed."

Generate in-situ OAM data and network telemetry across... what?

-
o "When interface utilization exceeds a specific threshold, emit an 
alert." This would be a rule that can help support network automation, 
but a simple rule is not an intent.

I wanted to proposed the following text:
   o  "When interface utilization exceeds a specific threshold, emit an
       alert."  This would be a rule that can help support network
       automation, or the intent automation, but a simple rule is not an intent.

Justification:
This example can certainly help automation, but actually, this simple 
rule will most likely be used in an intent realization, which of course 
requires some network automation.
Then I was thinking that all the examples in the series fall under the 
same logic.

    o  "Configure a given interface with an IP address."
    o  "When interface utilization exceeds a specific threshold, emit an
       alert."
    o  "Configure a VPN with a tunnel from A to B over path P."
    o  "Deny traffic to prefix P1 unless it is traffic from prefix P2."

So I guess this remark ("will most likely be used in an intent 
realization, which of course requires some network automation." should 
probably be generic for the 4 examples.

New proposal (I would add a sentence to this paragraph

    Accordingly, an IBN is a network that can be managed using intent.
    This means that it is able to recognize and ingest intent of an
    operator or user and configure and adapt itself according to the user
    intent, achieving an intended outcome (i.e., a desired state or
    behavior) without requiring the user to specify the detailed
    technical steps for how to achieve the outcome.  Instead, the IBN
    will be able to figure out on its own how to achieve the outcome.
    Similarly, an IBS is a system that allows users to manage a network
    using intent.  Such a system will serve as a point of interaction
    with users and implement the functionality that is necessary to
    achieve the intended outcomes, interacting for that purpose with the
    network as required.

ADDITION

    Potential examples of configuration and adaptation imperative constructs
    have been provided earlier in this section: "Configure a given interface
    with an IP address", "When interface utilization exceeds a specific threshold,
    emit an alert.", "Configure a VPN with a tunnel from A to B over path P.",
    "Deny traffic to prefix P1 unless it is traffic from prefix P2."

Note: I was debating with myself whether to add "imperative" in the 
previous sentence.
As an extra note, I believe that the draft would benefit from one or two 
sentences opposing declarative vs imperative, somewhere in the intro. 
You know, something as simple as;
     - Declarative: You will say what you want, but not how
     - Imperative: You describe how to do something

- Section 4.1
This section discusses intent definitions and concepts:
     - starting from the ANIMA intent definition,
     - then going into what intent is, its concept, some examples (and 
counter examples)
     - then including the last paragraph that introduces yet another 
definition
... while we have THE Intent definition in the terminology section.... 
which is NOT referred to a single time into this section. This looks 
weird to me.
It might worth stressing, as a last paragraph of 4.1, something such as...

     While there are multiple intent interpretations, ...
     OR: There are some existing intent definitions, deemed incomplete, 
therefore ...
     OR: For all the reasons mentioned in this section, ...

     ... this document focuses on the following Intent definition (as 
mentioned in the terminology section):
     A set of operational goals (that a network should meet) and 
outcomes (that a network is
     supposed to deliver), defined in a declarative manner without 
specifying how to achieve or
     implement them.

- section 4.2.3

    o  A service model is a data model that is used to describe instances
       of services that are provided to customers.  A service model has
       dependencies on lower-level models (device and network models)
       when describing how the service is mapped onto the underlying
       network and IT infrastructure.  Instantiating a service model
       requires orchestration by a system; the logic for how to
       orchestrate/manage/provide the service model and how to map it
       onto underlying resources is not included as part of the model
       itself.

A reference to RFC8199 would be helpful IMO.
Proposal to add a last sentence to this paragraph: "see RFC8199 for further details."

- editorial
OLD:

       Which algorithm or rules to apply can be automatically "learned/derived
       from intent" by the intent system.

NEW:
       Which algorithm or rules to apply can be automatically "learned/derived
       from intent" by the IBS.

Note: IBS or Intent-Based System => the document is not consistent at all.

-      Autonomy and Supervision.  A desirable goal for an intent-based
        system is to offer a high degree of flexibility and freedom on
        both the user side and system side, e.g., by giving the user the
        ability to express intents using the user's own terms, by
        supporting different forms of expression of intents and being
        capable of refining the intent expressions to well-formed and
        exploitable expressions.

In the sentence above, I would have replace user by (network) operator, right?
Because we speak about networking in this document and because we don't want to be confused by the end user/customers.
Then I reviewed the different occurrences of users and operators and I have to admit that I sometimes don't know which distinction you make between the two terms.

Like for example in the sentences:
o It provides data abstraction: users and operators do not need to be 
concerned with low-level device configuration and nerd knobs.
o It provides functional abstraction from particular management and 
control logic: users and operators do not need to be concerned even with 
how to achieve a given intent.
There are some examples I could have used.

This is even more confusing when I see this sentence, with a new term 
"administrator":

    Intent fulfillment is concerned with the functions that take intent
    from its origination by a user (generally, an administrator of the
    responsible organization)

As it seems that, by user, you meant the IBN user, so the administrator 
or network operator if we speak about IBNetworking. Figure 1 seems to 
support that view, but "user" can still be confused by "end 
user"/"customers".
The advice is review all instances of user/administrator/operator. You 
should use those terms adequately and consistently throughout the 
document. If still confusing, you might create a/some definition(s)

- There is a single sentence that uses the key words "MUST", "MUST NOT", 
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 
"NOT RECOMMENDED", "MAY", and"OPTIONAL" :

    o  Human-tailored network interaction: IBN SHOULD speak the language
       of the user as opposed to requiring the user to speak the language
       of the device/network.

Is this really worth it to use RFC 2119 keywords for just one sentence? And (and old debate in the IETF), what does a requirement with SHOULD actually mean?

- Editorial
Many cases would also invove => involve

- Section 7:
    o  The "inner" intent control loop between IBS and Network Operations
       space is completely autonomic and does not involve any human in
       the loop.  It involves automatic analysis and validation of intent
       based on observations from the network operations space.  Those
       observations are fed into the function that plans the rendering of
       networking intent in order to make adjustments as needed in the
       configuration of the network.  The loop addresses and counteracts
       any intent drift that may be occuring, using observations to
       assess the degree of the network's intent compliance and
       automatically prompting actions to address any discrepancies.
       Likewise, the loop allows to assess the effectiveness of any
       actions that are taken in order to continuously learn and improve
       how intent needs to be rendered in order to achieve the desired
       outcomes.

I would add the well-known "closed loop automation" in industry term somewhere in this paragraph.

Thans and regards, Benoit