From nobody Thu Feb 5 01:32:04 2015 Return-Path: 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 DCA5B1A0140 for ; Thu, 5 Feb 2015 01:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nk4aIY0JtozA for ; Thu, 5 Feb 2015 01:31:59 -0800 (PST) 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 7EAD41A007F for ; Thu, 5 Feb 2015 01:31:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSD30079; Thu, 05 Feb 2015 09:31:44 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 5 Feb 2015 09:31:40 +0000 From: Georgios Karagiannis To: Susan Hares Thread-Topic: some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTA== Date: Thu, 5 Feb 2015 09:31:40 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:32:02 -0000 Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios From nobody Fri Feb 6 18:12:10 2015 Return-Path: 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 458E41A038C; Fri, 6 Feb 2015 18:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.994 X-Spam-Level: X-Spam-Status: No, score=-98.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX_IMAGE=2.305, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, USER_IN_WHITELIST=-100] autolearn=no 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 wqf28XJYbIsF; Fri, 6 Feb 2015 18:09:12 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB81A00F5; Fri, 6 Feb 2015 18:09:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'John Strassner'" , "'Dacheng Zhang'" , , References: <02c701d03f9a$48b96f10$da2c4d30$@ndzh.com> <064501d04017$9cd5b0e0$d68112a0$@ndzh.com> In-Reply-To: Date: Fri, 6 Feb 2015 21:08:50 -0500 Message-ID: <02a701d0427b$05dd1550$11973ff0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_02A8_01D04251.1D0E3940" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGM6wailn5Aiu4DF35g6vJ9te36YAIqgQJWAaIcO8oDEwTWip00HwdA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Linda Dunbar' Subject: Re: [Ibnemo] [I2nsf] draft-zhang-gap-analysis-00 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 02:09:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02A8_01D04251.1D0E3940 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02A9_01D04251.1D0E3940" ------=_NextPart_001_02A9_01D04251.1D0E3940 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable John:=20 =20 Thank you for your interested in the RBAC qualities of the IB-Nemo as we = discuss vNSF nodes. You state =E2=80=9CRBAC implies a role for a first = class object=E2=80=9D. Below is a model definition for the Intent-Based = Nemo DSL. =20 =20 Let me ask a few more questions.=20 =20 The Intent Based Nemo has a DSL that passes across a RESTful interface = (over http) between an application client and controller with a Nemo = Engine inside. The Nemo Engine stores a network model which allow the = controller to understand the applications desire regarding the creation = of the virtual network. This model contains a top-level structures of = node, link, and actions. =20 =20 In your definition, does the node, link and actions constitute top level = structures that are =E2=80=9Croles=E2=80=9D for objects within the = Intent-based prescription for an application network. Based on these = roles, Intent-Based Nemo uses controller contextual information to map = the virtual application-level topology to a network topology via = specific SDN controller commands. These commands could be sent via an = I2RS client (sdn controller) to the I2RS Agent in a node. It could also = be sent from a client sending a netconf configuration stream to a node.=20 =20 If the node top-level entity, is associated with a policy set by the = behavior command. Is this RBAC or something else?=20 =20 Sue =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Intent-Based Nemo DSL=20 =20 :=3D | | = :=3D | | = =20 < resource_access_cmd> :=3D | | | = | | = :=3D | | | = | = :=3D | :=3D | < transaction _end> =20 From: John Strassner [mailto:John.sc.Strassner@huawei.com]=20 Sent: Wednesday, February 04, 2015 4:12 PM To: Susan Hares; 'Dacheng Zhang'; John Strassner; i2nsf@ietf.org Cc: Linda Dunbar Subject: RE: [I2nsf] draft-zhang-gap-analysis-00 =20 Sue: =20 Correction: I did NOT say that you =E2=80=9Cdo not understand ACL, RBAC, = ABAC, PBAC=E2=80=9D. In fact, I didn=E2=80=99t even mention ACL in my = reply. =20 The point is that in RBAC, a role is a first-class object. Your draft = did not mention Role, and in your reply, you say that =E2=80=9CRole is a = logical network role for a node and not a security role=E2=80=9D. This = does not meet the needs of RBAC, since RBAC requires that roles are = managed objects, not concepts. =20 regards, John =20 Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD logo.gif =20 Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com =20 =20 =20 From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, February 03, 2015 5:12 PM To: 'Dacheng Zhang'; i2nsf@ietf.org Cc: Linda Dunbar Subject: Re: [I2nsf] draft-zhang-gap-analysis-00 =20 Dacheng:=20 =20 Read John Strasser=E2=80=99s email before adding things. He things I do = not understand ACL, RBAC, ABAC, PBAC=E2=80=A6 I admit you-all are = better at security than I am.=20 =20 Sue=20 =20 From: Dacheng Zhang [mailto:dacheng.zdc@alibaba-inc.com]=20 Sent: Tuesday, February 03, 2015 8:09 PM To: Susan Hares; i2nsf@ietf.org Cc: linda.dunbar@huawei.com Subject: Re: [I2nsf] draft-zhang-gap-analysis-00 =20 Hi, Sue: =20 Sure. Hosnieh and I will include the work you mentioned into the new = version. =20 Thank you for the comments. =20 Dacheng =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Susan Hares =E6=97=A5=E6=9C=9F: 2015=E5=B9=B42=E6=9C=883=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=BA=8C =E4=B8=8B=E5=8D=886:15 =E8=87=B3: =E6=8A=84=E9=80=81: =E4=B8=BB=E9=A2=98: [I2nsf] draft-zhang-gap-analysis-00 =20 Hosnieh and Dacheng:=20 =20 Do you have an update for the gap analysis for the I2NSF? You did not = include the work in I2RS, rtgwg, and netmod/ netconf in your analysis. = It would be good to update it to include these features=20 =20 Just a few things to include to review for policy is the current=20 =20 =C2=B7 = = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ - approved = ACL policy=20 =20 =C2=B7 = = http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 - = Operators model=20 =C2=B7 draft-yan-rtgwg-routing-policy-yang-00 =E2=80=93 Proposed = for routing policy=20 =C2=B7 = = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ - approved = ACL policy=20 =C2=B7 = = http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ - an = I2RS policy (Sue=E2=80=99s personal draft) . =20 And there are probably others in the I2RS, RTWG, netmod, and netconf = that I have missed.=20 =20 I2RS has both a broker /proxy functionality it is architecture and = approved use cases for the firewall, DDoS/Anti-DoS, IDS/IPS policy. =20 =20 I hope this helps you complete your gap analysis.=20 =20 Sue Hares ------------------ =20 =20 Sections from the I2RS architecture:=20 =20 I2RS architecture document(p. 11-12) =E2=80=83 An I2RS Client is not automatically trustworthy. It has identity = information and applications using that I2RS Client should be aware of = the scope limitations of that I2RS Client. If the I2RS Client is acting as a broker for multiple applications, managing the security, = authentication and authorization for that communication is out of scope; = nothing prevents I2RS and a separate authentication and authorization channel from being used. Regardless of mechanism, an = I2RS Client that is acting as a broker is responsible for determining = that applications using it are trusted and permitted to make the particular requests. =20 Use Case Document (search for the identifying strings)=20 o Topo-REQ-06 (OC): I2RS should enable a orchestration manager attached to an I2RS client to communicate with I2RS agents into order to stitch together End-to-end services for network bandwidth optimization, load balancing, and Class-of-Service with point services (Firewall or NAT) within the end-to-end service). The orchestration manager should also be able to immediately schedule any of these resources via the I2RS-Client I2RS agent exchange. (from section 3.4)=20 =20 o SFC-Use-REQ02 (IC):Supported Service Types SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others =E2=80=83 o L-Flow-REQ-06 (IC): Once a large flow has been detected, I2RS must be used to modify the forwarding tables in the router to: =20 * In the case of large flow load balancing, be able to redirecting the large flow to a particular member with the LAG or ECMP group and readjusting the weights of the other members to account for the large flow =20 * In the case of DDoS mitigation, the action involves rate limiting, remarking or potentially discarding the large flow in question _______________________________________________ I2nsf mailing list = I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf=20 ------=_NextPart_001_02A9_01D04251.1D0E3940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

John:

 

Thank you for your interested in the RBAC = qualities of the IB-Nemo as we discuss vNSF nodes.=C2=A0 You state = =E2=80=9CRBAC implies a role for a first class object=E2=80=9D.=C2=A0 = Below is a model definition for the Intent-Based Nemo DSL.=C2=A0 =

 

Let me ask a few more questions. =

 

The Intent Based Nemo has a DSL that passes = across a RESTful interface (over http) between an application client and = controller with a Nemo Engine inside.=C2=A0 The Nemo Engine stores a = network model which allow the controller to understand the applications = desire regarding the creation of the virtual network.=C2=A0 =C2=A0This = model contains a top-level structures of node, link, and = actions.=C2=A0=C2=A0

 

In your definition, does the node, link and = actions constitute top level structures that are =E2=80=9Croles=E2=80=9D = for objects within the Intent-based prescription for an application = network. =C2=A0=C2=A0Based on these roles, Intent-Based Nemo uses = controller contextual information to map the virtual application-level = topology to a network topology via specific SDN controller = commands.=C2=A0 These commands could be sent via an I2RS client (sdn = controller) to the I2RS Agent in a node.=C2=A0 It could also be sent = from a client sending a netconf configuration stream to a node. =

 

If the node top-level entity, is associated = with a policy set by the behavior command.=C2=A0 Is this RBAC or = something else?

 

Sue =C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Intent-Based Nemo DSL

 

<NEMO_cmd> :=3D = <model_definition_cmd> | <resource_access_cmd> | = <behavior_cmd>

<model_definition_cmd> :=3D = <node_definition> | <link_definition> | = <action_definition>

< resource_access_cmd> :=3D = <node_cu> | <node_del> | <link_cu> | <link_del> = | <flow_cu> | = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0<flow_del>

<behavior_cmd> :=3D <query_cmd> = | <policy_cu> | <policy_del> | <notification_cu> = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = <notification_del>

<connection_mgt_cmd> :=3D = <connect_cmd> | <disconnect_cmd>

<transaction_cmd> = :=3D <transaction_begin> | < transaction = _end>

 

From:= = John Strassner [mailto:John.sc.Strassner@huawei.com]
Sent: = Wednesday, February 04, 2015 4:12 PM
To: Susan Hares; 'Dacheng = Zhang'; John Strassner; i2nsf@ietf.org
Cc: Linda = Dunbar
Subject: RE: [I2nsf] = draft-zhang-gap-analysis-00

 

Sue:

 

Correction: I did NOT = say that you =E2=80=9Cdo not understand ACL, RBAC, ABAC, PBAC=E2=80=9D. = In fact, I didn=E2=80=99t even mention ACL in my = reply.

 

The point is that in = RBAC, a role is a first-class object. Your draft did not mention Role, = and in your reply, you say that =E2=80=9CRole is a logical network role = for a node and not a security role=E2=80=9D. This does not meet the = needs of RBAC, since RBAC requires that roles are managed objects, not = concepts.

 

regards,

John<= /span>

 

Dr. John = Strassner, Ph.D.

CTO, Software = Laboratory, CRD

3Dlogo.gif

 

Futurewei = Technologies

US R&D Center

2330 Central = Expressway
Building A, office A2-2143

Santa Clara, = California   95050

  = Office:  +1.408.330.4923

  = Email:   john.sc.strassner@huawei.com=

 

 

 

From:= = I2nsf [mailto:i2nsf-bounces@ietf.org]= On Behalf Of Susan Hares
Sent: Tuesday, February 03, = 2015 5:12 PM
To: 'Dacheng Zhang'; i2nsf@ietf.org
Cc: Linda = Dunbar
Subject: Re: [I2nsf] = draft-zhang-gap-analysis-00

 

Dacheng:

 

Read John = Strasser=E2=80=99s email before adding things.  He things I do not = understand ACL, RBAC, ABAC, PBAC=E2=80=A6  I admit you-all are = better at security than I am.

 

Sue =

 

From:= = Dacheng Zhang [mailto:dacheng.zdc@alibaba-in= c.com]
Sent: Tuesday, February 03, 2015 8:09 = PM
To: Susan Hares; i2nsf@ietf.org
Cc: linda.dunbar@huawei.com
Subject: Re: [I2nsf] = draft-zhang-gap-analysis-00

 

