[Ibnemo] Report on IB-Nemo meeting at IETF 93 on 7/23/2015 (20:00-21:15)

["Susan Hares" <[e-mail]>]

We had a second lively discussion during IETF 93 on Thursday (7/23/2015)
from 20:00-21:15.  

Attendees for Thursday meeting (7/23/2015) 

.         Bert Wijnen's  - Huawei / consultant 

.         Pedro A. Aranda -  Telefonica

.         Susan Hares - Huawei/consultant

.         Tianran Zhou - Huawei 

.         Hannu Flinck - Nokia networks

.         Alexander Clemm - Cisco 

.         Dan Romascanu - Avaya 

.         Andy Veitch - Netcracker

.         Hesham Eibakouny - Huawei 

.         Scott Bradner - Harvard University 

.         Mehmet Ersue - Nokia Networks

.         Benoit Claise  - Cisco 

.         Bing Liu Huawei 

.         Sheng Jian - Huawei 

.         Michael Scharf - ALU 

.         Sabine Ranriamasy - ALU 

.         Michael Kloberdans [Cable Labs] 

.         Anita  -   

Comments on the presentation: 

1)      [slide 12] Arrows go from processing engine and are labeled
"Network- Wide Data models".   Should these arrows be single direction or
dual headed? 

 

Sue's response: These arrows should be dual direction as the Nemo Language
Processing element will both read and write the Yang data models.   The
network-wide yang data models will be created by other groups. 

 

2)      [slide 12] The Higher-level Intent blocks (in green on slide 12)
could use Netconf.   

 

Sue's response:  It is unclear how the IB-Nemo commands would be expressed
in NETCONF.   The use of NETCONF may require more operations than the
IB-Nemo set. 

 

3)      [slide 12] Anita: Intent: Can those who wish to use Intent use Nemo?


a)      Concern: Does Nemo's intent have a different intent than other
intents? 

 

Sue's response: Nemo's Intent is focused on a minimal set of commands. 

 

b)      Concern: What is the canonical representation of Intent?

   

Sue's response:  The canonical representation of Intent is being discussed
in many forums.  

I will provide a summary to the ibnemo mail list as a separate item.  [Todo
#1] 

 

 

4)      What is Service-based Intent? 

a)      Sue's Response: Customer gets what he wants is the measure of
intent.  

 

b)      Anita: Network orders outside of the carrier could be done in Nemo
and then it would break into the "box commands".

  

Sue's response:   We need more clarity on the "box commands from Anita.  I
am unclear if box commands means CLI commands or something else.  I will
query the list regarding Anita's question [Todo #2] 

 

5)      There are multiple the interactions between the publication and
executive element?  

a)      Where do we pay the complexity fee of translating the Nemo? 

 

Sue's Response: "The Nemo's language engine translates from Nemo language to
IETF network-wide yang modules [see slide 12].   In the future, these IETF
network-wide yang modules should have a clearly defined way to translate to
device-specific yang modules.    Without these IETF network-wide yang
modules, the Nemo language engine translates Nemo commands to
device-specific yang modules or device-specific commands. " 

 

6)      Are all policies expressed in this language? 

a)      Sue's Response:  As far as we know all policies are expressed.
However, this is a good question to query to the ibnemo mail list.  

[To-do #3] 

 

7)      Security of what the user can do?  How bad can the Intent-user screw
up the network? [See slide 12] 

a)      Sue's  Response:  The security of the transport of Nemo commands
depends on the transport and the mutual identification of the Nemo interface
in the Application 

 

8)      Access completeness of the Nemo interaction? 

a)      Who is doing the Intent Interaction? 

b)      Who is the actor? 

c)      Is there compartmentalization of the work?

 

Sue's response: 

The Intent interaction occurs between the application (APP, Nemo Web Gui, or
Nemo script) in slide 12 and the Nemo Language Processing engine.  The
Intent actor is the application that sends the commands to the Nemo Language
Engine.   The Nemo Language Engine in turn interacts with the Yang
Network-wide Data Models.  

 

The compartmentalization of the Nemo Work is to carefully define the
language that sets-up and send the commands. 

 

9)      [Benoit Claise] Is IB-Nemo domain specific?  (a) If it is outside
the scope of IETF, leave it to the market to decide which open source
initiative would be selected.  (b) Configured service models are outside the
scope of the IETF.  (c) Use cases need to be stabilized - What is fast
enough for the Intent?  What exactly is happening in the use cases? 

 

Sub-Questions: 

 

a)      Benoit:  If it is outside the scope of the IETF; leave it to the
market to decide which open source initiative would be selected. 

 

Sue's comment:  The ibnemo effort desire to standardize Nemo - a simple
language for Intent expression. 

 

There are 3 Open Daylight Models (ODL) that working on Intent based
networking: 

 

.         ODL Network Intent Composition (NIC) -  which seeks to include all
intent in a single interface
(https://wiki.opendaylight.org/view/Network_Intent_Composition:Main),

.         ODL Nemo - which seeks to include the minimum set of Intent
commands plus modeling commands in a language, and

.         Group-Based Policy - which is growing toward the Intent from the
concept of contracts between end points.   

 

The open source market is moving with 3 different models, and it is not
clear that any of these models fits all the sizes of Intent.   Since ODL NIC
seeks to have all Intent commands in an interface, and ODL Nemo seeks to
have a minimal set within an interface, it is unlikely these two models will
converge.   

 

[to-do #4] The IB-Nemo list will discuss the differences between the
different open-source efforts.  A summarization of this work will be posted
as an FAQ on www.nemo-project.net. 

 

b)      Benoit: Configured service models are outside the scope of the IETF.


 

Sue's comment: It is unclear what Benoit Claise meant by configured service
models, so we need to ask Benoit to define what he means by "configured
service models."   [todo #5] 

 

c)      Use cases need to be stabilized

