Subject: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions

From: John Strassner <[email-masked]>
Date: Sat, 20 Jun 2015 14:15:22 -0700

Hi all,

The following is a set of questions designed to better define the scope
of NEMO. This is email #2 in my review series.

*1. Who is the user of NEMO?*
The four NEMO I-Ds define different users of NEMO. Specifically:

    draft-zhou-netmod-intent-nemo-00 defines a YANG data model for
      "network intent", but does not define precisely what network intent
      is or who is supposed to use this document.
      *Assumption: network administrator*

    draft-xia-sdnrg-service-description-language-02 says "A service
      description language is needed to enable customers to easily
      describe their diverse intent". I sincerely doubt that the majority
      of **customers** would use a service description language. I am
      assuming that the service description language is instead used
      by either the operator of the service, or the interface between
      the customer and the system providing the service, in order to
      normalize different customer requests.
      *Assumption: network operator, or a programmer of the*
*        SDN controller*

    draft-xia-sdnrg-nemo-language-02 describes a simple language
      that "enables network users/applications to describe their
      demands for network resources, services, and logical operations
      in an intuitive way." The draft defines a network user as a
      network administrator. This assumes that the network administrator
      is motivated to change from their existing modus operandi (e.g.,
      CLI, TL1, netconf/YANG, TCL, ...) to a higher-level language.
      *Assumption: network administrator*

    draft-xia-ibnemo-icim-00 says: "According to this information model,
      network intent model is put forward which can satisfy users' need in
      different layers [sic], such as, end-users, business developers, and
      network administers [sic]."
      *Assumption: everyone*

The drafts need to agree on who the user of NEMO is.

*2. Who is the user of Intent?*
Intent is **supposed** to be expressed by a Customer or EndUser (the
roles are different!). This does not match the above four I-Ds:

  - Why would a *network administrator *use an intent-based system?
    They live in the world of CLI, YANG, expect and TCL scripts.
  - Why would a *programmer of an SDN Controller* use an intent-
    based system? The programmer may have to translate intent to a
    form that can be used to program the SDN Controller, but why
    would they use intent to program the SDN Controller? Furthermore,
    note that the language draft explicitly says that "All the policies
    follow the same pattern "when <condition>, to execute
    <action>, with <constraint>". *This is NOT a declarative statement!*
*    Note that the ID claims that the language is declarative.** It is*
*    also a merging of ECA with CA, which is not good (this will be*
*    discussed in a future email).*
  - The goal of the ICIM model (making intent available for end users,
    business developers, and network administrators) is NOT
    ACHIEVABLE. This was proved by having to create the policy
    continuum in the first place. These three constituencies speak
    completely different languages, and use completely different
    terminology with different concepts. There are arguably many more
    important actors (e.g., an application developer) that were not
    included that have additional differences that exacerbate this.

*3. Why are Flow and Link part of Intent?*
Intent is **supposed** to be used by a Customer or EndUser (repeated
on purpose). I find it very unlikely that either would have any idea what
a Link is, much less a Flow.

*4. Why is a Node a part of Intent?*
If intent is really a declarative statement, then why should the Customer
or EndUser be concerned about nodes in the system?

Example 1: I want my headache to stop. I did not *prescribe* the use of
aspirin. I didn't even prescribe the use of a drug (perhaps acupuncture
would be a better solution).

Example 2: I need to get to the airport by 6pm (it's currently noon, and
the airport is nominally a 45 minute taxi ride). I didn't specify "take the
following route", or even to use a car.

So why do I have to prescribe a node to define intent? *This is just a*
*crutch to make it easier for the compiler to translate to a form*
*that the rest of the system can understand*. The Customer or
EndUser should NOT be burdened with these concepts.

*5. If Node, Flow, and Link are really Intent, then who is the User?*
If these concepts are really intent, then I do NOT think that the Customer
is the user of intent. Rather, the user of intent is someone that
understands networks.

What is the compelling reason for a network administrator to use intent
instead of the existing mechanisms that they use? I have no idea....

-- 
regards,
John

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Mon, 22 Jun 2015 06:07:13 +0000

Hi John,

I’m working with your emails, since they provide a lot of very valuable guidance. Let me try to answer one of the simple questions.

We are still seeing service request times of days (look at the recent talks at TCN’15) and we are expected to make them go drastically down.
Looking at how things are evolving in networking in general, I sincerely think that if we want things to get better, network admins have to start leaving the expect/TCL turf. We all know that maintaining these scripts is a pain and that’s why some of us are looking somewhere else.
And that’s where SDN kicks in.
(OK, yes, some people say scripts are software, but c’on … Script Driven Networking is like using assembler. I did a lot of that in the Z80 and 8088 times.)

I as a network admin would like to get some level of abstraction. For example, I would like to say ‘router’ as a collection of well-known building blocks and with a well-defined behaviour. Whether it ends up being a Cisco, a Juniper or a you name it should not be my concern. The typical network admin sitting in the NOC doesn’t have to be impacted by a deal done somewhere up in the management floors to get routers cheaper.

Same goes for other types of nodes and something similar also holds for links. I don’t want to be bothered by the specifics of programming a link, but I want to be aware of its presence. And here, again, supplier independence,etc.