Hi, = Sue:

 

Sure. Hosnieh = and I will include the work you mentioned into the new = version.

 

Thank you for = the comments.

 

Dacheng

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: Susan Hares <shares@ndzh.com>
=E6=97=A5=E6=9C=9F: 2015=E5=B9=B42=E6=9C=883=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C =E4=B8=8B=E5=8D=886:15
=E8=87=B3: <i2nsf@ietf.org>
=E6=8A=84=E9=80=81: <linda.dunbar@huawei.com>=E4=B8=BB=E9=A2=98: [I2nsf] = draft-zhang-gap-analysis-00

 

Hosnieh and Dacheng:

 

Do you have an update for = the gap analysis for the I2NSF?  You did not include the work in = I2RS, rtgwg, and netmod/ netconf in your analysis.   It would = be good to update it to include these features

 

Just a few things to = include to review for policy is the current

 

=C2=B7         = http://datatracker.ietf.org/doc/draft-ietf-net= mod-acl-model/ - approved ACL policy =

 

=C2=B7         = http://tools.ietf.org/html/draft-shaikh-rtgwg-= policy-model-00   - Operators model =

=C2=B7         = draft-yan-rtgwg-routing-policy-yan= g-00 =E2=80=93 Proposed for routing policy

=C2=B7         = http://datatracker.ietf.org/doc/draft-ietf-net= mod-acl-model/ - approved ACL policy =

=C2=B7         = http://datatracker.ietf.org/doc/draft-hares-i2= rs-bnp-info-model/ - an I2RS policy = (Sue=E2=80=99s personal draft) .

 

And there are = probably others in the I2RS, RTWG, netmod, and netconf that I have = missed.

 

I2RS has both a broker = /proxy functionality it is architecture and approved use cases for the = firewall, DDoS/Anti-DoS, IDS/IPS policy.  

 

I hope this helps you = complete your gap analysis.

 

Sue = Hares

------------------

 

 

Sections from the I2RS architecture: =

 

I2RS architecture document(p. 11-12)  = =E2=80=83

An I2RS Client is not automatically = trustworthy.  It has identity information and applications using = that I2RS Client should be aware  of the scope limitations of that = I2RS Client.  If the I2RS Client is

acting as a = broker for multiple applications, managing the security, authentication = and authorization for that communication is out of scope; nothing = prevents I2RS and a separate authentication and

authorization channel from being used.  = Regardless of mechanism, an  I2RS Client that is acting as a broker = is responsible for determining that applications using it are trusted = and permitted to make the

particular requests.

 

Use Case Document (search for the = identifying strings)

o  Topo-REQ-06 (OC): I2RS should enable = a orchestration manager

      attached to = an I2RS client to communicate with I2RS agents into

      order to = stitch together End-to-end services for network bandwidth

      optimization, = load balancing, and Class-of-Service with point

      services = (Firewall or NAT) within the end-to-end service).  The

      orchestration = manager should also be able to immediately schedule

      any of these = resources via the I2RS-Client I2RS agent exchange.

      (from section = 3.4)

 

o SFC-Use-REQ02 (IC):Supported Service = Types

      SHOULD = include: NAT, IP Firewall, Load balancer, DPI, and others

=E2=80=83

o  L-Flow-REQ-06 (IC): Once a large = flow has been detected, I2RS must

      be used to = modify the forwarding tables in the router to:

 

      *  In = the case of large flow load balancing, be able to

       &nb= sp; redirecting the large flow to a particular member with the = LAG

       &nb= sp; or ECMP group and readjusting the weights of the other = members

       &nb= sp; to account for the large flow

 

      *  In = the case of DDoS mitigation, the action involves rate

       &nb= sp; limiting, remarking or potentially discarding the large flow = in

       &nb= sp; question

_______________= ________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org= /mailman/listinfo/i2nsf

------=_NextPart_001_02A9_01D04251.1D0E3940-- ------=_NextPart_000_02A8_01D04251.1D0E3940 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= ------=_NextPart_000_02A8_01D04251.1D0E3940-- From nobody Fri Feb 6 19:14:56 2015 Return-Path: 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 4B0671A0125 for ; Fri, 6 Feb 2015 19:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no 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 NKbfsaw2wzBx for ; Fri, 6 Feb 2015 19:14:51 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE451A00FD for ; Fri, 6 Feb 2015 19:14:51 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Georgios Karagiannis'" References: In-Reply-To: Date: Fri, 6 Feb 2015 22:14:42 -0500 Message-ID: <02d401d04284$381d6070$a8582150$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D5_01D0425A.4F492D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJv6C97uS28twITRDNDOcmrbje+xpulKgMw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 03:14:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D5_01D0425A.4F492D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire to maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers operate to maximize the use of server's compute cycle, storage devices, and networks. A research study (2011-2012) examined how to maximize usage of compute, storage, and networks using theoretical models. This study showed that if you optimize for any one facet (compute, storage, network) you obtain 66% utilization of all facets. However, if the applications can communicate and negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to with the virtualization of network devices creates an economic environment that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based networks via descriptive commands requires a large data flow between applications and networks. The application does not really want or need the full description of the networks. For example, a database application simply needs to signal that it needs to connect to two other database locations and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everything. However, most applications really need only to signal intent. The network engineers designing SDN orchestrators are 20% or less of the total applications. The other 80% of applications use the 20% of total commands that request the high-level requests. Intent based Domain Specific languages (E.g. focused on network) allow simple commands to be exchanged between the application and the SDN controller across a RESTful interface (http protocol). This simpler interface for applications can enable a large class of new applications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications for the new NFV controllers controlling Carrier access networks or Cable networks, b) Simple interfaces for the network-based application store that can load query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a Virtual network to link database sites. The set-up/tear down of this network is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connection to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Compute c) Standardize Intent-Based Nemo DSL (domain-specific language) for virtual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend an existing one? The main goal is to standardize a series of Domain-Specific languages which run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained to small environment as a specialized application protocol. However, these protocols are not focused on enabling an Intent-Based application protocols that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions. Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operable application protocol that forms a simple NorthBound API (NB) for applications on any platform to control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) handle compute devices with a the minimal set of intent-based primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cases defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo ------=_NextPart_000_02D5_01D0425A.4F492D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gergios:

 

Thank = you for these great questions.

 

 

1) = What is the motivation of starting this working group? =

The motivation for starting = this group comes out three things:  a) desire to maximum usage of = Network devices, b) Intent-Based theory and c) an 80/20 rule of = interfaces. 

 

Desire to maximum network devices: =

Today's networks connect = data centers to mobile users.  The Data Centers operate to maximize = the use of server's compute cycle, storage devices, and networks.  = A research study (2011-2012) examined how to maximize usage of compute, = storage, and networks using theoretical models.  This study showed = that if you optimize for any one facet (compute, storage, network) you = obtain 66% utilization of all facets.  However, if the applications = can communicate and negotiate their intent for compute, storage, or = network - the theoretical utilization can reach 95% or higher. =  

 

The potential higher utilization combined with the = lowering of costs due to with the virtualization of network devices = creates an economic environment that radically changes the cost dynamics = of IT technology. 

 

Intent-Based = Networks

The signaling of = the network changes via applications that direct SDN-based networks via = descriptive commands requires a large data flow between applications and = networks.   The application does not really want or need the = full description of the networks.   For example, a database = application simply needs to signal that it needs to connect to two other = database locations and exchange data with some maximum flow rate. =

 

Intent-based network signal this minimum required = information, and let the network set-up the rest.

 

80/20 rules of = applications

Some SDN = orchestrators are "god-boxes" that need to know and direct = everything.  However, most applications really need only to signal = intent.   The network engineers designing SDN orchestrators = are 20% or less of the total applications.   The other 80% of = applications use the 20% of total commands that request the high-level = requests.   Intent based Domain Specific languages (E.g. = focused on network) allow simple commands to be exchanged between the = application and the SDN controller across a RESTful interface (http = protocol). 

 

This = simpler interface for applications can enable a large class of new = applications to utilize the SDN controller.

 

2) = Are there use cases defined that are motivating this = work?

 

The use case motivating this work:  =

 

a) Simple interfaces for a new class of monitoring = and manage applications for the new NFV controllers controlling Carrier = access networks or Cable networks,

 

b) = Simple interfaces for the network-based application store that can load = query or load things on mobile networks,

 

c) = Large Database applications desiring to signal the network to set-up a = Virtual network to link database sites.  The set-up/tear down of = this network is controlled by the Application.

 

d) = Security devices seeking a short-term set-up of application layer = connection to exchange data.

 

3) = What are the work items?  

     a) Problem statement = and use cases document

    b) Intent Framework = Description for Networks, Security, Storage, Compute =  

 

    c) Standardize Intent-Based Nemo = DSL (domain-specific language) for virtual networks.

        IB-N= emo runs over a RESTful (http) interface.

    d) Standardize Intent-Based = Nemo DSL for Security devices  

    e) Standardize Intent-Based = Nemo DSL for compute devices.   

 

4) Is = the main goal of the WG to standardize a new protocol, or to extend an = existing one?

 

The = main goal is to standardize a series of Domain-Specific languages which = run over RESTful interface (http).

 

5)  What is the relation of IBnemo with = existing IETF WGs?

 

      =             &= nbsp;           &n= bsp;        NBI   =      SDN    SBI   =

IB-Nemo (application) ---- = controller --- I2rs, netconf/netmod,

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp; SACM

 

NBI - = north bound interface

SBI - south = bound interface

 

Application protocols work such as  CoApp = (CORE) produce http constrained to small environment as a specialized = application protocol.  However, these protocols are not focused on = enabling an Intent-Based application protocols that will utilize NFV = architectures. 

 

Before = I launch into more details, please let me know if you have questions. =

 

Sue Hares

 

-----Original Message-----
From: Ibnemo = [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios = Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan = Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification = questions about IBnemo

 

Hi = Sue, Hi all,

 

In a = previous email it is mentioned that:

 

"The Nemo-project group seeks to create a = simple Intent-Based inter-operable application protocol that forms a = simple NorthBound API (NB) for applications on any platform to control = the following : a) setup and take down of virtual networks between = virtual nodes, b) control transfer of data toward storage, and c) handle = compute devices with a the minimal set of intent-based = primitives."

 

Can = you please provide some clarifications on the following = points?

 

o) What is the motivation of starting this working = group? Are there use cases defined that are motivating this = work?

 

o) What are the work items? Is the main goal of the = WG to standardize a new protocol, or to extend an existing = one?

 

o)  What is the relation of IBnemo with = existing IETF WGs?

 

Best = regards,

Georgios

 

_______________________________________________=

Ibnemo mailing list

Ibnemo@ietf.org

https://www.ietf.org/mail= man/listinfo/ibnemo

------=_NextPart_000_02D5_01D0425A.4F492D30-- From nobody Tue Feb 10 01:15:10 2015 Return-Path: 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 55CFE1A008F for ; Tue, 10 Feb 2015 01:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, 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 HdvFXdvhNwfN for ; Tue, 10 Feb 2015 01:14:57 -0800 (PST) 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 C20BC1A00B0 for ; Tue, 10 Feb 2015 01:14:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSL74649; Tue, 10 Feb 2015 09:14:40 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 10 Feb 2015 09:14:36 +0000 From: Georgios Karagiannis To: Susan Hares Thread-Topic: [Ibnemo] some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTABXauIAAKNJ9UA= Date: Tue, 10 Feb 2015 09:14:35 +0000 Message-ID: References: <02d401d04284$381d6070$a8582150$@ndzh.com> In-Reply-To: <02d401d04284$381d6070$a8582150$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.77] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC014D8E1Dlhreml502mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 09:15:06 -0000 --_000_C5034E44CD620A44971BAAEB372655DC014D8E1Dlhreml502mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific lan= guage and YANG? By focusing on these three areas, the scope of the WG might be quite large.= If it is to focus only on one of these three work items, which one of them= will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire t= o maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 = rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers op= erate to maximize the use of server's compute cycle, storage devices, and n= etworks. A research study (2011-2012) examined how to maximize usage of co= mpute, storage, and networks using theoretical models. This study showed t= hat if you optimize for any one facet (compute, storage, network) you obtai= n 66% utilization of all facets. However, if the applications can communic= ate and negotiate their intent for compute, storage, or network - the theor= etical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to= with the virtualization of network devices creates an economic environment= that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based= networks via descriptive commands requires a large data flow between appli= cations and networks. The application does not really want or need the fu= ll description of the networks. For example, a database application simpl= y needs to signal that it needs to connect to two other database locations = and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the = network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everyth= ing. However, most applications really need only to signal intent. The n= etwork engineers designing SDN orchestrators are 20% or less of the total a= pplications. The other 80% of applications use the 20% of total commands = that request the high-level requests. Intent based Domain Specific langua= ges (E.g. focused on network) allow simple commands to be exchanged between= the application and the SDN controller across a RESTful interface (http pr= otocol). This simpler interface for applications can enable a large class of new app= lications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable ne= tworks, b) Simple interfaces for the network-based application store that can load = query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a V= irtual network to link database sites. The set-up/tear down of this networ= k is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connec= tion to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Comput= e c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend a= n existing one? The main goal is to standardize a series of Domain-Specific languages which= run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained t= o small environment as a specialized application protocol. However, these = protocols are not focused on enabling an Intent-Based application protocols= that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions= . Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo --_000_C5034E44CD620A44971BAAEB372655DC014D8E1Dlhreml502mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 =