i)        What is fast enough for the Intent? 

ii)      What exactly is happening? 

 

Sue's comment:  The IBNemo list needs to work on the use cases.  This should
a strong forward focus for August and September. 

 

10)   Can Nemo do L3VPN from the LS3M? 

 

Sue's Comment:  IB-Nemo could be used to establish a L3VPN connection, but
the details of the additional models need to be worked out.   IB-Nemo needs
to prove that we can read service information from the network service
models.  [Todo #6] 

 

11)  Is IBNemo role based? 

 

Sue's Comment:  The demonstration showed that the can be an Intent from the
User level (see slide 12 and slide 15), and intent from the Operators (see
slide 16).   These are two different roles.  

 

Question: Does this make this role based? 

 

Sue's Comment:  We have different sets of  "intent  expression commands"
that can/will/may be used by actors in different roles (e.g. end-user,
network architect, etc).

 

12)  Why is this not just mininet expanded?  

 

Pedro Aranda's comments: 

.         The IB-Nemo implementation shown is the implementation of a
concept, not even a proof of concept.   

.         We used mininet because we wanted to show the IB-Nemo work
locally.  If we had relied on someone providing the connectivity to a lab
where we had an Open Daylight Controller which controlled a real
infrastructure (with real network elements) we would not have been able to
show a useful demo due to the poor quality WiFi service within the Prague
Hotel. 

 

Sue's comment: 

.         The source code for IB-Nemo in ODL is at:
https://wiki.opendaylight.org/view/NEMO:Main. 

.         The early demo code is there on top of the Helium release, but the
IB-Nemo is targeted for the Beryllium release.  

 

13)  The use cases need addition work to provide 

a)      Who is the actor? 

b)      How does it work in a home network environment? 

c)      How does it work with a service provider?

d)      Parental control application needs more 

 

Sue's Comment: We need to provide better use cases with these questions
answered.  We will solicit the ibnemo list for contributions.  [Todo #7] 

 

14)  Need additional details on why the 80/20 rule is useful.  These details
should include:

a)      What is the long-term benefit for applications? 

b)      Why does a more user-friendly interface help? 

c)      What is the benefit for the service provider? 

Sue's comment: We need to enhance our use cases during August [Todo #6] 

15)   [From email by Dan Romascanu] 

"The technical question raised by Sue is whether NETCONF and/or RESTCONF are
suitable for simpler possibly automated actions between applications and a
network management systems that use declarative (intent-based) policy
models, or we need something else?  It certainly is worth a discussion IMO.

Benoit's question response to these questions:  

.         The question is where should this discussion happen? In SUPA?

.         And should the outcome of this discussion influence the SUPA
results?

.         At the last [SUPA] BoF, I recall mentioning "I hope you don't want
a new protocol?" Answer: "no"

Sue's response:  Intent-Based Nemo's (IB-Nemo) focus is on a minimal set of
commands that can be passed over other transport protocols (E.g. http).
The question "new protocol" implies a transport protocol and commands.
IBnemo simply looks to pass a minimal set of commands to express Intent for
most applications.    IB-Nemo should discuss this differences between
IB-Nemo and other protocols (RESTCONF, NETCONF, and SUPA). 

SUPA is focused on generic models and its charter (per Benoit) for ECA and
Intent-based.  In summarizing SUPA, Benoit considers the larger generic
model for Intent-Based to be experimental.   This may be because of large
scope of a complete Intent interface.   IB-Nemo does not look to be a
"complete Intent interface" but an interface that express Intent for most
applications. 

[Todo #8:  Continue discussing on the ibnemo list the differences between
NETCONF/RESTCONF and IB-Nemo.]

 

Action items from Discussion: 

1.      Discuss the Canonical definition of Intent on the ibnemo list [from
question 3]  

2.      Discuss what is Service-based Intent on the ibnemo list, and try to
determine what "box commands" might be?  [from question 4] 

3.      Discuss if all policies capable of being expressed by Nemo? [from
question 6]. 

4.      The IB-Nemo list will discuss the differences between the different
open-source efforts.  A summarization of this work will be posted as an FAQ
on www.nemo-project.net.  [from question 9]. 

5.      Query Benoit Claise on his definition of configured service models
[from question 9], and post a thread regarding this to the ibnemo list. 

 

6.      Provide an example of how IB-Nemo could be used to support L3VPN
service model that L3SM is providing, and Discuss this on the ibnemo mail
list. 

 

7.      Solicit the ibnemo for use cases with these questions answered.  

o   Who is the actor? 

o   How does it work in a home network environment? 

o   How does it work with a service provider?

o   Parental control application needs more 

 

8.      Continue discussing on the IB-Nemo list the differences between
NETCONF/RESTCONF and IB-Nemo, and the differences between SUPA and IB-Nemo. 

 

Additional action items suggested at IETF: 

.         Get feedback from operator forms (NANOG, RIPE) via side-bar
meetings or presentations, 

.         Work with other ODL and ONF groups to create a clear definition of
Intent, 

.         Work with other ODL Intent groups to try to determine the position
of each group, and

.         Determine steps we need to take for the BOF at IETF 94 (Yokohama).