17:00:00 <tbachman> #startmeeting sfc_weekly
17:00:00 <odl_meetbot> Meeting started Thu Feb 12 17:00:00 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:00:00 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:00 <odl_meetbot> The meeting name has been set to 'sfc_weekly'
17:00:04 <tbachman> #chair ebrjohn
17:00:04 <odl_meetbot> Current chairs: ebrjohn tbachman
17:00:13 <tbachman> #topic agenda
17:00:23 <tbachman> #link https://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-02-05-17.00.html Last week’s meeting minutes
17:01:20 <tbachman> #link https://lists.opendaylight.org/pipermail/sfc-dev/2015-February/000907.html Agenda for today’s meeting
17:06:02 <tbachman> #toipc SFC/GBP integration
17:06:09 <tbachman> #topic SFC/GBP integration
17:08:48 <tbachman> #link https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration wiki page describing the integration
17:09:07 <tbachman> #info ebrjohn says the EPGs determine which traffic gets sent into the chain
17:09:27 <tbachman> #info SFC is responsible for getting the packets through the chain and to the termination point
17:10:43 <tbachman> #info alagalah says it would help to frame the conversation around scope
17:11:14 <tbachman> #info alagalah asks ebrjohn if it’s okay to delineate scope
17:11:31 <tbachman> #info ebrjohn says its good to make clear that it’s a POC
17:12:01 <tbachman> #info paulq agrees with addressing scope
17:12:37 <tbachman> #info alagalah says someone else provisions the service chain
17:12:59 <tbachman> #info alagalah says there are two EPGs, with instances on two different servers, can talk over VxLAN tunnel
17:13:19 <tbachman> #info alagalah says one of the things between the two EPGs is the contract with an action called CHAIN, with an action referenced by name
17:13:40 <tbachman> #info alagalah says there’s an outer list and an inner list — the inner list says how to get in and how to come out
17:13:55 <tbachman> #info in the reverse direction is also needed — the entry and exit point
17:14:10 <tbachman> #info GBP has to then encap in NSH and get it there — black boxing SFC
17:14:23 <tbachman> #info paulq says that sounds fine
17:14:59 <tbachman> #info abhijitkumbhare asks for the prototype — will it be possible to extend it to other transport types such as MPLS
17:16:18 <tbachman> #info alagalah says it’s a bit out of scope of a POC goal, as it’s specific on GBP — maybe address this in the GBP meeting
17:16:44 <tbachman> #info ebrjohn says the communication between GBP and SFC is NSH — does it always have to be NSH
17:17:43 <tbachman> #info alagalah says this is just to get this to the head of the SFC chain — how we get it from the beginning or end of the service chain to the beginning or ending endpoint is a GBP specific thing, and maybe best to address it in that team meeting
17:18:12 <tbachman> #info paulq says we’re assuming that GBP is receiving the requisite information to start the chain — be it NSH, et. al.
17:19:06 <tbachman> #info ebrjohn says it needs to be flexible enough to use SFC with other technologies than NSH
17:19:32 <tbachman> #info paulq emphasizes that SFC will return the requisite information for the appropriate encap
17:20:07 <tbachman> #info mikey_spiegel says that the requirement of transport of SFC vs. transport of what GBP normally does, and as long as they’re different, it’s okay
17:20:14 <tbachman> #info paulq doesn’t agreee with that statement
17:20:26 <tbachman> #info alagalah says he kind of agrees with it, but has a question on that
17:20:50 <tbachman> #info alagalah says with NSH there’s no chance of openflow “glare” with GBP
17:21:17 <tbachman> #info paulq says he may have misunderstood mickey_spiegel’s comment
17:21:20 <ebrjohn> what is 'openflow "glare"' ?
17:21:34 <tbachman> ebrjohn: multiple writers in the flow table
17:22:17 <tbachman> #info mickey_spiegel says it’s only the multiple writers that he’s addressing
17:22:21 <tbachman> #info paulq agrees
17:23:31 <tbachman> #info alagalah recommends a phased approach for long term
17:24:20 <tbachman> #info ebrjohn agrees — what would be the next step
17:25:12 <tbachman> #link https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium Group Based Policy Trello board with cards for SFC
17:26:06 <tbachman> #info vina_ermagan asks when you say terminating EPG, is that the final SFF, or the where the final endpoint is located
17:26:13 <tbachman> #info ebrjohn says it’s after the SFF
17:26:24 <tbachman> #info vina_ermagan says that information has to be conveyed to SFC so that it knows where to send it
17:26:37 <tbachman> #info GBP would ask for the chain and at the last hop, send it to this location
17:27:38 <tbachman> #info ebrjohn says the difference between SFC as it is now vs. sending it to the terminating EPG — is there any difference for SFC?
17:27:48 <tbachman> #info paulq says there shouldn’t be — as long as we can impose the classification
17:27:59 <alagalah> https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit
17:28:02 <tbachman> #info mickey_spiegel says there’s the issue of creating the tunnel from the SFF
17:28:13 <alagalah> #link https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit SFC+GBP phased design brainstorming
17:28:19 <tbachman> alagalah: thx!
17:28:41 <tbachman> #info mickey_spiegel says there’s an action at the end of the chain that’s GBP-ish for the tunnel
17:29:22 <tbachman> #info vina_ermagan says that the way the POC is being designed, it’s kind of boxing out SFC — control of everything, including the last SFF
17:29:55 <tbachman> #info vina_ermagan says if we assume that they don’t have control over the SFFs, then the last SFF has to do the encap — maybe without NSH header — to the final EPG
17:30:35 <tbachman> #info vina_ermagan says both SFC and GBP both have the ability to do the encap
17:30:36 <tbachman> #info paulq says post service chain — the packet comes out w/o NSH
17:30:43 <tbachman> #info normal routing/forwarding has to handle that
17:30:52 <tbachman> #info in the case of GBP, the overlay has to handle that
17:31:01 <tbachman> #info in the case of non-GBP, it would just be handled by normal routing
17:31:16 <tbachman> #info mickey_spiegel asks who puts the overlay there at the last SFF — GBP or SFC
17:31:23 <tbachman> #info paulq says that after the service chain, SFC is done
17:31:39 <tbachman> #info alagalah says that’s his understanding as well - and vice versa — inside the service chain GBP doesn’t care
17:31:47 <tbachman> #info vina_ermagan says that there’s an overlap there tho
17:32:12 <tbachman> #info paulq says not really — the SFC rules are written on NSH; post-decap, it’s just an IP packet
17:34:11 <tbachman> #info alagalah would request SFC #1, gets back ‘you will send packets to start chain on OVS-1, port 1, NSH header A’
17:34:31 <tbachman> #info alagalah says at the end, coming out of the tunnel openflow switch 2 port 2 — also getting this from SFC
17:34:40 <tbachman> #info alagalah says we also get the reverse path
17:35:29 <tbachman> #info alagalah says we’d then need to key our flow, setting up the tunnel such that a packet is going to SFC#1, we need to get a VxLAN encaped packet with an NSH header
17:36:07 <tbachman> #info alagalah says coming out, we just have to take the packets from the tunnel and strip the headers
17:36:27 <tbachman> #info alagalah says SFC has now knowledge that GBP is using a VxLAN overlay
17:37:17 <tbachman> #info vina_ermagan says then GBP must have control over wherever the last SFF is to be able to get back the packet
17:37:51 <tbachman> #info alagalah says yes, the OVS would be shared
17:38:40 <tbachman> #info alagalah says that’s everything that’s SFC is matching on an NSH field
17:40:03 <tbachman> #info paulq says for the POC, let’s assume it’s NSH end to end, which allows us to avoid the multiple writers issue
17:40:22 <tbachman> #info vina_ermagan says that sounds good — the handoff is local from SFC to GBP on the vSwitch
17:40:43 <tbachman> #info mickey_spiegel says if we’re doing the local handoff on the vSwitch, then some details need to be worked out
17:40:46 <tbachman> #info alagalah agrees
17:41:05 <tbachman> #info alagalah says we’d have to address conflict resolution in order to do this, which would be tough to do in the given time frame
17:41:36 <tbachman> #info ebrjohn asks what the difference between alagalah’s google doc and the wiki page that repenno started
17:41:52 <tbachman> #info alagalah says this is just a brainstorming document — prefers gdoc with history, etc.
17:42:19 <tbachman> #info alagalah says the gdoc is also meant to address phases/goals beyond the POC
17:43:20 <tbachman> #info ebrjohn says he’d like to clarify a point in the email on the conflict resolution — we do need to make sure that GBP and SFC are each dealing with their parts of the network
17:43:33 <tbachman> #info paulq says yes — for POC, there’s a clear separation of who controls which switch
17:43:49 <tbachman> #info paulq says the only constraint is that the last SFF has to deliver an IP packet to GBP
17:44:08 <tbachman> #info ebrjohn asks if we should consider a “no encap” option
17:44:29 <tbachman> #info paulq says it does mean that the forwarding is “clean” on the intermediate switches
17:44:55 <tbachman> #info paulq says when you have a clear identifier in the packet then it’s easy to avoid any conflicts in the middle
17:45:22 <tbachman> #info ebrjohn asks if we want to address the different phases in alagalah’s document
17:47:17 <tbachman> #info alagalah says we should push the transparent case to a later date
17:47:24 <tbachman> #undo
17:47:24 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1942750>
17:47:33 <tbachman> #info alagalah says we should push the transparent case to a later phase
17:47:38 <tbachman> lol
17:47:55 * tbachman is really not a person — just a bunch of monkeys locked in a room on MBPs
17:48:19 <tbachman> #info ebrjohn asks if there’s anything else we should mention for phase 0
17:49:18 <tbachman> #info ebrjohn asks folks to review repenno’s document
17:52:13 <tbachman> #info tbachman is looking into providing an example patch on how SFC and GBP might integrate for the POC
17:52:21 <abhijitkumbhare> alagalah - is the google doc your scratch pad - or can you link it here?
17:52:31 <tbachman> #info ebrjohn asks if we should continue this in the GBP meeting
17:52:38 <tbachman> #info folks agree to continue in GBP
17:53:03 <tbachman> abhijitkumbhare http://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit
17:53:16 <abhijitkumbhare> Thx tbachman
17:53:22 <tbachman> abhijitkumbhare: np!
17:54:37 <tbachman> #endmeeting