17:58:26 <alagalah> #startmeeting GBP-150206
17:58:26 <odl_meetbot> Meeting started Fri Feb  6 17:58:26 2015 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:58:26 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:58:26 <odl_meetbot> The meeting name has been set to 'gbp_150206'
17:58:32 <alagalah> #chair tbachman
17:58:32 <odl_meetbot> Current chairs: alagalah tbachman
17:59:13 <tbachman> #topic agenda
17:59:33 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting Agenda for today’s meeting
18:00:24 <tbachman> #link https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_arch_status/opendaylight-group-policy-gbp_arch_status.2015-01-30-18.00.html last week’s meeting minutes
18:01:53 <tbachman> #topic SFC GBP Integration
18:02:22 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-January/000682.html email describing multiple renderer solution
18:06:35 <tbachman> sounds of jeapardy music play in the background
18:07:05 <tbachman> answer: who is rpenno?
18:07:27 <tbachman> #info alagalah says both GBP and SFC would like a POC for the Lithium release
18:07:50 <tbachman> #link https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration Wiki page describing a possible POC
18:08:18 <tbachman> #info alagalah says that today is the second half of the meeting that started in yesterday’s SFC weekly meeting
18:09:42 <edwarnicke> #link https://docs.google.com/drawings/d/1NOMUB0pcL5Ordlulb85B5krKa8w_Ce5rGYi2jywd-WQ/edit
18:10:08 <tbachman> #info paulq says the core thing is the question as to what granularity you ask for (i.e. by chain name? type?)
18:10:19 <tbachman> #info paulq says the classifier is pretty straightforward
18:10:40 <tbachman> #info edwarnicke says he thinks of it as to who’s responsible for what, and how do we prevent conflicts
18:10:53 <tbachman> #info paulq says if the classifier and SFF are separate, then the classifier rules are GBP rules
18:11:06 <tbachman> #info paulq says in the chain, flow rules are looked up by NSH
18:11:39 <tbachman> #info mickey_spiegel asks what happens at the end of the chain, and GBP is putting openflow rules at the end
18:12:04 <tbachman> #info paulq says we know in principle the last SFF; one thought (to GBP project) is if SFC tells GBP the last SFF, can GBP install a rule for this?
18:12:36 <tbachman> #info alagalah says more than likely this would be the reverse of the entry
18:12:37 <abhijitkumbhare> Good point mickey_spiegel
18:12:45 <tbachman> #info paulq thinks this mickey_spiegel asked a different question
18:12:59 <tbachman> #info when NSH is thrown in the garbage, how do you forward it to the ultimate destination?
18:13:26 <tbachman> #info alagalah says his thinking is that it would be the same as the ofoverlay renderer acts on the same destination today
18:13:52 <tbachman> #info edwarnicke says the end of the chain can happen for all kinds of reasons — in which case things like normal L3 routing gets the packets there
18:13:55 <abhijitkumbhare> Am I the only person who lost audio?
18:14:02 <tbachman> abhijitkumbhare: afraid so :(
18:14:07 <abhijitkumbhare> ok
18:14:13 <tbachman> #info alagalah says this could be problematic
18:14:59 <tbachman> #info paulq says that you don’t know which SFF the packet pops out on, should SFC tell GBP which SFF it is?
18:15:06 <tbachman> #info alagalah says yes, GBP will need that inforamtion
18:15:19 <tbachman> #info alagalah asks if the reverse path would also be the egress
18:15:27 <tbachman> #info paulq says that’s not guaranteed
18:16:45 <tbachman> #info paulq says there’s been a back and forth on what this integration looks like in the mailing lists
18:17:09 <tbachman> #info paulq says the use case for the POC is two EPGs and a contract; the contract expreses a chain, and the GBP will ask for that chain from SFC
18:17:42 <tbachman> #info SFC provides a set of IDs for the chain; as part of the EPG flow programming, GBP places the packet in a tunnel, tagged with appropriate identifiers and artifacts
18:17:52 <tbachman> #undo
18:17:52 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1939e10>
18:17:59 <tbachman> #info SFC provides a set of IDs for the chain; as part of the EPG flow programming, GBP places the packet in a tunnel, tagged with appropriate identifiers and encap
18:18:08 <tbachman> #info alagalah asks if this will be a flow header rewrite?
18:18:26 <tbachman> #info paulq says the way this works is you attach it to a tunnel; the output would be a vxlan with NSH header
18:19:01 <tbachman> #info paulq says ideally the tunnel CRUD would come from OVSDB; in short term, we can stand it up other ways
18:19:22 <tbachman> #info edwarnicke says we have an overlay API coming into the MD-SAL, so you can ask for a tunnel between two places
18:19:37 <tbachman> #info edwarnicke says the overlay API is constructed using the per-side issue
18:20:32 <tbachman> #info edwarnicke says that the classification would be handled by GBP; GBP requests the tunnel to the first SFF; GBP adds classifier to direct traffic onto this tunnel
18:20:58 <tbachman> #info edwarnicke says that SFC knows where SFFs are doesn’t have to understand GBP knowledge of where EPs live
18:21:32 <tbachman> #info Uri asks if the policy that establishes the contract between two EPGs enforces policy on the chain
18:23:30 <tbachman> #info alagalah says we’re just discussing the POC, not to cover the end-all use cases
18:24:00 <tbachman> #info Uri asks if the scope is just connecting GBP and SFC
18:24:02 <tbachman> #info alagalah says yes
18:25:20 <tbachman> #info There is a question as to whether GBP and SFC would both be attempting to write the flow tables
18:25:35 <tbachman> #info alagalah says that SFC matches on an NSH header, so they’d be completely separate flows
18:26:13 <tbachman> #info abhijitkumbhare asks for clarification on this; the classifier is likely to be the first switch at the edge, and adds the vxlan and NSH headers
18:26:21 <tbachman> #info abhijitkumbhare asks if that will be programmed by GBP
18:26:48 <tbachman> #info paulq says the openflow rules instantiated by GBP will direct the appropriate EPG members to the tunnel that does this encap
18:27:08 <tbachman> #info paulq says this means that GBP uses the existing rules to direct it to the tunnel
18:28:06 <tbachman> #info paulq says SFC will provide the dataplane locator for the SFF (first hop in the chain)
18:28:20 <tbachman> #info sanjay asks if you’re using LISP in this example
18:28:27 <abhijitkumbhare> paulq - so the tunnel will be responsible for adding both the VXLAN & NSH header
18:28:31 <tbachman> #info paulq says there’s nothing that precludes this
18:28:42 <tbachman> abhijitkumbhare: that’s my understanding
18:28:50 <abhijitkumbhare> thx tbachman
18:28:57 <tbachman> abhijitkumbhare: np!
18:29:22 <tbachman> #info paulq says this fits a model that makes sense — GBP asks essentially for a service chain, which is a form of graph; separates concerns
18:29:36 <tbachman> #info This allows SFC flexibility of the complexity of its graphs
18:30:16 <tbachman> #info Sanjay asks in the last SFF, all the SFC headers, etc. will be terminated. Will the last SFF forward the traffic back to the original switch that started the chain, or will the traffic be forwarded from the last SFF to go to the destination
18:31:37 <tbachman> #info alagalah says there is a contract that matches for traffic from A-B, we request stuff from SFC: head of the chain (node locator, encap, etc.); GBP adds flow to direct it there, and also gives us the last SFF; the return path may be a separte SFC, which gets handled the same way
18:32:09 <tbachman> #info Sanjay asks if the end of the chain returns the packet back to the switch that started the chain
18:32:22 <tbachman> #info paulq says he considers that a special case, so not necesarrily
18:33:09 <tbachman> #info mickey_spiegel points out that at the termination side of the chain, within the datapath, you have to get it from some lookups that SFC is handling to some lookup that GBP is handling, within that switch
18:33:59 <tbachman> #info mickey_spiegel is noting that the forwarding pieces need to be put together at the termination, so some coordination is needed there
18:34:11 <tbachman> #info alagalah says we’ll need a list of topologies we’ve tested
18:34:27 <tbachman> #info abhijitkumbhare asks if GBP is responsible for flow programming while tunnel programming is handled by SFC
18:34:33 <tbachman> #info alagalah says we’re treating this like a black box
18:35:25 <tbachman> #info paulq says that this conversation is the way we work through the issues in this POC
18:35:38 <abhijitkumbhare> alagalah - I also think this is doable
18:36:01 <abhijitkumbhare> and good enough design alagalah
18:36:03 <tbachman> #info alagalah says we still need to keep in mind the goal of providing a POC in Lithium
18:36:26 <tbachman> #info alagalah asks if this POC is goood enough for Uri’s needs
18:38:37 <tbachman> #info paulq says we can show a demo with the OVS switch provisioned with the SFC script/demo
18:38:57 <tbachman> #info Sanjay asks if the new tunnel provisioning service is used to create the tunnels between the SFFs
18:39:08 <tbachman> #info alagalah says we’re not using ODL yet; would have to be done manually
18:39:22 <tbachman> #info alagalah says there are plans to make the OVSDB CRUD for creating tunnels available
18:39:53 <tbachman> #info Sanjay asks if that means we’re using tunnels between SFFs
18:40:11 <tbachman> #info alagalah says they key is being used to target the tunnels in GBP
18:40:22 <tbachman> #info paulq says they use wildcard tunnels and key into them
18:40:34 <tbachman> #info paulq says they use REST to provision tunnels until the OVSDB mechanism is available
18:40:47 <tbachman> #info rpenno says the service function agent is used to create these tunnels
18:41:05 <tbachman> #info edwarnicke asks if Sanjay has been following the tunnel API discussion
18:41:13 <tbachman> #info Sanjay he has, but needs to read up on it a bit more
18:41:51 <tbachman> #info paulq says the real key here is for everyone to look at the wiki, get agreement, and start development
18:42:18 <tbachman> #info alagalah says he’s got a card for SFC integration — should we use that to manage this task?
18:42:52 <tbachman> #info rpenno says they just use a list of action items
18:42:59 <tbachman> #info alagalah recomends a gdoc checklist
18:43:13 <tbachman> #action alagalah to create a google doc to track this; link to wiki pages in both projects
18:43:45 <tbachman> #info alagalah asks who he should work with on this effort
18:43:50 <tbachman> #info rpenno says it will be him
18:44:20 <tbachman> #info mickey_spiegel says we’ve talked about fitting the pieces together; we haven’t talked about the model itself
18:44:35 <tbachman> #info mickey_spiegel asks if the proposal is to direct to a service function name, or something else?
18:44:53 <tbachman> #info alagalah says the idea is to put service function names into a list, which GBP will ask for
18:45:06 <tbachman> #info The list will be referenced by name
18:45:21 <tbachman> #info mickey_spiegel says he doesn’t understand the notion of a path and the granularity of the path
18:46:04 <tbachman> #info alagalah says that’s a good question, which needs to be resolved
18:46:13 <tbachman> #info alagalah we could have an ID for each instance of EPG
18:46:37 <tbachman> #info paulq says that for the POC, he would tend to think that SFC handles the graph abstraction and returns a path per request
18:48:35 <tbachman> #info LouisF asks for symmetric chains, do you need 2 paths for that; and how would your organize the classifiers for the forward and reverse directions
18:48:44 <tbachman> #info rpenno sasy you need 2 paths
18:48:53 <yapeng> my audio does not work. i have a question, the current GBP policy model support SFC contract?
18:49:19 <tbachman> yapeng: I don’t think there’s an SFC contract per se, but an action to direct it to the SFC chain
18:49:30 <tbachman> that’s contained in the contract
18:49:34 <tbachman> (i.e. it’s still just a contract)
18:50:16 <yapeng> tbachman, i see. so how is SFC chain described in the contract?
18:50:32 <tbachman> yapeng: I believe it’s by name
18:50:48 <tbachman> SFC owns the information about the chain
18:51:25 <s3wong> yapeng, tbachman: 'redirect' action has been in the GBP model very early on; that said, as many mentioned above, the intent can be represented, but the data path plumbing is the question
18:51:34 <yapeng> tbachman: i see. thanks.
18:51:56 <tbachman> #info mickey_spiegel asks if you want chain ABC, and in reverse CBA, are there 2 chains or 1?
18:52:10 <tbachman> #info Sanjay sasy these are different chains
18:52:17 <tbachman> #info rpenno sasy these are two different paths
18:52:26 <tbachman> #info forward direction and reverse direction#
18:53:10 <tbachman> #info mickey_spiegel asks if GBP is referencing two different chains
18:54:22 <tbachman> #info mickey_spiegel says that from a model perspective, GBP allows you to set a direction or say that it’s bidirectional
18:54:41 <tbachman> #info alagalah says the notion of the contract will still be applied in the direction
18:54:56 <tbachman> #info mickey_spiegel asks if the contract says bidirectional, and SFC supports this mapping, then we could use that
18:55:38 <tbachman> #info alagalah  says GBP would look at this as two unidirectional things
18:56:53 <tbachman> #info Sanjay asks what’s implemented today in SFC? Unidirectional chains?
18:57:00 <s3wong> in fact, how can bidirectional work here? the reverse flow would hit a different classifier
18:57:07 <tbachman> #info rpenno says today the API supports both: symmetric (bidirectional) paths
18:57:13 <tbachman> #info at the time of creation, they create two paths
18:57:34 <tbachman> #info they create the two paths in one shot, b/c if you want symmetry, you want the same SFFs to be traversed, just in reverse order
18:57:44 <tbachman> #info rpenno says you can also ask for two separate paths
18:57:48 <s3wong> the same policy-rule, even with BIDIRECTIONAL, would not get the reverse traffic to match the classifier
18:57:55 <tbachman> #info rpenno says it’s up to the caller to decide what they want
18:58:34 <tbachman> #info Sanjay says with chain SFF1-SFF2-SFF3, in the in direction (A-B), you’ll go SFF1-SFF2-SFF3; in reverse, do you go SFF1-SFF2-SFF3, of SFF3-SFF2-SFF1?
18:58:41 <tbachman> #info rpenno says it’s SFF3-SFF2-SFF1
18:58:54 <tbachman> #info paulq points out that the word symmetric is best here
19:00:40 <LouisF> how can bidirectional work here? the reverse flow would hit a different classifier?
19:00:55 <tbachman> LouisF: good question
19:00:58 <tbachman> #endmeeting