Thank you very much for = the answers. Regarding the listed work items:

 =

    c)= Standardize Intent-Based Nemo DSL (domain-specific language) for virtual n= etworks.

   &nb= sp;    IB-Nemo runs over a RESTful (http) interface.

   &nb= sp;d) Standardize Intent-Based Nemo DSL for Security devices  

   &nb= sp;e) Standardize Intent-Based Nemo DSL for compute devices.   

 

 =

 =

What are the main differ= ences between Intent-Based Nemo domain-specific langua= ge and YANG?

By focusing on these thr= ee areas, the scope of the WG might be quite large. If it is to focus only = on one of these three work items, which one of them will you choose?

 =

Best regards,=

Georgios

 =

 

 

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Saturday, February 07, 2015 4:15 AM
To: Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Gergios:

 

Thank you for these great questions. <= /p>

 

 

1) What is the motivation of starting this wor= king group?

The motivation for starting this group comes out = three things:  a) desire to maximum usage of Network devices, b) Inten= t-Based theory and c) an 80/20 rule of interfaces. 

 

Desire to maximum network devices:

Today's networks connect data centers to mobile u= sers.  The Data Centers operate to maximize the use of server's comput= e cycle, storage devices, and networks.  A research study (2011-2012) = examined how to maximize usage of compute, storage, and networks using theoretical models.  This study showed that if you= optimize for any one facet (compute, storage, network) you obtain 66% util= ization of all facets.  However, if the applications can communicate a= nd negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher.  

 

The potential higher utilization combined with th= e lowering of costs due to with the virtualization of network devices creat= es an economic environment that radically changes the cost dynamics of IT t= echnology. 

 

Intent-Based Networks

The signaling of the network changes via applicat= ions that direct SDN-based networks via descriptive commands requires a lar= ge data flow between applications and networks.   The application= does not really want or need the full description of the networks.   For example, a database application simply ne= eds to signal that it needs to connect to two other database locations and = exchange data with some maximum flow rate.

 

Intent-based network signal this minimum required= information, and let the network set-up the rest.

 

80/20 rules of applications<= /b>

Some SDN orchestrators are "god-boxes" = that need to know and direct everything.  However, most applications r= eally need only to signal intent.   The network engineers designi= ng SDN orchestrators are 20% or less of the total applications.   The other 80% of applications use the 20% of total commands that request t= he high-level requests.   Intent based Domain Specific languages = (E.g. focused on network) allow simple commands to be exchanged between the= application and the SDN controller across a RESTful interface (http protocol). 

 

This simpler interface for applications can enabl= e a large class of new applications to utilize the SDN controller.

 

2) Are there use cases defined that are motiva= ting this work?

 

The use case motivating this work: 

 

a) Simple interfaces for a new class of monitorin= g and manage applications for the new NFV controllers controlling Carrier a= ccess networks or Cable networks,

 

b) Simple interfaces for the network-based applic= ation store that can load query or load things on mobile networks,

 

c) Large Database applications desiring to signal= the network to set-up a Virtual network to link database sites.  The = set-up/tear down of this network is controlled by the Application.

 

d) Security devices seeking a short-term set-up o= f application layer connection to exchange data.

 

3) What are the work items?  

     a) Problem statemen= t and use cases document

    b) Intent Framework Descr= iption for Networks, Security, Storage, Compute  

 

    c) Standardize Intent-Based Ne= mo DSL (domain-specific language) for virtual networks.

        I= B-Nemo runs over a RESTful (http) interface.

    d) Standardize Intent-Bas= ed Nemo DSL for Security devices  

    e) Standardize Intent-Bas= ed Nemo DSL for compute devices.   

 

4) Is the main goal of the WG to standardize a ne= w protocol, or to extend an existing one?

 

The main goal is to standardize a series of Domai= n-Specific languages which run over RESTful interface (http).

 

5)  What is the relation of IBnemo with exis= ting IETF WGs?

 

         =             &nb= sp;            =      NBI        = ;SDN    SBI  

IB-Nemo (application) ---- controller --- I2rs, n= etconf/netmod,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;SACM

 

NBI - north bound interface

SBI - south bound interface

 

Application protocols work such as  CoApp (C= ORE) produce http constrained to small environment as a specialized applica= tion protocol.  However, these protocols are not focused on enabling a= n Intent-Based application protocols that will utilize NFV architectures. 

 

Before I launch into more details, please let me = know if you have questions.

 

Sue Hares

 

-----Original Message-----
From: Ibnemo [mailto:ibnemo-boun= ces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification questions about IBnemo

 

Hi Sue, Hi all,

 

In a previous email it is mentioned that:

 

"The Nemo-project group seeks to create a si= mple Intent-Based inter-operable application protocol that forms a simple N= orthBound API (NB) for applications on any platform to control the followin= g : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) = handle compute devices with a the minimal set of intent-based primitives.&q= uot;

 

Can you please provide some clarifications on the= following points?

 

o) What is the motivation of starting this workin= g group? Are there use cases defined that are motivating this work?

 

o) What are the work items? Is the main goal of t= he WG to standardize a new protocol, or to extend an existing one?

 

o)  What is the relation of IBnemo with exis= ting IETF WGs?

 

Best regards,

Georgios

 

_______________________________________________

Ibnemo mailing list

Ibnemo@ietf.org

https://www.i= etf.org/mailman/listinfo/ibnemo

--_000_C5034E44CD620A44971BAAEB372655DC014D8E1Dlhreml502mbschi_-- From nobody Tue Feb 10 01:53:30 2015 Return-Path: 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 6EE341A1AF5 for ; Tue, 10 Feb 2015 01:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 MH0s5En2iUmi for ; Tue, 10 Feb 2015 01:53:17 -0800 (PST) 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 91D411A00B6 for ; Tue, 10 Feb 2015 01:53:16 -0800 (PST) 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 BPC76692; Tue, 10 Feb 2015 09:53:14 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Feb 2015 09:53:13 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 10 Feb 2015 17:53:01 +0800 From: Zhoutianran To: Georgios Karagiannis , Susan Hares Thread-Topic: [Ibnemo] some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTABGp1kAAKNxa4AAEelTwA== Date: Tue, 10 Feb 2015 09:53:00 +0000 Message-ID: References: <02d401d04284$381d6070$a8582150$@ndzh.com> In-Reply-To: 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_BBA82579FD347748BEADC4C445EA0F2166B6B125nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 09:53:24 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2166B6B125nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gergios, A big difference I noticed is that: YANG is used for describing static data model including data structure, and= operations. IB-NEMO DSL can be used for programming, i.e. application can interact with= the network using NEMO DSL. There are many other differences I think we need a gap analysis. Best Regards, Tianran Zhou (Ph.D.) Senior Network Researcher Huawei Technologies Co., Ltd. From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Tuesday, February 10, 2015 5:15 PM To: Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific lan= guage and YANG? By focusing on these three areas, the scope of the WG might be quite large.= If it is to focus only on one of these three work items, which one of them= will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire t= o maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 = rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers op= erate to maximize the use of server's compute cycle, storage devices, and n= etworks. A research study (2011-2012) examined how to maximize usage of co= mpute, storage, and networks using theoretical models. This study showed t= hat if you optimize for any one facet (compute, storage, network) you obtai= n 66% utilization of all facets. However, if the applications can communic= ate and negotiate their intent for compute, storage, or network - the theor= etical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to= with the virtualization of network devices creates an economic environment= that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based= networks via descriptive commands requires a large data flow between appli= cations and networks. The application does not really want or need the fu= ll description of the networks. For example, a database application simpl= y needs to signal that it needs to connect to two other database locations = and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the = network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everyth= ing. However, most applications really need only to signal intent. The n= etwork engineers designing SDN orchestrators are 20% or less of the total a= pplications. The other 80% of applications use the 20% of total commands = that request the high-level requests. Intent based Domain Specific langua= ges (E.g. focused on network) allow simple commands to be exchanged between= the application and the SDN controller across a RESTful interface (http pr= otocol). This simpler interface for applications can enable a large class of new app= lications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable ne= tworks, b) Simple interfaces for the network-based application store that can load = query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a V= irtual network to link database sites. The set-up/tear down of this networ= k is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connec= tion to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Comput= e c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend a= n existing one? The main goal is to standardize a series of Domain-Specific languages which= run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained t= o small environment as a specialized application protocol. However, these = protocols are not focused on enabling an Intent-Based application protocols= that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions= . Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo --_000_BBA82579FD347748BEADC4C445EA0F2166B6B125nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gergios,=

 

A big difference I noticed is= that:

YANG is used for describing s= tatic data model including data structure, and operations.

IB-NEMO DSL can be used for p= rogramming, i.e. application can interact with the network using NEMO DSL.<= o:p>

 

There are many other differen= ces I think we need a gap analysis.

 

Best Regards,

 

Tianran Zhou (Ph.D.)

Senior Network Researcher

Huawei Technologies Co., Ltd.

 

From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Tuesday, February 10, 2015 5:15 PM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: Re: [Ibnemo] some clarification questions about IBnemo=

 

Hi Sue,

&nbs= p;

Thank you= very much for the answers. Regarding the listed work items:

&nbs= p;

 =    c) Standardize Intent-Based Nemo DSL (domain-specific language= ) for virtual networks.

 =        IB-Nemo runs over a RESTful (http= ) interface.

 =    d) Standardize Intent-Based Nemo DSL for Security devices=  

 =    e) Standardize Intent-Based Nemo DSL for compute devices.=   

&= nbsp;

&nbs= p;

&nbs= p;

What are = the main differences between Intent-Based Nemo domain-specific language and= YANG?

By focusi= ng on these three areas, the scope of the WG might be quite large. If it is= to focus only on one of these three work items, which one of them will you= choose?

&nbs= p;

Best rega= rds,

Georgios<= o:p>

&nbs= p;

&n= bsp;

&n= bsp;

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Saturday, February 07, 2015 4:15 AM
To: Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Gergios:

 

Thank you for these great qu= estions.

 

 

1) What is the motivation= of starting this working group?

The motivation for starting = this group comes out three things:  a) desire to maximum usage of Netw= ork devices, b) Intent-Based theory and c) an 80/20 rule of interfaces.&nbs= p;

 

Desire to maximum netw= ork devices:

Today's networks connect dat= a centers to mobile users.  The Data Centers operate to maximize the u= se of server's compute cycle, storage devices, and networks.  A resear= ch study (2011-2012) examined how to maximize usage of compute, storage, and networks using theoretical models.  Th= is study showed that if you optimize for any one facet (compute, storage, n= etwork) you obtain 66% utilization of all facets.  However, if the app= lications can communicate and negotiate their intent for compute, storage, or network - the theoretical utilization can = reach 95% or higher.  

 

The potential higher utiliza= tion combined with the lowering of costs due to with the virtualization of = network devices creates an economic environment that radically changes the = cost dynamics of IT technology. 

 

Intent-Based Networks<= o:p>

The signaling of the network= changes via applications that direct SDN-based networks via descriptive co= mmands requires a large data flow between applications and networks.  =  The application does not really want or need the full description of the networks.   For example, a data= base application simply needs to signal that it needs to connect to two oth= er database locations and exchange data with some maximum flow rate.

 

