Re: [Ibnemo] [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

John Strassner <John.sc.Strassner@huawei.com> Mon, 20 July 2015 12:48 UTC

Return-Path: <John.sc.Strassner@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 869D21A87C5; Mon, 20 Jul 2015 05:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.31
X-Spam-Level:
X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, 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 T5zHRmUsWYKQ; Mon, 20 Jul 2015 05:48:35 -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 721141A8785; Mon, 20 Jul 2015 05:48:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYY64611; Mon, 20 Jul 2015 12:48:00 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 13:47:59 +0100
Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.51]) by SJCEML702-CHM.china.huawei.com ([169.254.4.184]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 05:47:50 -0700
From: John Strassner <John.sc.Strassner@huawei.com>
To: John Strassner <strazpdj@gmail.com>, Susan Hares <shares@ndzh.com>
Thread-Topic: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time
Thread-Index: AQHQwCHCBRkgFfJVu0ymriWlLAvNbJ3kTohA
Date: Mon, 20 Jul 2015 12:47:50 +0000
Message-ID: <B818037A70EDCC4A86113DA25EC0209820117071@SJCEML703-CHM.china.huawei.com>
References: <C0E0A32284495243BDE0AC8A066631A818C258DF@szxeml557-mbs.china.huawei.com> <C0E0A32284495243BDE0AC8A066631A818C45663@szxeml557-mbs.china.huawei.com> <C0E0A32284495243BDE0AC8A066631A818C71DF4@szxeml557-mbs.china.huawei.com> <5FD31D8EDBF4EC468B36D86F04FDB2E8780A102F@nkgeml507-mbs.china.huawei.com> <CAJwYUrHTyQt_eJEv_=ADvoHE7RvNWGTsyr8fVuokzvWaDaxd9w@mail.gmail.com>
In-Reply-To: <CAJwYUrHTyQt_eJEv_=ADvoHE7RvNWGTsyr8fVuokzvWaDaxd9w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.67.124]
Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC0209820117071SJCEML703CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/iFwowTjZ4hkj2Kj4w16LonJjrL4>
Cc: "ibnemo@ietf.org" <ibnemo@ietf.org>, "supa@ietf.org" <supa@ietf.org>, Susan Hares <shares@ndzh.com>, "Scott O. Bradner" <sob@sobco.com>
Subject: Re: [Ibnemo] [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time
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: Mon, 20 Jul 2015 12:48:39 -0000

Sue:
> The premise of Nemo is still the 80/20 rule – of trying to provide
> a simple model for 80% of the application with 20% of the
> commands.
<jcs>
I understand, but what does this have to do with the previous email?
</jcs>
> We posit two points:
>       1)  IBNemo’s 15 specific commands for targeted use cases are
>            better than the generic commands.
>     2)  IBNemo’s 15 specific commands are better than NETCONF
>         or RESTCONF commands
<jcs>
I understand, but what does this have to do with the previous email?
That email had 4 points:
    1) flatter, simpler object model
    2) targets of policy
    3) NEMO does not define a policy model
    4) NEMO does not support ECA (and a larger issue, why is NEMO's
         declarative language implemented using imperative controls)
