18:09:19 <dbainbri> #startmeeting f2f
18:09:19 <odl_meetbot> Meeting started Wed Feb 18 18:09:19 2015 UTC.  The chair is dbainbri. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:09:19 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:09:19 <odl_meetbot> The meeting name has been set to 'f2f'
18:09:37 <gzhao> #topic Roll Call
18:11:23 <tbachman> #info tbachman (Noiro)
18:12:37 * tbachman wonders wherre the rest of the Roll Call is :)
18:12:42 <tbachman> gzhao: thx for kicking that off
18:12:44 <tbachman> ah
18:12:50 <tbachman> gzhao: you’re not chair, so you can’t topic
18:12:56 <tbachman> dbainbri would have to make you one
18:13:24 <gzhao> tbachman: yeah,
19:06:55 <dbainbri> how do i make someone chair?
19:07:09 <dbainbri> #chair gzhao
19:07:09 <odl_meetbot> Current chairs: dbainbri gzhao
19:07:14 <dbainbri> guessed
19:07:25 <gzhao> #chair tbachman
19:07:25 <odl_meetbot> Current chairs: dbainbri gzhao tbachman
19:07:38 <tbachman> dbainbri: good guess ;)
19:08:14 <tbachman> #info dmentze says that HP has experience with commercial grade SDN controllers; hoping to bring that experience in for the benefit to ODL
19:08:19 * gzhao thinks rule of thumb is to put tbachman as chair
19:08:24 <tbachman> lol
19:08:58 <gzhao> #topic Multiple application support (Duane)
19:09:59 <tbachman> #info dmentze says the multi-writer problem can occur with a single API — app A and app B calling same API, can result in collision
19:11:01 <dbainbri> tbachman: thanks for taking notes
19:11:18 <tbachman> dbainbri: sure!  May be a bit spotty
19:11:21 <tbachman> trying to multi-task
19:11:29 <tbachman> others are welcome to join as well!
19:11:45 * tbachman looks for new odl-meetbot wonder-boy ShaunWackerly
19:12:57 <tbachman> #info dmentze says he doesn’t want to get stuck on the terminology; wants to address the technology, their definitions, and how do they address the problems that are trying to be solved
19:13:02 <gzhao> tbachman: ShaunWackerly concentrates on the big screen right now...
19:13:07 <tbachman> gzhao: ack :)
19:13:45 <tbachman> #info dmentze says the Intent API is used by applications to: specify desried network behavior; and exchange real-time network information
19:14:41 <tbachman> #Info goals include: easy for app-writiers (don’t need to become networking experts); suport multiple-apps (no need to coordinate — interface addresses potential for conflict); decoupled from physical network changes (apps don’t need to react or be aware of changes in the topology or technology)
19:14:46 <ShaunWackerly> tbachman: it is being recorded, so don't we not need to take notes?
19:15:00 <tbachman> ShaunWackerly: we usually do just in case — some folks read the minutes
19:15:03 <tbachman> up to you all
19:15:10 * tbachman doesn’t want to step on any toees
19:15:20 <ShaunWackerly> I prefer recording, so then we can all avoid typing :)
19:15:25 <tbachman> loll
19:15:40 <tbachman> ShaunWackerly: I defer to you ;)
19:16:05 <ShaunWackerly> :)
19:16:51 <ShaunWackerly> We'll have slides sent out and a recording to listen to, so I think that is sufficient.
19:16:58 <dbainbri> the benefit of notes is to call out points that are also in audio. be nice if you could tag the recording with timestamps (i.e at 5:13 someone said X)
19:17:19 <dbainbri> different people like different things.
19:17:27 <gzhao> +1, reading minutes is much easier than play back recording, key points in the #info
19:17:28 <dbainbri> also wondering if people are watching the IRC live
19:18:05 <tbachman> If folks want me to continue, am more than happy to do so
19:18:09 <tbachman> just let me know :)
19:18:20 <dbainbri> tbachman: +1 from me ;)
19:18:30 <gzhao> dbainbri: minutes has timestamp, so you can actually correlate to recording
19:18:43 <tbachman> we have one +1 and one (implicit) -2
19:18:47 <tbachman> sorry — minus 1
19:18:56 * gzhao reads tbachman 's minute all the time
19:18:57 <tbachman> (1 and 2 are dangerously close to each other ;) )
19:19:24 <ShaunWackerly> I'm find with meeting minutes, as long as I don't have to take them (since my brain either operates in "recording" or "engaging" mode)
19:19:38 <tbachman> lol
19:19:41 <tbachman> ShaunWackerly: no worries!
19:19:44 <tbachman> I’m more than happy
19:20:03 <ShaunWackerly> tbachman: thank you, much appreciated
19:20:12 <tbachman> ShaunWackerly: np!
19:21:37 <tbachman> #info dmentze provides a VOIP Call Optimization exmample
19:21:54 <tbachman> #info Step 1,  VOIP server provides a NOtify: new Lync session (lp1, lp2)
19:22:31 <tbachman> #info An Optimizer App receives the Notify, calls the SDN Controller with GetNetworkNode DPID, Port(Ip)
19:22:54 <tbachman> #info the Optimizer App calls the SDN Controller SendFlowMod(Write dscp, output port)
19:23:07 <ShaunWackerly> #info (and GetNetworkNode means "get me the location of two endpoints"
19:23:34 <tbachman> #info the SDN Controller makes an Openflow FlowMod(Write dscp, Output port) to the appropriate nodes
19:23:42 <tbachman> ShaunWackerly: thx :)
19:24:00 <tbachman> #info Another use case is Network Monitor
19:24:23 <tbachman> #info An admin selects a user to monitor — provides it to a Monitor App
19:24:32 <tbachman> #info the Monitor App calls GetNetworkNode DPID, Port(Ip)
19:24:51 <tbachman> #info the Monitor App calls SendFlowMod(output port+tunnel)
19:25:10 <tbachman> lol
19:25:11 <tbachman> oops
19:25:13 <tbachman> too slow
19:25:36 <tbachman> #info dmentze illustrates how the Monitor App and the Optimizer app can collide here
19:25:56 <tbachman> #info dmentze says this is the multi-writer problem, illustrated through multi-apps
19:26:21 <tbachman> #topic Prototype Intent API syntax presentation
19:26:55 <tbachman> #info dmentze provides of intent-based policy examples
19:27:36 <tbachman> #info example: “DNS queries are allowed, but only when directed to one of our authorized DNS servers and all of these DNS queries are to be inspected first by one of our IPS servers”
19:28:03 <tbachman> #info dmentze provides an example of the model
19:28:32 <tbachman> #info source group, destination group, classifier, policy, and context are the model elements
19:29:02 <tbachman> #info the source group and destination group intersect with the classifier and policy, all within the scope of a context
19:29:36 <tbachman> #info Intent are “principles” that applications and administrators specify to guide decisions on the treatment of traffic on the network
19:29:53 <tbachman> #ifo Policies are set for specific communication between two endpoint groups on the network
19:29:58 <tbachman> drat
19:30:07 <tbachman> #info Policies are set for specific communication between two endpoint groups on the network
19:30:19 <tbachman> #info Intent-based policies are network topology and technology independent
19:30:54 <tbachman> #info dmentze says that the concept of Dynamic Endpoint Groups have been mentioned on the wiki
19:31:07 <tbachman> #info source and destination endpoint groups specify the set of hosts for the policy
19:31:19 <tbachman> #info Group descriptions are Boolean expressions with endpoint attributes as terms
19:31:27 <tbachman> #info 3 types of EPGs are: ID, group, dynamic
19:31:32 <ShaunWackerly> #link https://wiki.opendaylight.org/view/Network_Intent_Composition:Dynamic_Attributes
19:31:33 <tbachman> #info dbainbri asks how hosts are defined
19:31:38 <tbachman> ShaunWackerly: thx!
19:32:07 <tbachman> #info mickey_spiegel says there’s been discussion on the mailing lists — doesn’t believe this has been completely resolved
19:32:42 <ShaunWackerly> #info CharlesClark says he defines endpoint as a source/sink of information
19:32:42 <tbachman> #info Atributes are applications and customer defined statically or dynamically applied to endpoints in the endpoint database; and dynamically evaluated by the SDN controller policy engine
19:32:55 <tbachman> #info Access control restricts permitted applications to use and change specific endpoint attributes
19:33:53 <tbachman> #info examples include: “employee AND multifactorAuthenticated”; “tablet AND corporateDevice”; “server2003sp3 AND NOT ufeiBios”
19:35:11 <ShaunWackerly> uh-oh
19:36:04 <ShaunWackerly> #info 3 types of endpoints are identification (ip/mac), group (administratively assigned), and dynamic (change w/network condition)
19:36:13 <dbainbri> so glad he came back.
19:36:16 <tbachman> #info someone asks difference between an endpoint group and an endpoint attribute
19:36:30 <tbachman> sorry — overactive mouse click :)
19:36:58 <ShaunWackerly> #info an attribute is a single value, and a group is a logical expression of attributes
19:37:20 <tbachman> ShaunWackerly: thx!
19:37:45 <ShaunWackerly> #info correction: 3 types of endpoint attributes, not 3 types of EPGs
19:37:49 <tbachman> lol
19:37:53 <tbachman> ShaunWackerly: beat me to it!
19:38:10 * tbachman pictures scribe western-style draw
19:38:11 <ShaunWackerly> (okay, I'm listening again) :)
19:38:18 * tbachman gets shot
19:38:20 <tbachman> k
19:38:42 <tbachman> #info dbainbri says that groups are very dynamic; difference has to do with rate of change
19:40:03 <tbachman> #info dmentze says dynamic is something changing on its own; group is something that is changed administratively
19:40:21 <tbachman> #info Extnsible policies are covered next
19:40:27 <ShaunWackerly> #info the 3-type distinction isn't codified into the prototype
19:40:42 <tbachman> #info policies decribe the treatement to be applied to the communication between endpoint groups
19:40:50 <tbachman> #info each intent contains a sequence of actions
19:40:58 <tbachman> #info policies are executed in the order specified
19:41:55 <tbachman> #info e.g. multiple inspect policy actions (service chaining) are performed according to the order specified.
19:44:39 <ShaunWackerly> #info Cathy asks if there is separate classifier for source + dest EPG
19:44:54 <tbachman> ShaunWackerly: thx - some of it is hard to make out
19:44:54 <ShaunWackerly> #info dmentze says our prototype chose to use single classifier for both
19:46:28 <ShaunWackerly> #info break for lunch, back @ 12:15
20:14:09 <dbainbri> 2 minute warning
20:16:43 <tbachman> dbainbri: ack
20:17:43 <ShaunWackerly> #info starting up again
20:19:20 * tbachman is having trouble operating his IRC client today :P
20:20:35 <ShaunWackerly> #info dbainbri asks if "traffic" is being used as "classifier"
20:20:36 * tbachman can’t hear the person talking
20:20:42 <ShaunWackerly> #info dmentze says yes
20:20:43 <tbachman> ShaunWackerly: thx!
20:21:04 <ShaunWackerly> #info dbainbri asks if "traffic" and "policy" could be combined into 'VOIP' in the example
20:21:13 <ShaunWackerly> #info CharlesClark says yes
20:21:37 <ShaunWackerly> #info CharlesClark says we chose a particular set of classifiers and actions to use in the prototype
20:22:37 <tbachman> #info mickey_spiegel says the first 3 things listed are what flows are being affected; the last one is what you do with it
20:23:24 <tbachman> #info note: this in the context of an Intent API, with an example like this: Intent(user1, employee, Traffic=all, Audit)
20:24:02 <tbachman> #info another example of the use of the Intent API is: Intent(user1, user2, traffic=voip, QOS(high))
20:25:14 <tbachman> #info dmentze says this slide isn’t about the actual interface — the interface was just a necesarry in order to demonstrate how it could be used
20:27:39 <tbachman> #info dmentze says the compiler takes the two intents and creates two compiled nodes
20:28:08 <tbachman> #info dmentze says the definition of orthogonality is that no packets can get the same region
20:28:16 <tbachman> ShaunWackerly: does that look right^^^^?
20:28:55 <tbachman> #info dmentze says this is an example of composition; compiled policies can possibly conflict
20:29:26 <tbachman> #info dmentze says in the VOIP Call Optimization and Monitor, the policy space is orthogonal
20:29:36 <ShaunWackerly> tbachman: close enough :)
20:29:43 <tbachman> #info mickey_spiegel says that in making this orthogonal, you’re making these as disjoint sets?
20:29:46 <ShaunWackerly> doing great.
20:29:47 <tbachman> #info dmentze says yes
20:29:50 <tbachman> ShaunWackerly: thx!
20:31:12 <ShaunWackerly> #info dmentze browses to unit test code for this example
20:31:41 <ShaunWackerly> #info dmentze explains that since this is a unit test, it is adding network basis to give a network upon which the prototype will operate
20:36:31 <ShaunWackerly> #info dmentze begins example 2
20:38:09 <ShaunWackerly> #info in dmentze's examples, "Monitor" translates to the following use case:
20:38:13 <ShaunWackerly> #link https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#Network_Monitoring_of_a_Single_User
20:38:39 <ShaunWackerly> #info in dmentze's examples, "Optimizer" translates to the following use case:
20:38:41 <ShaunWackerly> #link https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#Lync_call_QoS
20:39:04 <ShaunWackerly> #info in dmentze's examples, "Security" translates to the following use case:
20:39:06 <ShaunWackerly> #link https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#DNS_monitoring_for_infection
20:42:26 <gzhao> #info dbainbri  comments on scalability issue on  adding tags etc
20:42:39 <ShaunWackerly> #info mickey_spiegel questions whether wildcarding with exceptions (all hosts except 10.0.0.1) will result in explosion of output
20:43:29 <ShaunWackerly> #info CharlesClark says that some ideas exist for mitigating that problem
20:44:51 <ShaunWackerly> #info CharlesClark says that the prototype is displaying IP addresses, but it could also just display EPG expression instead
20:46:16 <ShaunWackerly> #info Cathy says intent specified "infected", asks how endpoint is associated with "infected"
20:46:31 <tbachman> ODL SoS :)
20:46:33 <ShaunWackerly> #info dmentze says a security service on the network tells the controller which endpoint is "infected"
20:47:16 * tbachman pictures bat-ODL-phone/signal
20:47:19 <mickey_spiegel> #info My question was whether the compiler output is in terms of individual endpoints or in terms of endpoint groups, e.g. the intersection of two endpoint groups
20:47:28 <mickey_spiegel> #info Heard the latter is correct
20:47:57 <ShaunWackerly> mickey_spiegel: thanks :)
20:48:04 <ShaunWackerly> that's correct
20:49:36 * tbachman has divided attention atm :(
20:52:36 * ShaunWackerly was listening, not recording
20:56:25 <ShaunWackerly> #info alagalah asks if endpoint attributes are tagged on multiple endpoints, then the endpoint database is queried to get the matching set of endpoints for a specific attribute or group
20:56:49 <ShaunWackerly> #info confirmed as correct interpretation
20:57:58 <ShaunWackerly> #info CharlesClark points out that example 1 was an example of composition (fulfilling both intents)
20:58:28 <ShaunWackerly> #info CharlesClark points out that example 2 was an example of conflict, where 'block' conflicts with 'set QoS' and a winner is chosen
21:00:42 <ShaunWackerly> #info dmentze identifies extensibility in endpoint database and codegenerator
21:03:02 <ShaunWackerly> #info dbainbri asks if policy compiler output should be written to ODL's existing model
21:03:31 <ShaunWackerly> #info dmentze says that what's being displayed is the intermediate language between policy compiler and codegenerator
21:03:52 <ShaunWackerly> #info alagalah points out that codegenerator is similar to a renderer in GBP
21:05:34 <gzhao> #info CharlesClark points out the code generation portion is plug-able, people can customize it.
21:07:38 <gzhao> #info dbainbri suggests ODL to have a common abstract model and plugin derive it to talk to device.
21:10:50 <ShaunWackerly> #info mickey_spiegel, dbainbri and others discuss whether things with network-wide view within ODL (GBP, OVSDB) talk to the intent API to get their work done, or whether something like GBP or OVSDB could set underneath codegenerator and retain its network-level view.
21:11:14 <ShaunWackerly> mickey_spiegel: please correct if I mis-stated. :)
21:13:44 <ShaunWackerly> #info mickey_spiegel asks if SFC would be incorporated into codegenerator
21:13:46 <mickey_spiegel> In terms of subject we were talking about, that seem correct
21:13:50 <ShaunWackerly> #info dmentze says we'll get to it later
21:15:04 <gzhao> #topic Endpoint database
21:15:36 <gzhao> #undo
21:15:36 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x19aab90>
21:15:46 <gzhao> #info end point database
21:15:56 <gzhao> #info dynamic SFC
21:18:35 <gzhao> #info mickey_spiegel notes some action such as allow and block has relations.
21:22:20 <gzhao> #info mickey_spiegel said inspect here means SFC
21:22:42 <mickey_spiegel> Charles said that, not me
21:22:58 <ShaunWackerly> gzhao: just to clarify, that was from CharlesClark :)
21:24:07 <gzhao> #undo
21:24:07 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1bac190>
21:24:22 <ShaunWackerly> #info dbainbri asks how this approach would accomodate path computation
21:24:27 <gzhao> #info CharlesClark said inspect here means SFC
21:27:30 <ShaunWackerly> #info dmentze says a slide later will address it
21:27:44 <ShaunWackerly> #info mickey_spiegel asks if a single composable flag is sufficient
21:27:53 <ShaunWackerly> #info CharlesClark says it would really end up being a matrix
21:42:21 <ShaunWackerly> #topic Policy Conflict Resolution
21:44:01 <gzhao> #info policy conflict resolution: exclusive->composable-> action precedence-> app priority
21:44:20 <gzhao> #info question who defines precedence
21:45:27 <gzhao> #info CharlesClark said you need to define actions before intent
21:49:25 <ShaunWackerly> #info ShaunWackerly said that actions are registered with policy compiler (for use by apps in Intent statements) and action translators are registered with the code generator (for use in translating an action to a native protocol, like OpenFlow).
21:56:01 <gzhao> #info CharlesClark said ODL needs to first declare a set of supported actions, then application can select from those actions,  dmentze said precedence is an attribute of action.
21:59:06 <ShaunWackerly> #topic Code Generator
21:59:08 <gzhao> #info daveL suggest not to use terms as policy and app
21:59:33 <ShaunWackerly> #dmentze identifies forwarding engine as that which does path computations
22:11:56 <ShaunWackerly> #info multiple people discuss how codegenerator and forwarding engine cooperate to control policy and forwarding together, without stomping on eachother.
22:42:16 <gzhao> #topic Service Function Chainiing
23:11:24 <gzhao> #info hideyuki asks for the relationship with the prototype  code with ODL NIC
23:21:19 <ShaunWackerly> #info CharlesClark says there is no relationship between the ONF SFC prototype and the prototype that dmentze presented today
23:22:02 <ShaunWackerly> #info multiple people discuss whether the prototype dmentze presented would make a good starting point for NIC, or whether it would be better to start from scratch or another prototype/code set.
23:23:19 <ShaunWackerly> #info dmentze points out that if the prototype leads to a NIC implementation, we'd need to place requirements on SFC to work with attributes
23:27:25 <ShaunWackerly> #topic Service Function Chaining
23:28:22 <ShaunWackerly> #info dlenrow says intent is an overlay
23:29:17 <ShaunWackerly> #info dlenrow says first you build physical layer, then build virtual layer on top of it. Intent is an overlay layer that comes in later that allows portability and external NBI support.
23:32:15 <ShaunWackerly> #info dlenrow identifies border control (ie: edge characteristics) and underlay control (ie: tunnels) as areas where physical specifics are needed, need layer on top
23:32:44 <ShaunWackerly> #info dlenrow identifies virtual function pool could be an EPG
23:33:27 <ShaunWackerly> #topic Service Function Chaining (by dbainbri)
23:34:48 <ShaunWackerly> #info dbainbri says we can look at SFC as a black box from the controller (or policy engine)
23:35:43 <ShaunWackerly> #info dbainbri says service functions could get injected into resource pools, where the policy engine could pick from that resource pool when it needs a service instance
23:36:17 <ShaunWackerly> #info dlenrow says this would allow a network fault to be handled by the controller, rather than a lower layer
23:37:48 <ShaunWackerly> #info dbainbri says that service functions could be exposed like endpoints, questions whether we are picking from a pool or merely resolving an attribute to a specific instance
23:38:51 <ShaunWackerly> #info dbainbri notes that a query may request a service instance, but include restrictions/criteria related to location
23:40:32 <ShaunWackerly> #info dbainbri and dlenrow discuss whether constraints are given as part of calling context, or if they are specified with each request (I think)
23:43:58 <ShaunWackerly> #info dbainbri shows that intents may decompose into more-and-more precision, including insertions of SFCs
23:47:54 <ShaunWackerly> #info louisfourie says it would be nice if we could tag service instances with attributes
23:48:36 <ShaunWackerly> #info CharlesClark explains that the prototype model had an EndpointGroup class, and a ServiceGroup which extended it (ie: both based on attributes)
23:49:51 <ShaunWackerly> #info dbainbri asks whether attributes have a value or namespace, or whether they merely exist in isolation
23:50:15 <ShaunWackerly> #info dbainbri says we should avoid building typing into attribute definition
23:51:25 <ShaunWackerly> #topic NIC API discussion
00:00:30 <ShaunWackerly> #info CathyZhang presents about composite endpoint descriptor (CED), which consists of a set of flexible endpoint descriptors
00:02:27 <ShaunWackerly> #info CathyZhang shows FEDs (flexible endpoint descriptors) as each having a type and value, combined in logical expressions
00:03:30 <ShaunWackerly> #info CathyZhang shows that FEDs could be included in endpoint groups to classify flow as part of endpoint group definition
00:04:13 <ShaunWackerly> #info CathyZhang says there would be a base set of well-known endpoint descriptor types, and that a CED may also references another CED.
00:04:46 <ShaunWackerly> gzhao: I don't know cathy's IRC username ... do you?
00:04:59 <gzhao> she doesn't have one
00:05:02 <gzhao> yet
00:05:07 <ShaunWackerly> thanks
00:05:11 <gzhao> sure
00:06:07 <ShaunWackerly> #info dlenrow asks if the current GBP project has higher-level EPG registry could be made compatible with (or used by) NIC
00:06:30 <ShaunWackerly> #info dbainbri says we have an existing endpoint database in the inventory
00:08:44 <ShaunWackerly> #info the EPG stored by GBP stores duplicate data as compared with inventory
00:09:18 <ShaunWackerly> #info dbainbri worries that duplicated data complicates adding endpoints
00:10:57 <ShaunWackerly> #info CathyZhang proposes that endpoints not be defined as a "host", but rather at any L1-L7 layer
00:11:13 <ShaunWackerly> #info CathyZhang says such a model is very flexible
00:12:17 <ShaunWackerly> #info (?) this flexible model would be difficult to map to what already exists and is tracked by ODL (hosts/OpenFlow/etc)
00:13:48 <ShaunWackerly> #info dlenrow says that NIC/Intent may need to extend what's already in ODL to get what it needs
00:14:00 <ShaunWackerly> #info dbainbri disagrees ...
00:15:41 <gzhao> #info discussion of where classifier should belong
00:17:31 <ShaunWackerly> #info dbainbri says reusability of components (classifier, EPG, etc) is important to him
00:22:05 <ShaunWackerly> mickey_spiegel, could you summarize what you stated in the notes?
00:48:27 <gzhao> #info ONF SFC discussion will be deferred to Friday's team meeting
00:49:08 <rukhsana> will the slides be posted to the mailing list/available on wiki?
00:56:15 <ShaunWackerly> ruksana: I believe all slides will be posted
00:56:41 <ShaunWackerly> Will make sure we discuss that in the wrap-up today.
00:56:44 <rukhsana> shaun: ok thanks
01:04:00 <gzhao> #topic terminology discussion
01:09:46 <gzhao> #action ShaunWackerly is going to put presentation slides on wiki
01:09:54 <gzhao> #endmeeting