Intent-based network signal = this minimum required information, and let the network set-up the rest.

 

80/20 rules of applica= tions

Some SDN orchestrators are &= quot;god-boxes" that need to know and direct everything.  However= , most applications really need only to signal intent.   The netw= ork engineers designing SDN orchestrators are 20% or less of the total applications.   The other 80% of applications use the = 20% of total commands that request the high-level requests.   Int= ent based Domain Specific languages (E.g. focused on network) allow simple = commands to be exchanged between the application and the SDN controller across a RESTful interface (http protocol).  =

 

This simpler interface for a= pplications can enable a large class of new applications to utilize the SDN= controller.

 

2) Are there use cases de= fined that are motivating this work?

 

The use case motivating this= work: 

 

a) Simple interfaces for a n= ew class of monitoring and manage applications for the new NFV controllers = controlling Carrier access networks or Cable networks,

 

b) Simple interfaces for the= network-based application store that can load query or load things on mobi= le networks,

 

c) Large Database applicatio= ns desiring to signal the network to set-up a Virtual network to link datab= ase sites.  The set-up/tear down of this network is controlled by the = Application.

 

d) Security devices seeking = a short-term set-up of application layer connection to exchange data.

 

3) What are the work items? =  

    &nbs= p;a) Problem statement and use cases document

    b) I= ntent Framework Description for Networks, Security, Storage, Compute  =

 

    c) Standa= rdize Intent-Based Nemo DSL (domain-specific language) for virtual networks= .

    &nbs= p;   IB-Nemo runs over a RESTful (http) interface.

    d) S= tandardize Intent-Based Nemo DSL for Security devices  

    e) S= tandardize Intent-Based Nemo DSL for compute devices.   

 

4) Is the main goal of the W= G to standardize a new protocol, or to extend an existing one?

 

The main goal is to standard= ize a series of Domain-Specific languages which run over RESTful interface = (http).

 

5)  What is the relatio= n of IBnemo with existing IETF WGs?

 

    &nbs= p;             =             &nb= sp;        NBI   &nb= sp;    SDN    SBI  

IB-Nemo (application) ---- c= ontroller --- I2rs, netconf/netmod,

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   SACM

 

NBI - north bound interface<= o:p>

SBI - south bound interface =

 

Application protocols work s= uch as  CoApp (CORE) produce http constrained to small environment as = a specialized application protocol.  However, these protocols are not = focused on enabling an Intent-Based application protocols that will utilize NFV architectures. 

 

Before I launch into more de= tails, please let me know if you have questions.

 

Sue Hares =

 

-----Original Message----- From: Ibnemo [mailto:ibnemo-boun= ces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification questions about IBnemo

 

Hi Sue, Hi all,

 

In a previous email it is me= ntioned that:

 

"The Nemo-project group= seeks to create a simple Intent-Based inter-operable application protocol = that forms a simple NorthBound API (NB) for applications on any platform to= control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of dat= a toward storage, and c) handle compute devices with a the minimal set of i= ntent-based primitives."

 

Can you please provide some = clarifications on the following points?

 

o) What is the motivation of= starting this working group? Are there use cases defined that are motivati= ng this work?

 

o) What are the work items? = Is the main goal of the WG to standardize a new protocol, or to extend an e= xisting one?

 

o)  What is the relatio= n of IBnemo with existing IETF WGs?

 

Best regards,

Georgios

 

____________________________= ___________________

Ibnemo mailing list

Ibnemo@ietf.or= g

https://www.ietf.org/mailman/listinfo/ibnemo<= /span>

--_000_BBA82579FD347748BEADC4C445EA0F2166B6B125nkgeml512mbxchi_-- From nobody Tue Feb 10 01:56:27 2015 Return-Path: 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 A10C91A0120 for ; Tue, 10 Feb 2015 01:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 bXuLFHTWVPw3 for ; Tue, 10 Feb 2015 01:56:16 -0800 (PST) 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 0ADF41A00F1 for ; Tue, 10 Feb 2015 01:56:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPC77026; Tue, 10 Feb 2015 09:56:00 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 10 Feb 2015 09:55:52 +0000 From: Georgios Karagiannis To: Zhoutianran , Susan Hares Thread-Topic: [Ibnemo] some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTABXauIAAKNJ9UAAAX7vAAAACuyg Date: Tue, 10 Feb 2015 09:55:52 +0000 Message-ID: References: <02d401d04284$381d6070$a8582150$@ndzh.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.77] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC014D8E70lhreml502mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 09:56:26 -0000 --_000_C5034E44CD620A44971BAAEB372655DC014D8E70lhreml502mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tianran, Thank you very much for the answer. I think that you are right, a gap analy= sis is needed in order to emphasize the main differences between what the I= Nnemo use cases require and what YANG can provide. Best regards, Georgios From: Zhoutianran Sent: Tuesday, February 10, 2015 10:53 AM To: Georgios Karagiannis; Susan Hares Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Hi Gergios, A big difference I noticed is that: YANG is used for describing static data model including data structure, and= operations. IB-NEMO DSL can be used for programming, i.e. application can interact with= the network using NEMO DSL. There are many other differences I think we need a gap analysis. Best Regards, Tianran Zhou (Ph.D.) Senior Network Researcher Huawei Technologies Co., Ltd. From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Tuesday, February 10, 2015 5:15 PM To: Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific lan= guage and YANG? By focusing on these three areas, the scope of the WG might be quite large.= If it is to focus only on one of these three work items, which one of them= will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire t= o maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 = rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers op= erate to maximize the use of server's compute cycle, storage devices, and n= etworks. A research study (2011-2012) examined how to maximize usage of co= mpute, storage, and networks using theoretical models. This study showed t= hat if you optimize for any one facet (compute, storage, network) you obtai= n 66% utilization of all facets. However, if the applications can communic= ate and negotiate their intent for compute, storage, or network - the theor= etical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to= with the virtualization of network devices creates an economic environment= that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based= networks via descriptive commands requires a large data flow between appli= cations and networks. The application does not really want or need the fu= ll description of the networks. For example, a database application simpl= y needs to signal that it needs to connect to two other database locations = and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the = network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everyth= ing. However, most applications really need only to signal intent. The n= etwork engineers designing SDN orchestrators are 20% or less of the total a= pplications. The other 80% of applications use the 20% of total commands = that request the high-level requests. Intent based Domain Specific langua= ges (E.g. focused on network) allow simple commands to be exchanged between= the application and the SDN controller across a RESTful interface (http pr= otocol). This simpler interface for applications can enable a large class of new app= lications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable ne= tworks, b) Simple interfaces for the network-based application store that can load = query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a V= irtual network to link database sites. The set-up/tear down of this networ= k is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connec= tion to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Comput= e c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend a= n existing one? The main goal is to standardize a series of Domain-Specific languages which= run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained t= o small environment as a specialized application protocol. However, these = protocols are not focused on enabling an Intent-Based application protocols= that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions= . Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo --_000_C5034E44CD620A44971BAAEB372655DC014D8E70lhreml502mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tianran,=

 

Thank you very much fo= r the answer. I think that you are right, a gap analysis is needed in order= to emphasize the main differences between what the INnemo use cases requir= e and what YANG can provide.

 

Best regards,

Georgios

 

 

From: Zhoutian= ran
Sent: Tuesday, February 10, 2015 10:53 AM
To: Georgios Karagiannis; Susan Hares
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Hi Gergios,

 

A big difference I noticed is that:

YANG is used for describing static data mode= l including data structure, and operations.

IB-NEMO DSL can be used for programming, i.e= . application can interact with the network using NEMO DSL.

 

There are many other differences I think we = need a gap analysis.

 

Best Regards,

 

Tianran Zhou (Ph.D.)

Senior Network Researcher<= /p>

Huawei Technologies Co., Ltd.

 

 

Hi Sue,

 =

Thank you very much for = the answers. Regarding the listed work items:

 =

    c)= Standardize Intent-Based Nemo DSL (domain-specific language) for virtual n= etworks.

   &nb= sp;    IB-Nemo runs over a RESTful (http) interface.

   &nb= sp;d) Standardize Intent-Based Nemo DSL for Security devices  

   &nb= sp;e) Standardize Intent-Based Nemo DSL for compute devices.   

 

 =

 =

What are the main differ= ences between Intent-Based Nemo domain-specific language and YANG?

By focusing on these thr= ee areas, the scope of the WG might be quite large. If it is to focus only = on one of these three work items, which one of them will you choose?

 =

Best regards,=

Georgios

 =

 

 

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Saturday, February 07, 2015 4:15 AM
To: Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Gergios:

 

Thank you for these great questions. <= /p>

 

 

1) What is the motivation of starting this wor= king group?

The motivation for starting this group comes out = three things:  a) desire to maximum usage of Network devices, b) Inten= t-Based theory and c) an 80/20 rule of interfaces. 

 

Desire to maximum network devices:

Today's networks connect data centers to mobile u= sers.  The Data Centers operate to maximize the use of server's comput= e cycle, storage devices, and networks.  A research study (2011-2012) = examined how to maximize usage of compute, storage, and networks using theoretical models.  This study showed that if you= optimize for any one facet (compute, storage, network) you obtain 66% util= ization of all facets.  However, if the applications can communicate a= nd negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher.  

 

The potential higher utilization combined with th= e lowering of costs due to with the virtualization of network devices creat= es an economic environment that radically changes the cost dynamics of IT t= echnology. 

 

Intent-Based Networks

The signaling of the network changes via applicat= ions that direct SDN-based networks via descriptive commands requires a lar= ge data flow between applications and networks.   The application= does not really want or need the full description of the networks.   For example, a database application simply ne= eds to signal that it needs to connect to two other database locations and = exchange data with some maximum flow rate.

 

Intent-based network signal this minimum required= information, and let the network set-up the rest.

 

80/20 rules of applications<= /b>

Some SDN orchestrators are "god-boxes" = that need to know and direct everything.  However, most applications r= eally need only to signal intent.   The network engineers designi= ng SDN orchestrators are 20% or less of the total applications.   The other 80% of applications use the 20% of total commands that request t= he high-level requests.   Intent based Domain Specific languages = (E.g. focused on network) allow simple commands to be exchanged between the= application and the SDN controller across a RESTful interface (http protocol). 

 

This simpler interface for applications can enabl= e a large class of new applications to utilize the SDN controller.

 

2) Are there use cases defined that are motiva= ting this work?

 

The use case motivating this work: 

 

a) Simple interfaces for a new class of monitorin= g and manage applications for the new NFV controllers controlling Carrier a= ccess networks or Cable networks,

 

b) Simple interfaces for the network-based applic= ation store that can load query or load things on mobile networks,

 

c) Large Database applications desiring to signal= the network to set-up a Virtual network to link database sites.  The = set-up/tear down of this network is controlled by the Application.

 

d) Security devices seeking a short-term set-up o= f application layer connection to exchange data.

 

3) What are the work items?  

     a) Problem statemen= t and use cases document

    b) Intent Framework Descr= iption for Networks, Security, Storage, Compute  

 

    c) Standardize Intent-Based Ne= mo DSL (domain-specific language) for virtual networks.

        I= B-Nemo runs over a RESTful (http) interface.

    d) Standardize Intent-Bas= ed Nemo DSL for Security devices  

    e) Standardize Intent-Bas= ed Nemo DSL for compute devices.   

 

4) Is the main goal of the WG to standardize a ne= w protocol, or to extend an existing one?

 

The main goal is to standardize a series of Domai= n-Specific languages which run over RESTful interface (http).

 

5)  What is the relation of IBnemo with exis= ting IETF WGs?

 

         =             &nb= sp;            =      NBI        = ;SDN    SBI  

IB-Nemo (application) ---- controller --- I2rs, n= etconf/netmod,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;SACM

 

NBI - north bound interface

SBI - south bound interface

 

Application protocols work such as  CoApp (C= ORE) produce http constrained to small environment as a specialized applica= tion protocol.  However, these protocols are not focused on enabling a= n Intent-Based application protocols that will utilize NFV architectures. 

 

Before I launch into more details, please let me = know if you have questions.

 

Sue Hares

 