</jcs>
> In order to confirm our assumptions, we have proposed to prove
> this for specific use cases (see hares-.   This work includes checks
> on the user’s range of inputs, the expected output, and the
> prototype IBNemo code, and looks at the SUPA intent policy.
> The user’s input includes:  use cases and potential intent policy.
 <jcs>
SUPA intent policy is either propositional logic or first order logic.
NEMO intent policy is condition-action. This aren't compatible
in their native forms.
</jcs>
> What’s the benefit for IB-NEMO for SUPA’s work?   SUPA’s
> defining generic policy information models for ECA and Intent.
> While we have many examples of ECA policy over the last 30
> years in IETF, we do not have many examples of Intent policy.
> IB-Nemo will benefit from SUPA’s definition and design work.
> One thing that would be useful, is to post how SUPA’s model
> can guide IB-Nemo’s user policy or IB-Nemo’s translation of
> user policy into network-wide policy in the network
> management system.
<jcs>
That's nice to hear. We could of course "short-circuit" the ECA
policy rule to be a simpler CA policy rule. Constraints would be
handled in metadata, so this may be a problem for NEMO (I
don't see metadata in the NEMO model).

However, as stated above, our definitions of intent are very
different. So I'm not sure how this helps NEMO.
</jcs>
John

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of John Strassner
Sent: Thursday, July 16, 2015 4:47 PM
To: Xiayinben
Cc: ibnemo@ietf.org; supa@ietf.org; Susan Hares; Scott O. Bradner; Tina TSOU
Subject: Re: [Supa] 答复: SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

What, exactly, are you not agreeing with in the following sentence:
"NEMO uses a flatter, simpler object model with fewer objects to represent targets of policy. NEMO does not define a policy model, and does not support ECA policies. NEMO uses a condition-action paradigm to execute its policy commands.”

Lets take the sentence point by point.

#1 FLATTER, SIMPLER OBJECT MODEL
NEMO defines three objects: node, link, and flow. How many managed objects do G.805 or G.809, let alone the average MIB, define? It is irrelevant that you can define subclasses of node - the user has to do all the work, and this guarantees non-interoperable solutions.

#2 TARGETS OF POLICY.
You just said that you define an object model and an operation model. Both would be policy targets, by any standard CA or ECA definition.

#3. NEMO DOES NOT DEFINE A POLICY MODEL
You said: "NEMO doesn’t NEED to define a new policy model, because industry already has well defined policy model(such as RFC 3460). We will not rebuild a wheel." Not only did you agree that you aren't defining a policy model, but you appear to be unaware of why RFC3460 is badly broken. So yes, you do need to rebuild this.

#4. DOES NOT SUPPORT ECA POLICIES. NEMO USES A CONDITION-ACTION PARADIGM TO EXECUTE ITS POLICY COMMANDS.
It is inconceivable to me how you could disagree with this. From draft-xia-sdnrg-nemo-language-02, Section 5.1: "All the policies follow the same pattern "when <condition>, to execute <action>, with <constraint>", and can be applied to any entity." This is NOT an ECA policy; any useful implementation of CA or ECA allows constraints - EXCEPT RFC3460.


John


On Wed, Jul 15, 2015 at 6:38 PM, Xiayinben <xiayinben@huawei.com<mailto:xiayinben@huawei.com>> wrote:
Hi Tina and all,

I do not agree with your word about NEMO/ibnemo in page 8.

Your sentence: “NEMO uses a flatter, simpler object model with fewer objects to represent targets of policy. NEMO does not define a policy model, and does not support ECA policies. NEMO uses a condition-action paradigm to execute its policy commands.”
The truth is that NEMO define an object model and an operation model to represent network abstraction for intent NBI, because NEMO’s target is a simplified network interface(Intent NBI) for application even for ender-user.  policy is only a type of operation in Intent NBI. NEMO doesn’t NEED to define a new policy model, because industry already has well defined policy model(such as RFC 3460). We will not rebuild a wheel.

Your sentence: “IBNemo – 'intent' means I express a desired topology and its properties.”
The truth  is that Ibnemo –‘Intent’ means user simply and intuitively  express demands of network resource and/or network behavior. Topology and its properties are typical type of network resource, so they are part of network intent, but not all.

Best regards,
Yinben
发件人: Supa [mailto:supa-bounces@ietf.org] 代表 Tina TSOU
发送时间: 2015年7月15日 15:42
收件人: Scott O. Bradner; Susan Hares
抄送: supa@ietf.org<mailto:supa@ietf.org>
主题: Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear all,

Enclosed pls find the updated slides based on Monday July 13 call discussion, only page 8 added.


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Friday, July 10, 2015 4:31 PM
To: Scott O. Bradner; Susan Hares
Cc: supa@ietf.org<mailto:supa@ietf.org>
Subject: Re: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time

Dear Scott and Sue,

Regarding “2.2. Relationship to other WGs (Scott/Sue et al, 5 minutes)” (Times are the ones in the call next week – not the BOF), attached is a quick update based on Jun’s presentation in last BoF, according to the discussion after Dallas.

Feel free to use or update the slides.


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Tuesday, July 07, 2015 7:05 AM
To: supa@ietf.org<mailto:supa@ietf.org>
Subject: [Supa] SUPA call: 7:30-8:30am, Monday, July 13, San Francisco time


Dear all,



Below is the draft agenda and logistics for next call during 7:30-8:30am, Monday, July 13, San Francisco time.



Look forward to talking to many of you at the meeting.



----------

1. Note Well, logistics, agenda bashing (chairs, 5 min)



2. Slides Preparation for the BoF (Times are the ones in the call next week – not the BOF)



2.1. Goals, Framework, Examples (Max, Oscar (Luis) et al, 10 minutes)

2.2. Relationship to other WGs (Scott/Sue et al, 5 minutes)

2.3. Information Model Overview (John et al, 5 minutes)

2.4. Data Model Overview (Andy et al, 5 minutes)

2.5. Charter presentation (Dan/Juergen et al, 10 minutes)

2.6. Discussion on whether the progress assessment implies going forward changes to the charter (all, 15 minutes)

2.7. Questions to the audience (chairs, 10 minutes)



-----------





Join WebEx meeting<https://ietf.webex.com/ietf/j.php?MTID=m23e113c8822a0970e0e779383ab09322>

Meeting number: 646 022 302

Meeting password:       2015





Join by phone

1-877-668-4493<tel:1-877-668-4493> Call-in toll free number (US/Canada)

1-650-479-3208<tel:1-650-479-3208> Call-in toll number (US/Canada)

Access code: 646 022 302

Toll-free calling restrictions<http://www.webex.com/pdf/tollfree_restrictions.pdf>







Can't join the meeting? Contact support.<https://ietf.webex.com/ietf/mc>



IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.





Thank you,

Dan & Tina

_______________________________________________
Supa mailing list
Supa@ietf.org<mailto:Supa@ietf.org>
https://www.ietf.org/mailman/listinfo/supa



--
regards,
John