16:59:26 <tbachman> #startmeeting gbp_arch 16:59:26 <odl_meetbot> Meeting started Fri Aug 1 16:59:26 2014 UTC. The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:59:26 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:26 <odl_meetbot> The meeting name has been set to 'gbp_arch' 17:01:55 <tbachman> #topic audiophiles rule 17:04:37 <tbachman> #topic agenda 17:04:40 <paulq> trying to join the hangout, getting permission denied. 17:04:47 <paulq> anyway to get whitelisted? 17:04:48 <tbachman> paulq: we’re on webex 17:04:51 <tbachman> just a sec... 17:04:55 <paulq> even better! 17:05:00 <tbachman> https://cisco.webex.com/ciscosales/j.php?MTID=mdfede3d482ceede44a93acdcca9f0e2e 17:05:03 <paulq> ty 17:05:06 <tbachman> np 17:06:29 <tbachman> I can hear you guys 17:06:36 <tbachman> There’s a bit of a “buzz” on there 17:07:15 <hemanthravi> can hear you...on mute 17:07:30 <tbachman> can see you too :) 17:08:34 <tbachman> mickey_spiegel: webex: https://cisco.webex.com/ciscosales/j.php?MTID=mdfede3d482ceede44a93acdcca9f0e2e 17:09:28 <tbachman> Is a laptop or something near a microphone? 17:09:31 <tbachman> Getting a buzz on the line 17:10:10 <tbachman> #info agenda items: 1) documentation; 2) service chaining 17:11:15 <tbachman> #topic documentation 17:11:26 <tbachman> #undo 17:11:26 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x2641b90> 17:11:33 <tbachman> #topic service chaining 17:11:57 <tbachman> #info paulq gives a high-level view of SFC project 17:12:50 <tbachman> #info a service chain is the intent, such as “give me firewall”, or “give me IPS" 17:13:01 <tbachman> #info that gets rendered into a service function path 17:13:30 <tbachman> #info where path is a specific device, and can be one or more paths to one intent 17:13:45 <tbachman> #info It can be mulitiple instances, or multiple instances of the same intent 17:14:06 <tbachman> #info there is a service function forwarder, which is “the switch" 17:14:21 <tbachman> #info and a service function, which connects to the service function forwarder 17:14:28 <tbachman> #info this is done to decouple the function from the forwarding 17:14:37 <tbachman> #info assigned by a basic mapping at the moment 17:14:54 <tbachman> #info The current model does not contain constraints 17:15:10 <tbachman> #info They create an overlay topology that links forwarders to each other 17:15:26 * tbachman watches dvorkinista rapid-hack MS PowerPoint 17:15:41 <tbachman> #info paths are identified by a path ID which is unique in a domain 17:15:50 <tbachman> #when a chain is rendered into a path, the ID gets created 17:16:02 <tbachman> #info Think of a path ID as a graph ID 17:16:38 <tbachman> #info where a path is a graph that is traversed for a given class of traffic 17:16:45 <tbachman> #info you can alter the path to alter the graph 17:17:16 <tbachman> #info the path is the service plane 17:17:21 <tbachman> #info dvorkinista asks if it includes the endpoints 17:17:27 <tbachman> #info paulq says it does not 17:17:38 <tbachman> #info it starts at a classification event, and ends at the end of the chain 17:17:48 <tbachman> #info where chain end is the last service function forwarder 17:18:41 <tbachman> #info The EP in GBP is the classification in SFC 17:18:56 <tbachman> #info classification defines which traffic enters which graph 17:19:08 <tbachman> #info this is indicated both in the model and on the wire 17:19:23 <tbachman> #info so at any point you can see where you are 17:19:33 <tbachman> #info dvorkinista says lets look at the expression of intent 17:20:12 <tbachman> #info there is a function, a type, a data plane locator (essentially a network address), an encap type — basic data plane stuff 17:20:27 <tbachman> #info a path is a colleciton of forwarder and functions 17:20:36 <tbachman> #info that is the rendering 17:20:47 <tbachman> #info the intent model is a series of types, agnostic of forwarders 17:21:05 <tbachman> #info paulq says that intent is list of service types 17:21:38 <tbachman> #info paulq says that they do not expect the user to say “I want FW 28”, but rather just “I want a FW" 17:21:52 <tbachman> #info and there is an implied order in the lists 17:22:01 <tbachman> #info dvorkinista asks if there is a terminal 17:22:08 <tbachman> #info paulq says that there isn’t currently 17:22:20 <tbachman> #info but that they’re working on that — specifying a classifier 17:22:38 <tbachman> #info dvorkinista asks if there’s anything else in the intent 17:22:41 <tbachman> #info paulq says no 17:23:10 <tbachman> #info dvorkinista asks if the types are mapped into functions 1-to-1 17:23:20 <tbachman> #info paulq says there can be more than one function of a given type 17:24:09 <tbachman> #info (i.e. one-to-one mapping of service tuypes to functions) 17:24:20 <tbachman> #info There is also a mapping of forwarders to functions 17:24:43 <tbachman> #info lenrow says he sees areas where there are issues with zero-resource service allocation 17:24:56 <tbachman> #undo 17:24:56 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x275d690> 17:25:08 <tbachman> lenrow says he sees areas where there are issues with zero-sum resource service allocation 17:25:27 <tbachman> #info lenrow is concerned about multiple entities controlling resources 17:26:24 <tbachman> #info lenrow says that the current propsal is that GBP is the sole resource to manage the ships-in-the-night problems with accessing resources such as flow tables 17:26:45 <tbachman> #info dvorkinista says that the idea for GBP is to specify the high-level intent, such as SFC 17:26:57 <tbachman> #info paulq says there are a lot of constraints that can be resolved locally 17:27:12 <tbachman> #info as an example, a constraint such as “least loaded FW” 17:27:30 <tbachman> #info SFC is not going to track djikstra’s algorithm, etc. 17:27:48 <tbachman> #info hemanth asks if paths are bi-directional 17:27:54 <tbachman> #info paulq says that paths are uni-directional 17:28:02 <tbachman> #info dvorkinista asks if intent is uni-directional 17:28:08 <tbachman> #info paulq says intent is uni-directional 17:28:22 <tbachman> #info paulq says they could optimize — it’s come up, but they haven’t optimized currently 17:28:41 <tbachman> #info dvorkinista says you could create a graph, and the way to interact with the graph is strictly bi-directional 17:29:03 <tbachman> #info the way the boundaries of the chain are defined are bi-directional 17:29:13 <tbachman> So that they way you connect to the chain is bi-directional 17:29:19 <tbachman> #info 17:29:22 <tbachman> #info So that they way you connect to the chain is bi-directional 17:29:35 <tbachman> #info but within the chain, it can use uni-directional constructs 17:31:32 <tbachman> #info paulq says that their current use of uni-directional intent is a question of whether they keep state to know that path forward is the same as path back 17:32:58 <tbachman> #info hemanthravi asks if the user has the ability to ask whether the forward and reverse path are related 17:34:03 <tbachman> #info dlenrow points out it would be great if this could be encapsulated in the virtual function container, so that the details don’t become part of the intent, and are part of the rendering 17:34:36 <tbachman> #info dvorkinista says one way to think of it is that those things come from an operational policy 17:35:00 <tbachman> #info and this way you don’t over-burden the intent 17:35:41 <tbachman> #info paulq notes that the whole point of SFC is to abstract out the plumbing 17:36:09 <tbachman> #info paulq says that they add a data plane header/shim to build these topologies without having to change the plumbing 17:36:27 <tbachman> #info and that metadata is carried on the wire, e.g. an ID for group 1 and group 2 17:36:45 <tbachman> #info dvorkinista asks if their using Network Service Headers (NSH) 17:36:54 <tbachman> #info paulq says yes, they’re doing this in NSH 17:37:02 <tbachman> #info dvorkinista asks if they’re looking at geneve? 17:37:09 <tbachman> #info paulq says that their current plan is NSH 17:37:41 <tbachman> #info paulq says that they’ve already done the first updates of NSH in OVS 17:37:50 <tbachman> #info they try to keep the metadata and transport separate 17:38:11 <tbachman> #info paulq says that they also allow services (not yet today in ODL), which allows services to inform other services of what they know. 17:38:24 <tbachman> #info where this context is put on the wire 17:38:46 <tbachman> #info which allows for things like dynamic alteration of the graph 17:39:18 <dlenrow> The graph on Mike's slie is Stephi (Graaf) 17:39:31 <tbachman> Is there a knife? 17:39:33 <tbachman> (ouch) 17:41:09 <tbachman> #info dvorkinista asks if this looks more like a tree when looked at uni-directionally 17:41:17 <tbachman> #info paulq says no, b/c they can be cyclical 17:41:25 <tbachman> #info e.g. FW => LB => FW 17:41:43 <tbachman> #info mickey_spiegel asks how they capture intent when it’s not just a chain 17:41:52 <tbachman> #info paulq says it’s a series of sub-graphs (chains that overlap) 17:42:17 <tbachman> #info dvorkinista asks if you have a cycle, and you go back to the perimiter FW, will it be the same graph or different graph 17:42:21 <tbachman> #info paulq says the same graph 17:42:39 <tbachman> #info the metadata in the dataplane allows you to break the cycles 17:43:07 <tbachman> #info paulq says to hop between graphs, there’s a classification event 17:43:32 <tbachman> #info paulq says as long as you don’t alter the path ID, you’re in the same graph 17:44:12 <tbachman> #info sanjay says services may be connected in a graph, but as far as a single flow is concerned, they will only utilize this in a chain fashion (i.e. everything is a chain) 17:44:23 <tbachman> #info paulq re-emphasizes that everything is a path 17:44:51 <tbachman> #info where forking would be two different paths 17:45:29 <tbachman> #info mickey_spiegel asks why path is being used instead of chain 17:46:08 <tbachman> #info paulq says chain is the abstraction (e.g. FW => LB => DPI), and path is the concrete realization of that (e.g. FW #21 => LB #13 => DPI #4) 17:51:03 <tbachman> #info paulq says the reason they talk about the service plane is to provide a level of abstraction 17:51:12 <tbachman> #info which is why they are transport-independent 17:51:51 <tbachman> #info mickey_spiegel asks if there’s any notion of terminal or interface 17:52:17 <tbachman> #info paulq says they purposelly don’t have that — just classification, as they don’t want to become the classification project/platform 17:53:21 <tbachman> #info mickey_spiegel says the problem is that having the abstraction draws the line as to who has the ability to decide paths 17:58:20 <tbachman> #info mickey_spiegel asks whether classification can indirectly reference decisions functions make without directly referencing them 17:59:47 <tbachman> #info mickey_spiegel asks what we want to do about intent for a graph vs. a chain 18:00:55 <tbachman> #info mickey_spiegel asks if paulq can provide a reference for their intent model 18:01:09 <tbachman> #info dlenrow said we can tack this on to the Monday use case/requirements meeting agenda 18:01:37 <tbachman> #info dvorkinista notes that he’ll be out starting next Thursday for a week (8/7-8/15) 18:02:04 <tbachman> #info mickey_spiegel asks if folks will be able to look at the model in time for monday’s meeting 18:02:30 <tbachman> #info paulq says that it’s covered in the yang files in the git repo 18:03:30 <tbachman> #link sanjay asks if you’d consider multiple VIPs for each service funciton, or can we limit a single VIP per service function 18:03:42 <tbachman> #info sanjay asks if you’d consider multiple VIPs for each service funciton, or can we limit a single VIP per service function 18:03:48 <paulq> this draft has most of the model -- might be a bit out of date but pretty close 18:03:48 <paulq> https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ 18:04:06 <tbachman> #link https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ <= link to yang model for SFC project 18:04:56 <paulq> minor point: that's the ietf draft that the YANG code is derived from 18:05:00 <tbachman> ah 18:05:12 <tbachman> let me look up the actual code in the git repo.... 18:05:16 <tbachman> #undo 18:05:16 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x2529910> 18:06:16 <tbachman> #link https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=tree;f=model/src/main/yang;h=abe368fdf09fc912b00625a76bddba9a03229f62;hb=218ea63128db2a9d2d1d8e10693a0ebcbe090860 link to yang models in git for SFC project 18:07:22 <tbachman> #info mickey_spiegel says he won’t be here on Friday next week 18:08:03 <tbachman> #topic documentation 18:09:34 <tbachman> #topic readams demo of OpenFlow Overlay renderer 18:10:12 <tbachman> #info readams says the current state is that a lot is working, but a few key pieces not there yet, which require additional changes to the OpenFlow plugin in ODL 18:11:00 <tbachman> #info readams is using a mininet environment, with some scripts to set up some policy 18:11:20 <tbachman> #info there’s a simple contract that allows web traffic and ICMP traffic, and two EPGs 18:11:54 <tbachman> #info readams demonstrates the flows written into the flow table 18:12:17 <tbachman> #info the policy model is rendered into an equivalent policy model, handling inheritance, etc. 18:12:47 <tbachman> #info The equivalent policy model is then used to create the flow entries in the switches 18:13:11 <tbachman> #info There are conventions used for the flow table: table 0 is used for port security 18:13:25 <tbachman> #info table 1 is used for the source EPG and source condition assignment 18:14:39 <tbachman> #info table 2 is used for destination EPG and destination condition assignment 18:14:46 <tbachman> #info last table is policy table 18:16:36 <tbachman> #info readams needs some extensions in the OF plugin in order to complete the implementation 18:17:27 <tbachman> #info everything up until the final packet delivery should work, until we get the extension 18:18:41 <tbachman> #info sanjay asks if we can check this out and run it ourselves 18:19:03 <tbachman> #info readams says that not currenlty, as it requires checking out several projects and building uncommitted patches 18:19:36 <tbachman> #info sanjay asks if readams can post the rest commands 18:22:04 <tbachman> #topic documentation 18:23:38 <tbachman> #info mickey_spiegel talks about the different doc requirements 18:23:45 <tbachman> #info installation is pretty straightforward 18:23:55 <tbachman> #info they want pre-installation, post-installation, etc. 18:24:16 <tbachman> #info mickey_spiegel didn’t see specific dates for documentation in the release plan 18:24:48 <tbachman> #info mickey_spiegel says that with that in mind, installation requires a little more content, but not a lot 18:25:19 <tbachman> #info confusion on the developer guide, etc. 18:25:55 <tbachman> #info mickey_spiegel asked mlemay differences between developer and user guids 18:27:04 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:ARCH#Team_Meeting <= link dscribing various documentation requirements 18:28:08 <tbachman> #info readams recommends just using what he’s provided on the wiki for the devloper guide 18:28:44 <tbachman> #info mickey_spiegel says the operations guide is optional 18:29:41 <tbachman> #info mickey_spiegel says that the user guide is required, but there’s confusion as to what exactly a user guide is 18:33:24 <tbachman> #link https://wiki.opendaylight.org/view/Sample_User_Guide <= link in ODL wiki for sample user guide 18:34:35 <tbachman> #info readams says that the UML probably isn’t going to be as helpful to users, as it requires a lot of explanation 18:35:14 <tbachman> #info readams says that a pseudo-cli type thing might be more helpful than the yang or JSON 18:40:35 <tbachman> #info mickey_spiegel says this needs to be converted to ASCII doc format 18:40:45 <tbachman> #info at which point the wiki becomes deprecated 18:41:56 <tbachman> #info mickey_spiegel asked mlemay whether the wiki and ASCII doc could be kept in sync, but mlemay said that the wiki was meant to be internal only 18:52:27 <tbachman> #link https://wiki.opendaylight.org/view/Sample_Developer_Guide <= link in ODL wiki for sample developer guide 18:55:10 <tbachman> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_Developer_Guide <= helium developers guide 18:55:30 <tbachman> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_User_Guide =< helium users guide 18:55:57 <tbachman> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Helium_Installation <= helium installation guide 18:57:51 <tbachman> #info mickey_spiegel suggests that we focus on generating content on the wiki, and then convert it 18:59:32 <tbachman> #info given that dvorkinista and mickey_spiegel will both be out next Friday, the arch group will not meet next Friday (8/8) 19:00:43 <tbachman> #endmeeting