-----Original Message-----
From: Ibnemo [mailto:ibnemo-boun= ces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification questions about IBnemo

 

Hi Sue, Hi all,

 

In a previous email it is mentioned that:

 

"The Nemo-project group seeks to create a si= mple Intent-Based inter-operable application protocol that forms a simple N= orthBound API (NB) for applications on any platform to control the followin= g : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) = handle compute devices with a the minimal set of intent-based primitives.&q= uot;

 

Can you please provide some clarifications on the= following points?

 

o) What is the motivation of starting this workin= g group? Are there use cases defined that are motivating this work?

 

o) What are the work items? Is the main goal of t= he WG to standardize a new protocol, or to extend an existing one?

 

o)  What is the relation of IBnemo with exis= ting IETF WGs?

 

Best regards,

Georgios

 

_______________________________________________

Ibnemo mailing list

Ibnemo@ietf.org

https://www.i= etf.org/mailman/listinfo/ibnemo

--_000_C5034E44CD620A44971BAAEB372655DC014D8E70lhreml502mbschi_-- From nobody Tue Feb 10 15:21:38 2015 Return-Path: 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 0ED511A8761 for ; Tue, 10 Feb 2015 15:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no 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 6F_UuMhEoZ5h for ; Tue, 10 Feb 2015 15:21:31 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 966531A8759 for ; Tue, 10 Feb 2015 15:21:30 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Georgios Karagiannis'" References: <02d401d04284$381d6070$a8582150$@ndzh.com> In-Reply-To: Date: Tue, 10 Feb 2015 18:21:18 -0500 Message-ID: <041d01d04588$476207a0$d62616e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041E_01D0455E.5E90BA90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJv6C97uS28twITRDNDOcmrbje+xgLpsRUnAmvAWsebgI2foA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:21:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_041E_01D0455E.5E90BA90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Georgios: Nemo is a high level DSL North Bound Interface (NBI) for applications can use to talk to controller at the network layer. Application || Nemo DSL ---------- Controller (with Nemo Engine with nemo model) || || (SBI) || netconf (I2RS/config) Yang Is a descriptive rather than an intent based interface. It is extremely words and will change a functions change in the network. Nemo as a DSL will provide functions the user application wants. Yang modules will be 10,000s different items in at least 100+ module. Nemo 15 primitives with options. Would it be helpful, if I describe a potential security DSL? Sue From: Georgios Karagiannis [mailto:georgios.karagiannis@huawei.com] Sent: Tuesday, February 10, 2015 4:15 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for virtual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific language and YANG? By focusing on these three areas, the scope of the WG might be quite large. If it is to focus only on one of these three work items, which one of them will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire to maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers operate to maximize the use of server's compute cycle, storage devices, and networks. A research study (2011-2012) examined how to maximize usage of compute, storage, and networks using theoretical models. This study showed that if you optimize for any one facet (compute, storage, network) you obtain 66% utilization of all facets. However, if the applications can communicate and negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to with the virtualization of network devices creates an economic environment that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based networks via descriptive commands requires a large data flow between applications and networks. The application does not really want or need the full description of the networks. For example, a database application simply needs to signal that it needs to connect to two other database locations and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everything. However, most applications really need only to signal intent. The network engineers designing SDN orchestrators are 20% or less of the total applications. The other 80% of applications use the 20% of total commands that request the high-level requests. Intent based Domain Specific languages (E.g. focused on network) allow simple commands to be exchanged between the application and the SDN controller across a RESTful interface (http protocol). This simpler interface for applications can enable a large class of new applications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications for the new NFV controllers controlling Carrier access networks or Cable networks, b) Simple interfaces for the network-based application store that can load query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a Virtual network to link database sites. The set-up/tear down of this network is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connection to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Compute c) Standardize Intent-Based Nemo DSL (domain-specific language) for virtual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend an existing one? The main goal is to standardize a series of Domain-Specific languages which run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained to small environment as a specialized application protocol. However, these protocols are not focused on enabling an Intent-Based application protocols that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions. Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operable application protocol that forms a simple NorthBound API (NB) for applications on any platform to control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) handle compute devices with a the minimal set of intent-based primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cases defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo ------=_NextPart_000_041E_01D0455E.5E90BA90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Georgios:

 

Nemo is a high level DSL = North Bound Interface (NBI) for applications can use to talk to = controller at the network layer. 

 

Application

   || =  Nemo DSL

----------

Controller (with Nemo Engine with nemo model) =

  ||

  ||  (SBI) =

  || netconf (I2RS/config) =

 

Yang Is a descriptive = rather than an intent based interface.  It is extremely words and = will change a functions change in the network.  Nemo as a DSL will = provide functions the user application wants.

 

Yang modules will be = 10,000s different items in at least 100+ module.

Nemo 15 primitives with = options.

 

Would it be helpful, if = I describe a potential security DSL?  

 

Sue =

From:= = Georgios Karagiannis [mailto:georgios.karagiannis@huawei.com] =
Sent: Tuesday, February 10, 2015 4:15 AM
To: Susan = Hares
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some = clarification questions about IBnemo

 

Hi Sue,

 

Thank you very much for = the answers. Regarding the listed work items:

 

    c) = Standardize Intent-Based Nemo DSL (domain-specific language) for virtual = networks.

        IB-= Nemo runs over a RESTful (http) interface.

    d) Standardize = Intent-Based Nemo DSL for Security devices =  

    e) Standardize = Intent-Based Nemo DSL for compute devices. =   

 

 

 

What are the main = differences between Intent-Based Nemo domain-specific language and = YANG?

By focusing on these three areas, the scope of the = WG might be quite large. If it is to focus only on one of these three = work items, which one of them will you choose?

 

Best = regards,

Georgios

 

 

 

From:= = Susan Hares [mailto:shares@ndzh.com] =
Sent: Saturday, February 07, 2015 4:15 AM
To: = Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: = RE: [Ibnemo] some clarification questions about = IBnemo

 

Gergios:

 

Thank = you for these great questions.

 

 

1) = What is the motivation of starting this working group? =

The motivation for starting = this group comes out three things:  a) desire to maximum usage of = Network devices, b) Intent-Based theory and c) an 80/20 rule of = interfaces. 

 

Desire to maximum network devices: =

Today's networks connect = data centers to mobile users.  The Data Centers operate to maximize = the use of server's compute cycle, storage devices, and networks.  = A research study (2011-2012) examined how to maximize usage of compute, = storage, and networks using theoretical models.  This study showed = that if you optimize for any one facet (compute, storage, network) you = obtain 66% utilization of all facets.  However, if the applications = can communicate and negotiate their intent for compute, storage, or = network - the theoretical utilization can reach 95% or higher. =  

 

The potential higher utilization combined with the = lowering of costs due to with the virtualization of network devices = creates an economic environment that radically changes the cost dynamics = of IT technology. 

 

Intent-Based = Networks

The signaling of = the network changes via applications that direct SDN-based networks via = descriptive commands requires a large data flow between applications and = networks.   The application does not really want or need the = full description of the networks.   For example, a database = application simply needs to signal that it needs to connect to two other = database locations and exchange data with some maximum flow rate. =

 

Intent-based network signal this minimum required = information, and let the network set-up the rest.

 

80/20 rules of = applications

Some SDN = orchestrators are "god-boxes" that need to know and direct = everything.  However, most applications really need only to signal = intent.   The network engineers designing SDN orchestrators = are 20% or less of the total applications.   The other 80% of = applications use the 20% of total commands that request the high-level = requests.   Intent based Domain Specific languages (E.g. = focused on network) allow simple commands to be exchanged between the = application and the SDN controller across a RESTful interface (http = protocol). 

 

This = simpler interface for applications can enable a large class of new = applications to utilize the SDN controller.

 

2) = Are there use cases defined that are motivating this = work?

 

The use case motivating this work:  =

 

a) Simple interfaces for a new class of monitoring = and manage applications for the new NFV controllers controlling Carrier = access networks or Cable networks,

 

b) = Simple interfaces for the network-based application store that can load = query or load things on mobile networks,

 

c) = Large Database applications desiring to signal the network to set-up a = Virtual network to link database sites.  The set-up/tear down of = this network is controlled by the Application.

 

d) = Security devices seeking a short-term set-up of application layer = connection to exchange data.

 

3) = What are the work items?  

     a) Problem statement = and use cases document

    b) Intent Framework = Description for Networks, Security, Storage, Compute =  

 

    c) Standardize Intent-Based Nemo = DSL (domain-specific language) for virtual networks.

        IB-N= emo runs over a RESTful (http) interface.

    d) Standardize Intent-Based = Nemo DSL for Security devices  

    e) Standardize Intent-Based = Nemo DSL for compute devices.   

 

4) Is = the main goal of the WG to standardize a new protocol, or to extend an = existing one?

 

The = main goal is to standardize a series of Domain-Specific languages which = run over RESTful interface (http).

 

5)  What is the relation of IBnemo with = existing IETF WGs?

 

      =             &= nbsp;           &n= bsp;        NBI   =      SDN    SBI   =

IB-Nemo (application) ---- = controller --- I2rs, netconf/netmod,

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp; SACM

 

NBI - = north bound interface

SBI - south = bound interface

 

Application protocols work such as  CoApp = (CORE) produce http constrained to small environment as a specialized = application protocol.  However, these protocols are not focused on = enabling an Intent-Based application protocols that will utilize NFV = architectures. 

 

Before = I launch into more details, please let me know if you have questions. =

 

Sue Hares

 

-----Original Message-----
From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, = 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] = some clarification questions about IBnemo

 

Hi = Sue, Hi all,

 

In a = previous email it is mentioned that:

 

"The Nemo-project group seeks to create a = simple Intent-Based inter-operable application protocol that forms a = simple NorthBound API (NB) for applications on any platform to control = the following : a) setup and take down of virtual networks between = virtual nodes, b) control transfer of data toward storage, and c) handle = compute devices with a the minimal set of intent-based = primitives."

 

Can = you please provide some clarifications on the following = points?

 

o) What is the motivation of starting this working = group? Are there use cases defined that are motivating this = work?

 

o) What are the work items? Is the main goal of the = WG to standardize a new protocol, or to extend an existing = one?

 

o)  What is the relation of IBnemo with = existing IETF WGs?

 

Best = regards,

Georgios

 

_______________________________________________=

Ibnemo mailing list

Ibnemo@ietf.org

https://www.ietf.org/mail= man/listinfo/ibnemo

------=_NextPart_000_041E_01D0455E.5E90BA90-- From nobody Tue Feb 10 17:02:30 2015 Return-Path: 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 0BCAB1A1B17 for ; Tue, 10 Feb 2015 17:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no 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 hWDTDXG-ALxk for ; Tue, 10 Feb 2015 17:02:12 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A41A1B12 for ; Tue, 10 Feb 2015 17:02:11 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Zhoutianran'" , "'Georgios Karagiannis'" References: <02d401d04284$381d6070$a8582150$@ndzh.com> In-Reply-To: Date: Tue, 10 Feb 2015 20:01:57 -0500 Message-ID: <048801d04596$55c63b50$0152b1f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0489_01D0456C.6CF4A020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJv6C97uS28twITRDNDOcmrbje+xgLpsRUnAmvAWscC3778dptppkng Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:02:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0489_01D0456C.6CF4A020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tianran: I agree that the static data model for configuration and operational status is the base model from netmod. However, if one includes the dynamic interface being defined in the I2RS model (pub/sub) then the yang modules could be considered dynamic supporting temporary configuration and publication/subscription. All of these are like machine code in the network. The dynamic nature of I2RS is a descriptive language instead of the prescriptive Intent-based Nemo. The current 100+ yang modules will have 10,000-20,000 model entities defined. Nemo's level of dynamic nature is at the intent level which makes it more powerful. Like a lever, Nemo's intent-based DSL indicate the application wants to move the network. An example of this is a "Big Data" application that wants to control setting up three sites for data transfer in order to do over-night processing for a company, The 15 primitives of Nemo specify the establishment of a virtual network via (node, link, action, policy) With the model primitives, you can also create a library of definitions that allow the Big Data Application to pre-set up the names of the nodes or links or flows to be more human readable. This makes the http:: stream to be human readable which the Network operators prefer. := | | Sue From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Tuesday, February 10, 2015 4:53 AM To: Georgios Karagiannis; Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Gergios, A big difference I noticed is that: YANG is used for describing static data model including data structure, and operations. IB-NEMO DSL can be used for programming, i.e. application can interact with the network using NEMO DSL. There are many other differences I think we need a gap analysis. Best Regards, Tianran Zhou (Ph.D.) Senior Network Researcher Huawei Technologies Co., Ltd. From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Tuesday, February 10, 2015 5:15 PM To: Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for virtual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific language and YANG? By focusing on these three areas, the scope of the WG might be quite large. If it is to focus only on one of these three work items, which one of them will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire to maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers operate to maximize the use of server's compute cycle, storage devices, and networks. A research study (2011-2012) examined how to maximize usage of compute, storage, and networks using theoretical models. This study showed that if you optimize for any one facet (compute, storage, network) you obtain 66% utilization of all facets. However, if the applications can communicate and negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to with the virtualization of network devices creates an economic environment that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based networks via descriptive commands requires a large data flow between applications and networks. The application does not really want or need the full description of the networks. For example, a database application simply needs to signal that it needs to connect to two other database locations and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everything. However, most applications really need only to signal intent. The network engineers designing SDN orchestrators are 20% or less of the total applications. The other 80% of applications use the 20% of total commands that request the high-level requests. Intent based Domain Specific languages (E.g. focused on network) allow simple commands to be exchanged between the application and the SDN controller across a RESTful interface (http protocol). This simpler interface for applications can enable a large class of new applications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications for the new NFV controllers controlling Carrier access networks or Cable networks, b) Simple interfaces for the network-based application store that can load query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a Virtual network to link database sites. The set-up/tear down of this network is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connection to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Compute c) Standardize Intent-Based Nemo DSL (domain-specific language) for virtual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend an existing one? The main goal is to standardize a series of Domain-Specific languages which run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained to small environment as a specialized application protocol. However, these protocols are not focused on enabling an Intent-Based application protocols that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions. Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operable application protocol that forms a simple NorthBound API (NB) for applications on any platform to control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) handle compute devices with a the minimal set of intent-based primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cases defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo ------=_NextPart_000_0489_01D0456C.6CF4A020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tianran:

 