And since we are already here, why not having design patterns? Who always starts from scratch when designing networks and then proceeds on a node-by-node basis? Doesn’t it make sense to replicate blocks you trust to work for a specific purpose?

This is why I find this IBNEMO stuff valuable. Yes, we need some focusing and shaping here and there, and there is where your valuable comments kick in.

Best, /PA

---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler
De: John Strassner <[email-masked]<mailto:[email-masked]>>
Fecha: sábado, 20 de junio de 2015 23:15
Para: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions

Hi all,
…
  - Why would a network administrator use an intent-based system?
    They live in the world of CLI, YANG, expect and TCL scripts.
…
--
regards,
John

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Zhoutianran <[email-masked]>
Date: Wed, 24 Jun 2015 08:54:58 +0000

Hi John,

Thanks for your part 2 comments.
Let me try to answer your questions.

1.  Who is the user of NEMO?
There is synchronization problem of the four drafts, since the discussion and improving keep on going. But I think they have the same target users, no matter in what form they are(data model and information model). IBNEMO will provide intent based northbound model and interface for the SDN controller/orchestrator. So the user of NEMO would be the user of intent.

2. Who is the user of Intent?
It is similar to the question why a programmer use Java/C not assembly language. Before C, all the programmer use assembly language. You cannot say that’s what they have to do. Just like your words, “They(network administrator) live in the world of CLI, YANG, expect and TCL scripts”, which I do not think so. If there’s anything that can make the operation easier, why not? The only thing that I think will not change is the responsibility of each role. So each role can talk about its intent.

I agree different role will speak with different languages. But the difference could be the specific data models for each role. And that’s what I think we can work on to define a set of intent data models by roles. This does not resist us to conclude the consistent super classes(in ICIM) which are shared by different roles.

3. Why are Flow and Link part of Intent?
4. Why is a Node a part of Intent?
Combine the answer to question 3 and 4, because they are both about the intent object.
Object is part of intent to make expression clear. Just like your intent “I want my headache to stop”, the headache is a kind of object but in real word.
In network domain, I think the object should be no more than node, connection and flow. As I mentioned previously, those are very abstracted super class compared to specific data models. For end-users who may have high level requirement, e.g., intent could be “set up call connection with Bob”. Here “connection” works as part of the end-user intent.

5. If Node, Flow, and Link are really Intent, then who is the User?
I think I have answer this question in previous statements. One additional reply to “What is the compelling reason for a network administrator to use intent instead of the existing mechanisms that they use?”. How about to reduce/easy the operation?

Best,
Tianran

From: Ibnemo [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, June 21, 2015 5:15 AM
To: [email-masked]
Subject: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions

Hi all,

1. Who is the user of NEMO?
The four NEMO I-Ds define different users of NEMO. Specifically:

    draft-zhou-netmod-intent-nemo-00 defines a YANG data model for
      "network intent", but does not define precisely what network intent
      is or who is supposed to use this document.
      Assumption: network administrator

      Assumption: network operator, or a programmer of the
        SDN controller

      Assumption: network administrator

      Assumption: everyone

2. Who is the user of Intent?
Intent is **supposed** to be expressed by a Customer or EndUser (the
roles are different!). This does not match the above four I-Ds:

  - Why would a network administrator use an intent-based system?
    They live in the world of CLI, YANG, expect and TCL scripts.
  - Why would a programmer of an SDN Controller use an intent-
    based system? The programmer may have to translate intent to a
    form that can be used to program the SDN Controller, but why
    would they use intent to program the SDN Controller? Furthermore,
    note that the language draft explicitly says that "All the policies
    follow the same pattern "when <condition>, to execute
    <action>, with <constraint>". This is NOT a declarative statement!
    Note that the ID claims that the language is declarative. It is
    also a merging of ECA with CA, which is not good (this will be
    discussed in a future email).
  - The goal of the ICIM model (making intent available for end users,
    business developers, and network administrators) is NOT
    ACHIEVABLE. This was proved by having to create the policy
    continuum in the first place. These three constituencies speak
    completely different languages, and use completely different
    terminology with different concepts. There are arguably many more
    important actors (e.g., an application developer) that were not
    included that have additional differences that exacerbate this.

3. Why are Flow and Link part of Intent?
Intent is **supposed** to be used by a Customer or EndUser (repeated
on purpose). I find it very unlikely that either would have any idea what
a Link is, much less a Flow.

4. Why is a Node a part of Intent?
If intent is really a declarative statement, then why should the Customer
or EndUser be concerned about nodes in the system?

Example 1: I want my headache to stop. I did not prescribe the use of
aspirin. I didn't even prescribe the use of a drug (perhaps acupuncture
would be a better solution).

So why do I have to prescribe a node to define intent? This is just a
crutch to make it easier for the compiler to translate to a form
that the rest of the system can understand. The Customer or
EndUser should NOT be burdened with these concepts.

5. If Node, Flow, and Link are really Intent, then who is the User?
If these concepts are really intent, then I do NOT think that the Customer
is the user of intent. Rather, the user of intent is someone that
understands networks.

--
regards,
John