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