I agree that the static = data model for configuration and operational status is the base model = from netmod.

However, if one includes the dynamic interface = being defined in the I2RS model (pub/sub) then the yang modules could be = considered  dynamic supporting temporary configuration and = publication/subscription. 

 

All of these are like = machine code in the network.  The dynamic nature of I2RS is a = descriptive language instead of the prescriptive Intent-based = Nemo.   The current 100+ yang modules will have 10,000-20,000 = model entities defined.

 

Nemo’s level of = dynamic nature is at the intent level which makes it more = powerful.  Like a lever, Nemo’s intent-based DSL indicate the = application wants to move the network. An example of this is a = “Big Data” application that wants to control setting up = three sites for data transfer in order to do over-night processing for a = company,

 

The 15 primitives of = Nemo specify the establishment of a virtual network via (node, link, = action, policy)  With the model primitives, you can also create a = library of definitions that allow the Big Data Application to pre-set up = the names of the nodes or links or flows to be more human readable. =  This makes the http:: stream to be human readable which the = Network operators prefer.

 

 

<model_definition_cmd> :=3D = <node_definition> | <link_definition> | = <action_definition>

 

 

Sue =

 

From:= = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of = Zhoutianran
Sent: Tuesday, February 10, 2015 4:53 = AM
To: Georgios Karagiannis; Susan Hares
Cc: = ibnemo@ietf.org
Subject: Re: [Ibnemo] some clarification = questions about IBnemo

 

Hi = Gergios,

 

A big difference I = noticed is that:

YANG is used for = describing static data model including data structure, and = operations.

IB-NEMO DSL can be used = for programming, i.e. application can interact with the network using = NEMO DSL.

 

There are many other = differences I think we need a gap analysis.

 

Best = Regards,

 

Tianran Zhou = (Ph.D.)

Senior Network = Researcher

Huawei Technologies Co., = Ltd.

 

 

Hi = Sue,

 =

Thank you very much for = the answers. Regarding the listed work items:

 =

    c) = Standardize Intent-Based Nemo DSL (domain-specific language) for virtual = networks.

    =     IB-Nemo runs over a RESTful (http) interface. =

    = d) Standardize Intent-Based Nemo DSL for Security devices =  

    = e) Standardize Intent-Based Nemo DSL for compute devices. =   

 =

 =

 =

What are the main = differences between Intent-Based Nemo domain-specific language and = YANG?

By focusing on these = three areas, the scope of the WG might be quite large. If it is to focus = only on one of these three work items, which one of them will you = choose?

 =

Best = regards,

Georgios

 =

 

 

From: Susan Hares [mailto:shares@ndzh.com] =
Sent: Saturday, February 07, 2015 4:15 AM
To: = Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: = RE: [Ibnemo] some clarification questions about = IBnemo

 

Gergios:

 

Thank = you for these great questions.

 

 

1) = What is the motivation of starting this working group? =

The motivation for starting this = group comes out three things:  a) desire to maximum usage of = Network devices, b) Intent-Based theory and c) an 80/20 rule of = interfaces. 

 

Desire to maximum network devices: =

Today's networks connect data = centers to mobile users.  The Data Centers operate to maximize the = use of server's compute cycle, storage devices, and networks.  A = research study (2011-2012) examined how to maximize usage of compute, = storage, and networks using theoretical models.  This study showed = that if you optimize for any one facet (compute, storage, network) you = obtain 66% utilization of all facets.  However, if the applications = can communicate and negotiate their intent for compute, storage, or = network - the theoretical utilization can reach 95% or higher. =  

 

The = potential higher utilization combined with the lowering of costs due to = with the virtualization of network devices creates an economic = environment that radically changes the cost dynamics of IT = technology. 

 

Intent-Based = Networks

The signaling of the network = changes via applications that direct SDN-based networks via descriptive = commands requires a large data flow between applications and = networks.   The application does not really want or need the = full description of the networks.   For example, a database = application simply needs to signal that it needs to connect to two other = database locations and exchange data with some maximum flow rate. =

 

Intent-based network signal this = minimum required information, and let the network set-up the rest. =

 

80/20 rules of = applications

Some SDN orchestrators are = "god-boxes" that need to know and direct everything.  = However, most applications really need only to signal = intent.   The network engineers designing SDN orchestrators = are 20% or less of the total applications.   The other 80% of = applications use the 20% of total commands that request the high-level = requests.   Intent based Domain Specific languages (E.g. = focused on network) allow simple commands to be exchanged between the = application and the SDN controller across a RESTful interface (http = protocol). 

 

This = simpler interface for applications can enable a large class of new = applications to utilize the SDN controller.

 

2) = Are there use cases defined that are motivating this = work?

 

The use = case motivating this work: 

 

a) = Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable = networks,

 

b) = Simple interfaces for the network-based application store that can load = query or load things on mobile networks,

 

c) Large = Database applications desiring to signal the network to set-up a Virtual = network to link database sites.  The set-up/tear down of this = network is controlled by the Application.

 

d) = Security devices seeking a short-term set-up of application layer = connection to exchange data.

 

3) What = are the work items?  

     a) = Problem statement and use cases document

    b) Intent = Framework Description for Networks, Security, Storage, Compute =  

 

    c) Standardize = Intent-Based Nemo DSL (domain-specific language) for virtual networks. =

      =   IB-Nemo runs over a RESTful (http) interface. =

    d) = Standardize Intent-Based Nemo DSL for Security devices =  

    e) = Standardize Intent-Based Nemo DSL for compute devices. =   

 

4) Is = the main goal of the WG to standardize a new protocol, or to extend an = existing one?

 

The main = goal is to standardize a series of Domain-Specific languages which run = over RESTful interface (http).

 

5)  = What is the relation of IBnemo with existing IETF = WGs?

 

      =             &= nbsp;           &n= bsp;        NBI   =      SDN    SBI   =

IB-Nemo (application) ---- = controller --- I2rs, netconf/netmod,

      =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;    SACM

 

NBI - = north bound interface

SBI - south bound interface =

 

Application protocols work such as =  CoApp (CORE) produce http constrained to small environment as a = specialized application protocol.  However, these protocols are not = focused on enabling an Intent-Based application protocols that will = utilize NFV architectures. 

 

Before I = launch into more details, please let me know if you have questions. =

 

Sue = Hares

 

-----Original Message-----
From: = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, = 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] = some clarification questions about IBnemo

 

Hi Sue, = Hi all,

 

In a = previous email it is mentioned that:

 

"The Nemo-project group seeks = to create a simple Intent-Based inter-operable application protocol that = forms a simple NorthBound API (NB) for applications on any platform to = control the following : a) setup and take down of virtual networks = between virtual nodes, b) control transfer of data toward storage, and = c) handle compute devices with a the minimal set of intent-based = primitives."

 

Can you = please provide some clarifications on the following = points?

 

o) What = is the motivation of starting this working group? Are there use cases = defined that are motivating this work?

 

o) What = are the work items? Is the main goal of the WG to standardize a new = protocol, or to extend an existing one?

 

o)  = What is the relation of IBnemo with existing IETF = WGs?

 

Best = regards,

Georgios

 

____________________________________= ___________

Ibnemo mailing = list

Ibnemo@ietf.org

https://www.ietf.org/mail= man/listinfo/ibnemo

------=_NextPart_000_0489_01D0456C.6CF4A020-- From nobody Tue Feb 10 17:19:46 2015 Return-Path: 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 DFB8D1A1A46 for ; Tue, 10 Feb 2015 17:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nnMyuwdvdTKQ for ; Tue, 10 Feb 2015 17:19:30 -0800 (PST) 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 CEF831A1A17 for ; Tue, 10 Feb 2015 17:19:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM50569; Wed, 11 Feb 2015 01:19:27 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Feb 2015 01:19:27 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 11 Feb 2015 09:19:15 +0800 From: Zhoutianran To: Susan Hares , Georgios Karagiannis Thread-Topic: [Ibnemo] some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTABGp1kAAKNxa4AAEelTwAAPLMuAABEtV9A= Date: Wed, 11 Feb 2015 01:19:13 +0000 Message-ID: References: <02d401d04284$381d6070$a8582150$@ndzh.com> <048801d04596$55c63b50$0152b1f0$@ndzh.com> In-Reply-To: <048801d04596$55c63b50$0152b1f0$@ndzh.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_BBA82579FD347748BEADC4C445EA0F2166B6B456nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:19:40 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2166B6B456nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, You are right. It's interesting to introduce I2RS for the comparison. I2RS is dynamic compared to YANG. And IBNEMO sits in a higher level compared to I2RS. Tianran From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, February 11, 2015 9:02 AM To: Zhoutianran; Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Tianran: I agree that the static data model for configuration and operational status= is the base model from netmod. However, if one includes the dynamic interface being defined in the I2RS mo= del (pub/sub) then the yang modules could be considered dynamic supporting= temporary configuration and publication/subscription. All of these are like machine code in the network. The dynamic nature of I= 2RS is a descriptive language instead of the prescriptive Intent-based Nemo= . The current 100+ yang modules will have 10,000-20,000 model entities de= fined. Nemo's level of dynamic nature is at the intent level which makes it more p= owerful. Like a lever, Nemo's intent-based DSL indicate the application wa= nts to move the network. An example of this is a "Big Data" application tha= t wants to control setting up three sites for data transfer in order to do = over-night processing for a company, The 15 primitives of Nemo specify the establishment of a virtual network vi= a (node, link, action, policy) With the model primitives, you can also cre= ate a library of definitions that allow the Big Data Application to pre-set= up the names of the nodes or links or flows to be more human readable. Th= is makes the http:: stream to be human readable which the Network operators= prefer. :=3D | | Sue From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran Sent: Tuesday, February 10, 2015 4:53 AM To: Georgios Karagiannis; Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Gergios, A big difference I noticed is that: YANG is used for describing static data model including data structure, and= operations. IB-NEMO DSL can be used for programming, i.e. application can interact with= the network using NEMO DSL. There are many other differences I think we need a gap analysis. Best Regards, Tianran Zhou (Ph.D.) Senior Network Researcher Huawei Technologies Co., Ltd. From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Tuesday, February 10, 2015 5:15 PM To: Susan Hares Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific lan= guage and YANG? By focusing on these three areas, the scope of the WG might be quite large.= If it is to focus only on one of these three work items, which one of them= will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire t= o maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 = rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers op= erate to maximize the use of server's compute cycle, storage devices, and n= etworks. A research study (2011-2012) examined how to maximize usage of co= mpute, storage, and networks using theoretical models. This study showed t= hat if you optimize for any one facet (compute, storage, network) you obtai= n 66% utilization of all facets. However, if the applications can communic= ate and negotiate their intent for compute, storage, or network - the theor= etical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to= with the virtualization of network devices creates an economic environment= that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based= networks via descriptive commands requires a large data flow between appli= cations and networks. The application does not really want or need the fu= ll description of the networks. For example, a database application simpl= y needs to signal that it needs to connect to two other database locations = and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the = network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everyth= ing. However, most applications really need only to signal intent. The n= etwork engineers designing SDN orchestrators are 20% or less of the total a= pplications. The other 80% of applications use the 20% of total commands = that request the high-level requests. Intent based Domain Specific langua= ges (E.g. focused on network) allow simple commands to be exchanged between= the application and the SDN controller across a RESTful interface (http pr= otocol). This simpler interface for applications can enable a large class of new app= lications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable ne= tworks, b) Simple interfaces for the network-based application store that can load = query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a V= irtual network to link database sites. The set-up/tear down of this networ= k is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connec= tion to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Comput= e c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend a= n existing one? The main goal is to standardize a series of Domain-Specific languages which= run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained t= o small environment as a specialized application protocol. However, these = protocols are not focused on enabling an Intent-Based application protocols= that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions= . Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo --_000_BBA82579FD347748BEADC4C445EA0F2166B6B456nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sue,

 

