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

Zhoutianran <zhoutianran@huawei.com> Wed, 24 June 2015 08:55 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: ibnemo@ietfa.amsl.com
Delivered-To: ibnemo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACEC1B3246 for <ibnemo@ietfa.amsl.com>; Wed, 24 Jun 2015 01:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level:
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei_myWgRfGQ1 for <ibnemo@ietfa.amsl.com>; Wed, 24 Jun 2015 01:55:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB4C1B3241 for <ibnemo@ietf.org>; Wed, 24 Jun 2015 01:55:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUH08289; Wed, 24 Jun 2015 08:55:06 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Jun 2015 09:55:03 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 24 Jun 2015 16:54:59 +0800
From: Zhoutianran <zhoutianran@huawei.com>
To: John Strassner <strazpdj@gmail.com>, "ibnemo@ietf.org" <ibnemo@ietf.org>
Thread-Topic: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions
Thread-Index: AQHQq549n6zBmP1Dw0erCGXkGJhHTJ27OwFg
Date: Wed, 24 Jun 2015 08:54:58 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F2166BC3569@nkgeml512-mbx.china.huawei.com>
References: <CAJwYUrHSY6KyeoyWa49-OeWek5W6eF486kWYm2qvD5VKMGWmxg@mail.gmail.com>
In-Reply-To: <CAJwYUrHSY6KyeoyWa49-OeWek5W6eF486kWYm2qvD5VKMGWmxg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.21]
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2166BC3569nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/MgqboQLesOg9JpA4rPTSiCUFovA>
Subject: Re: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions
X-BeenThere: ibnemo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." <ibnemo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ibnemo/>
List-Help: <mailto:ibnemo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2015 08:55:14 -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:ibnemo-bounces@ietf.org] On Behalf Of John Strassner
Sent: Sunday, June 21, 2015 5:15 AM
To: ibnemo@ietf.org
Subject: [Ibnemo] Clearing up some misconceptions, part 2: Technical Scope Questions

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