You are right. It’s int= eresting to introduce I2RS for the comparison.

I2RS is dynamic compared to Y= ANG.

And IBNEMO sits in a higher l= evel compared to I2RS.

 

 

 

Tianran

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, February 11, 2015 9:02 AM
To: Zhoutianran; Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Tianran= :

&n= bsp;

I agree= that the static data model for configuration and operational status is the= base model from netmod.

However= , if one includes the dynamic interface being defined in the I2RS model (pu= b/sub) then the yang modules could be considered  dynamic supporting t= emporary configuration and publication/subscription. 

&n= bsp;

All of = these are like machine code in the network.  The dynamic nature of I2R= S is a descriptive language instead of the prescriptive Intent-based Nemo.&= nbsp;  The current 100+ yang modules will have 10,000-20,000 model entities defined.

&n= bsp;

Nemo= 217;s level of dynamic nature is at the intent level which makes it more po= werful.  Like a lever, Nemo’s intent-based DSL indicate the appl= ication wants to move the network. An example of this is a “Big Data” application that wants to control setting up thre= e sites for data transfer in order to do over-night processing for a compan= y,

&n= bsp;

The 15 = primitives of Nemo specify the establishment of a virtual network via (node= , link, action, policy)  With the model primitives, you can also creat= e a library of definitions that allow the Big Data Application to pre-set up the names of the nodes or links or flows to= be more human readable.  This makes the http:: stream to be human rea= dable which the Network operators prefer.

 <= o:p>

&n= bsp;

&l= t;model_definition_cmd> :=3D <node_definition> | <link_d= efinition> | <action_definition>

&n= bsp;

&n= bsp;

Sue

&n= bsp;

From: Ibnemo [ma= ilto:ibnemo-bounces@ietf.org] On Behalf Of Zhoutianran
Sent: Tuesday, February 10, 2015 4:53 AM
To: Georgios Karagiannis; Susan Hares
Cc: ibnemo@ietf.org
Subject: Re: [Ibnemo] some clarification questions about IBnemo=

 

Hi Gergios,=

 

A big difference I noticed is= that:

YANG is used for describing s= tatic data model including data structure, and operations.

IB-NEMO DSL can be used for p= rogramming, i.e. application can interact with the network using NEMO DSL.<= o:p>

 

There are many other differen= ces I think we need a gap analysis.

 

Best Regards,

 

Tianran Zhou (Ph.D.)

Senior Network Researcher

Huawei Technologies Co., Ltd.=

 

From: Ibnemo [ma= ilto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Tuesday, February 10, 2015 5:15 PM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: Re: [Ibnemo] some clarification questions about IBnemo=

 

Hi Sue,

&nbs= p;

Thank you= very much for the answers. Regarding the listed work items:

&nbs= p;

 =    c) Standardize Intent-Based Nemo DSL (domain-specific language= ) for virtual networks.

 =        IB-Nemo runs over a RESTful (http= ) interface.

 =    d) Standardize Intent-Based Nemo DSL for Security devices=  

 =    e) Standardize Intent-Based Nemo DSL for compute devices.=   

&= nbsp;

&nbs= p;

&nbs= p;

What are = the main differences between Intent-Based Nemo domain-specific language and= YANG?

By focusi= ng on these three areas, the scope of the WG might be quite large. If it is= to focus only on one of these three work items, which one of them will you= choose?

&nbs= p;

Best rega= rds,

Georgios<= o:p>

&nbs= p;

&n= bsp;

&n= bsp;

From: Susan Hares [mailt= o:shares@ndzh.com]
Sent: Saturday, February 07, 2015 4:15 AM
To: Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Gergios:

 

Thank you for these great qu= estions.

 

 

1) What is the motivation= of starting this working group?

The motivation for starting = this group comes out three things:  a) desire to maximum usage of Netw= ork devices, b) Intent-Based theory and c) an 80/20 rule of interfaces.&nbs= p;

 

Desire to maximum netw= ork devices:

Today's networks connect dat= a centers to mobile users.  The Data Centers operate to maximize the u= se of server's compute cycle, storage devices, and networks.  A resear= ch study (2011-2012) examined how to maximize usage of compute, storage, and networks using theoretical models.  Th= is study showed that if you optimize for any one facet (compute, storage, n= etwork) you obtain 66% utilization of all facets.  However, if the app= lications can communicate and negotiate their intent for compute, storage, or network - the theoretical utilization can = reach 95% or higher.  

 

The potential higher utiliza= tion combined with the lowering of costs due to with the virtualization of = network devices creates an economic environment that radically changes the = cost dynamics of IT technology. 

 

Intent-Based Networks<= o:p>

The signaling of the network= changes via applications that direct SDN-based networks via descriptive co= mmands requires a large data flow between applications and networks.  =  The application does not really want or need the full description of the networks.   For example, a data= base application simply needs to signal that it needs to connect to two oth= er database locations and exchange data with some maximum flow rate.

 

Intent-based network signal = this minimum required information, and let the network set-up the rest.

 

80/20 rules of applica= tions

Some SDN orchestrators are &= quot;god-boxes" that need to know and direct everything.  However= , most applications really need only to signal intent.   The netw= ork engineers designing SDN orchestrators are 20% or less of the total applications.   The other 80% of applications use the = 20% of total commands that request the high-level requests.   Int= ent based Domain Specific languages (E.g. focused on network) allow simple = commands to be exchanged between the application and the SDN controller across a RESTful interface (http protocol).  =

 

This simpler interface for a= pplications can enable a large class of new applications to utilize the SDN= controller.

 

2) Are there use cases de= fined that are motivating this work?

 

The use case motivating this= work: 

 

a) Simple interfaces for a n= ew class of monitoring and manage applications for the new NFV controllers = controlling Carrier access networks or Cable networks,

 

b) Simple interfaces for the= network-based application store that can load query or load things on mobi= le networks,

 

c) Large Database applicatio= ns desiring to signal the network to set-up a Virtual network to link datab= ase sites.  The set-up/tear down of this network is controlled by the = Application.

 

d) Security devices seeking = a short-term set-up of application layer connection to exchange data.

 

3) What are the work items? =  

    &nbs= p;a) Problem statement and use cases document

    b) I= ntent Framework Description for Networks, Security, Storage, Compute  =

 

    c) Standa= rdize Intent-Based Nemo DSL (domain-specific language) for virtual networks= .

    &nbs= p;   IB-Nemo runs over a RESTful (http) interface.

    d) S= tandardize Intent-Based Nemo DSL for Security devices  

    e) S= tandardize Intent-Based Nemo DSL for compute devices.   

 

4) Is the main goal of the W= G to standardize a new protocol, or to extend an existing one?

 

The main goal is to standard= ize a series of Domain-Specific languages which run over RESTful interface = (http).

 

5)  What is the relatio= n of IBnemo with existing IETF WGs?

 

    &nbs= p;             =             &nb= sp;        NBI   &nb= sp;    SDN    SBI  

IB-Nemo (application) ---- c= ontroller --- I2rs, netconf/netmod,

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   SACM

 

NBI - north bound interface<= o:p>

SBI - south bound interface =

 

Application protocols work s= uch as  CoApp (CORE) produce http constrained to small environment as = a specialized application protocol.  However, these protocols are not = focused on enabling an Intent-Based application protocols that will utilize NFV architectures. 

 

Before I launch into more de= tails, please let me know if you have questions.

 

Sue Hares =

 

-----Original Message----- From: Ibnemo [mailto:ibnemo-boun= ces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification questions about IBnemo

 

Hi Sue, Hi all,

 

In a previous email it is me= ntioned that:

 

"The Nemo-project group= seeks to create a simple Intent-Based inter-operable application protocol = that forms a simple NorthBound API (NB) for applications on any platform to= control the following : a) setup and take down of virtual networks between virtual nodes, b) control transfer of dat= a toward storage, and c) handle compute devices with a the minimal set of i= ntent-based primitives."

 

Can you please provide some = clarifications on the following points?

 

o) What is the motivation of= starting this working group? Are there use cases defined that are motivati= ng this work?

 

o) What are the work items? = Is the main goal of the WG to standardize a new protocol, or to extend an e= xisting one?

 

o)  What is the relatio= n of IBnemo with existing IETF WGs?

 

Best regards,

Georgios

 

____________________________= ___________________

Ibnemo mailing list

Ibnemo@ietf.or= g

https://www.ietf.org/mailman/listinfo/ibnemo<= /span>

--_000_BBA82579FD347748BEADC4C445EA0F2166B6B456nkgeml512mbxchi_-- From nobody Tue Feb 10 19:31:39 2015 Return-Path: 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 48D001A001A for ; Tue, 10 Feb 2015 19:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 tCJKWTnjZJXM for ; Tue, 10 Feb 2015 19:31:31 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDA1A00F5 for ; Tue, 10 Feb 2015 19:31:31 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CB74AB2E0CB; Tue, 10 Feb 2015 22:31:30 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id BE466B2E0B3; Tue, 10 Feb 2015 22:31:30 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.185]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0224.002; Tue, 10 Feb 2015 22:31:31 -0500 From: "Natale, Bob" To: Susan Hares Thread-Topic: [Ibnemo] some clarification questions about IBnemo Thread-Index: AdBBJot8KCIWKNkkRKWxBg/YA63rTABXauIAAKNJ9UAAKDPoAAAB25Gg Date: Wed, 11 Feb 2015 03:31:29 +0000 Message-ID: References: <02d401d04284$381d6070$a8582150$@ndzh.com> <041d01d04588$476207a0$d62616e0$@ndzh.com> In-Reply-To: <041d01d04588$476207a0$d62616e0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.140.19.249] Content-Type: multipart/alternative; boundary="_000_A65E21691881E64DBF058A66E53068ED4C8B1185IMCMBX01MITREOR_" MIME-Version: 1.0 Archived-At: Cc: "ibnemo@ietf.org" Subject: Re: [Ibnemo] some clarification questions about IBnemo 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\)." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 03:31:38 -0000 --_000_A65E21691881E64DBF058A66E53068ED4C8B1185IMCMBX01MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, Wrt "Would it be helpful, if I describe a potential security DSL?" ... yes = (for me, at least) ... I would appreciate seeing what it might look like ..= . outline of possible fit with SUPA and I2NSF would be helpful too ... expe= ctation only high-level and rough draft at this stage, of course. Avanti, BobN From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, February 10, 2015 6:21 PM To: 'Georgios Karagiannis' Cc: ibnemo@ietf.org Subject: Re: [Ibnemo] some clarification questions about IBnemo Georgios: Nemo is a high level DSL North Bound Interface (NBI) for applications can u= se to talk to controller at the network layer. Application || Nemo DSL ---------- Controller (with Nemo Engine with nemo model) || || (SBI) || netconf (I2RS/config) Yang Is a descriptive rather than an intent based interface. It is extreme= ly words and will change a functions change in the network. Nemo as a DSL = will provide functions the user application wants. Yang modules will be 10,000s different items in at least 100+ module. Nemo 15 primitives with options. Would it be helpful, if I describe a potential security DSL? Sue From: Georgios Karagiannis [mailto:georgios.karagiannis@huawei.com] Sent: Tuesday, February 10, 2015 4:15 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Hi Sue, Thank you very much for the answers. Regarding the listed work items: c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. What are the main differences between Intent-Based Nemo domain-specific lan= guage and YANG? By focusing on these three areas, the scope of the WG might be quite large.= If it is to focus only on one of these three work items, which one of them= will you choose? Best regards, Georgios From: Susan Hares [mailto:shares@ndzh.com] Sent: Saturday, February 07, 2015 4:15 AM To: Georgios Karagiannis Cc: ibnemo@ietf.org Subject: RE: [Ibnemo] some clarification questions about IBnemo Gergios: Thank you for these great questions. 1) What is the motivation of starting this working group? The motivation for starting this group comes out three things: a) desire t= o maximum usage of Network devices, b) Intent-Based theory and c) an 80/20 = rule of interfaces. Desire to maximum network devices: Today's networks connect data centers to mobile users. The Data Centers op= erate to maximize the use of server's compute cycle, storage devices, and n= etworks. A research study (2011-2012) examined how to maximize usage of co= mpute, storage, and networks using theoretical models. This study showed t= hat if you optimize for any one facet (compute, storage, network) you obtai= n 66% utilization of all facets. However, if the applications can communic= ate and negotiate their intent for compute, storage, or network - the theor= etical utilization can reach 95% or higher. The potential higher utilization combined with the lowering of costs due to= with the virtualization of network devices creates an economic environment= that radically changes the cost dynamics of IT technology. Intent-Based Networks The signaling of the network changes via applications that direct SDN-based= networks via descriptive commands requires a large data flow between appli= cations and networks. The application does not really want or need the fu= ll description of the networks. For example, a database application simpl= y needs to signal that it needs to connect to two other database locations = and exchange data with some maximum flow rate. Intent-based network signal this minimum required information, and let the = network set-up the rest. 80/20 rules of applications Some SDN orchestrators are "god-boxes" that need to know and direct everyth= ing. However, most applications really need only to signal intent. The n= etwork engineers designing SDN orchestrators are 20% or less of the total a= pplications. The other 80% of applications use the 20% of total commands = that request the high-level requests. Intent based Domain Specific langua= ges (E.g. focused on network) allow simple commands to be exchanged between= the application and the SDN controller across a RESTful interface (http pr= otocol). This simpler interface for applications can enable a large class of new app= lications to utilize the SDN controller. 2) Are there use cases defined that are motivating this work? The use case motivating this work: a) Simple interfaces for a new class of monitoring and manage applications = for the new NFV controllers controlling Carrier access networks or Cable ne= tworks, b) Simple interfaces for the network-based application store that can load = query or load things on mobile networks, c) Large Database applications desiring to signal the network to set-up a V= irtual network to link database sites. The set-up/tear down of this networ= k is controlled by the Application. d) Security devices seeking a short-term set-up of application layer connec= tion to exchange data. 3) What are the work items? a) Problem statement and use cases document b) Intent Framework Description for Networks, Security, Storage, Comput= e c) Standardize Intent-Based Nemo DSL (domain-specific language) for vir= tual networks. IB-Nemo runs over a RESTful (http) interface. d) Standardize Intent-Based Nemo DSL for Security devices e) Standardize Intent-Based Nemo DSL for compute devices. 4) Is the main goal of the WG to standardize a new protocol, or to extend a= n existing one? The main goal is to standardize a series of Domain-Specific languages which= run over RESTful interface (http). 5) What is the relation of IBnemo with existing IETF WGs? NBI SDN SBI IB-Nemo (application) ---- controller --- I2rs, netconf/netmod, SACM NBI - north bound interface SBI - south bound interface Application protocols work such as CoApp (CORE) produce http constrained t= o small environment as a specialized application protocol. However, these = protocols are not focused on enabling an Intent-Based application protocols= that will utilize NFV architectures. Before I launch into more details, please let me know if you have questions= . Sue Hares -----Original Message----- From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Georgios Karagia= nnis Sent: Thursday, February 05, 2015 4:32 AM To: Susan Hares Cc: ibnemo@ietf.org Subject: [Ibnemo] some clarification questions about IBnemo Hi Sue, Hi all, In a previous email it is mentioned that: "The Nemo-project group seeks to create a simple Intent-Based inter-operabl= e application protocol that forms a simple NorthBound API (NB) for applicat= ions on any platform to control the following : a) setup and take down of v= irtual networks between virtual nodes, b) control transfer of data toward s= torage, and c) handle compute devices with a the minimal set of intent-base= d primitives." Can you please provide some clarifications on the following points? o) What is the motivation of starting this working group? Are there use cas= es defined that are motivating this work? o) What are the work items? Is the main goal of the WG to standardize a new= protocol, or to extend an existing one? o) What is the relation of IBnemo with existing IETF WGs? Best regards, Georgios _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo --_000_A65E21691881E64DBF058A66E53068ED4C8B1185IMCMBX01MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Su= e,

=  

Wrt &= #8220;Would it be helpful, if I describe a potential security DSL?” &= #8230; yes (for me, at least) … I would appreciate seeing what it mig= ht look like … outline of possible fit with SUPA and I2NSF would be helpful too … expectation only high-level and rough draft at this= stage, of course.

=  

Avant= i,

BobN<= o:p>

=  

From: Ibnemo [mailto:ibnemo-bounces@ietf.org]= On Behalf Of Susan Hares
Sent: Tuesday, February 10, 2015 6:21 PM
To: 'Georgios Karagiannis'
Cc: ibnemo@ietf.org
Subject: Re: [Ibnemo] some clarification questions about IBnemo=

 

Georgios: <= /span>

 

Nemo is a high level D= SL North Bound Interface (NBI) for applications can use to talk to controll= er at the network layer. 

 

Application

   ||  = Nemo DSL

----------<= /span>

Controller (with Nemo Engine with nemo model)

  ||

  ||  (SBI) =

  || netconf= (I2RS/config)

 

Yang Is a descriptive = rather than an intent based interface.  It is extremely words and will= change a functions change in the network.  Nemo as a DSL will provide= functions the user application wants.

 

Yang modules will be 1= 0,000s different items in at least 100+ module.

Nemo 15 primitives wit= h options.

 

Would it be helpful, i= f I describe a potential security DSL?  

 

Sue =

From: Georgios Karagiannis [mailto:georgios.karagiannis@huawei= .com]
Sent: Tuesday, February 10, 2015 4:15 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Hi Sue,

 =

Thank you very much for = the answers. Regarding the listed work items:

 =

    c)= Standardize Intent-Based Nemo DSL (domain-specific language) for virtual n= etworks.

   &nb= sp;    IB-Nemo runs over a RESTful (http) interface.

   &nb= sp;d) Standardize Intent-Based Nemo DSL for Security devices  

   &nb= sp;e) Standardize Intent-Based Nemo DSL for compute devices.   

 

 =

 =

What are the main differ= ences between Intent-Based Nemo domain-specific language and YANG?

By focusing on these thr= ee areas, the scope of the WG might be quite large. If it is to focus only = on one of these three work items, which one of them will you choose?

 =

Best regards,=

Georgios

 =

 

 

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Saturday, February 07, 2015 4:15 AM
To: Georgios Karagiannis
Cc: ibnemo@ietf.org
Subject: RE: [Ibnemo] some clarification questions about IBnemo=

 

Gergios:

 

Thank you for these great questions. <= /p>

 

 

1) What is the motivation of starting this wor= king group?

The motivation for starting this group comes out = three things:  a) desire to maximum usage of Network devices, b) Inten= t-Based theory and c) an 80/20 rule of interfaces. 

 

Desire to maximum network devices:

Today's networks connect data centers to mobile u= sers.  The Data Centers operate to maximize the use of server's comput= e cycle, storage devices, and networks.  A research study (2011-2012) = examined how to maximize usage of compute, storage, and networks using theoretical models.  This study showed that if you= optimize for any one facet (compute, storage, network) you obtain 66% util= ization of all facets.  However, if the applications can communicate a= nd negotiate their intent for compute, storage, or network - the theoretical utilization can reach 95% or higher.  

 

The potential higher utilization combined with th= e lowering of costs due to with the virtualization of network devices creat= es an economic environment that radically changes the cost dynamics of IT t= echnology. 

 

Intent-Based Networks

The signaling of the network changes via applicat= ions that direct SDN-based networks via descriptive commands requires a lar= ge data flow between applications and networks.   The application= does not really want or need the full description of the networks.   For example, a database application simply ne= eds to signal that it needs to connect to two other database locations and = exchange data with some maximum flow rate.

 

Intent-based network signal this minimum required= information, and let the network set-up the rest.

 

80/20 rules of applications<= /b>

Some SDN orchestrators are "god-boxes" = that need to know and direct everything.  However, most applications r= eally need only to signal intent.   The network engineers designi= ng SDN orchestrators are 20% or less of the total applications.   The other 80% of applications use the 20% of total commands that request t= he high-level requests.   Intent based Domain Specific languages = (E.g. focused on network) allow simple commands to be exchanged between the= application and the SDN controller across a RESTful interface (http protocol). 

 

This simpler interface for applications can enabl= e a large class of new applications to utilize the SDN controller.

 

2) Are there use cases defined that are motiva= ting this work?

 

The use case motivating this work: 

 

a) Simple interfaces for a new class of monitorin= g and manage applications for the new NFV controllers controlling Carrier a= ccess networks or Cable networks,

 

b) Simple interfaces for the network-based applic= ation store that can load query or load things on mobile networks,

 

c) Large Database applications desiring to signal= the network to set-up a Virtual network to link database sites.  The = set-up/tear down of this network is controlled by the Application.

 

d) Security devices seeking a short-term set-up o= f application layer connection to exchange data.

 

3) What are the work items?  

     a) Problem statemen= t and use cases document

    b) Intent Framework Descr= iption for Networks, Security, Storage, Compute  

 

    c) Standardize Intent-Based Ne= mo DSL (domain-specific language) for virtual networks.

        I= B-Nemo runs over a RESTful (http) interface.

    d) Standardize Intent-Bas= ed Nemo DSL for Security devices  

    e) Standardize Intent-Bas= ed Nemo DSL for compute devices.   

 

4) Is the main goal of the WG to standardize a ne= w protocol, or to extend an existing one?

 

The main goal is to standardize a series of Domai= n-Specific languages which run over RESTful interface (http).

 

5)  What is the relation of IBnemo with exis= ting IETF WGs?

 

         =             &nb= sp;            =      NBI        = ;SDN    SBI  

IB-Nemo (application) ---- controller --- I2rs, n= etconf/netmod,

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;SACM

 

NBI - north bound interface

SBI - south bound interface

 

Application protocols work such as  CoApp (C= ORE) produce http constrained to small environment as a specialized applica= tion protocol.  However, these protocols are not focused on enabling a= n Intent-Based application protocols that will utilize NFV architectures. 

 

Before I launch into more details, please let me = know if you have questions.

 

Sue Hares

 

-----Original Message-----
From: Ibnemo [mailto:ibnemo-boun= ces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Thursday, February 05, 2015 4:32 AM
To: Susan Hares
Cc: ibnemo@ietf.org
Subject: [Ibnemo] some clarification questions about IBnemo

 

Hi Sue, Hi all,

 

In a previous email it is mentioned that:

 

"The Nemo-project group seeks to create a si= mple Intent-Based inter-operable application protocol that forms a simple N= orthBound API (NB) for applications on any platform to control the followin= g : a) setup and take down of virtual networks between virtual nodes, b) control transfer of data toward storage, and c) = handle compute devices with a the minimal set of intent-based primitives.&q= uot;

 

Can you please provide some clarifications on the= following points?

 

o) What is the motivation of starting this workin= g group? Are there use cases defined that are motivating this work?

 

o) What are the work items? Is the main goal of t= he WG to standardize a new protocol, or to extend an existing one?

 

o)  What is the relation of IBnemo with exis= ting IETF WGs?

 

Best regards,

Georgios

 

_______________________________________________

Ibnemo mailing list

Ibnemo@ietf.org

https://www.i= etf.org/mailman/listinfo/ibnemo

--_000_A65E21691881E64DBF058A66E53068ED4C8B1185IMCMBX01MITREOR_--