18:00:11 <tbachman> #startmeeting gbp_status_arch
18:00:11 <odl_meetbot> Meeting started Fri Feb 13 18:00:11 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:00:11 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:11 <odl_meetbot> The meeting name has been set to 'gbp_status_arch'
18:00:14 <tbachman> #chair alagalah
18:00:14 <odl_meetbot> Current chairs: alagalah tbachman
18:00:18 <tbachman> #topic agenda
18:00:31 <tbachman> #link https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting Agenda for today’s meeting
18:00:42 <tbachman> #link https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_150206/opendaylight-group-policy-gbp_150206.2015-02-06-17.58.html Minutes from last week’s meeting
18:01:33 <tbachman> #link https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit Google document that alagalah created, as an action from last week’s meeting on SFC/GBP integration
18:02:06 <tbachman> #topic SFC/GBP Integration
18:02:48 <tbachman> #undo
18:02:48 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1a27a90>
18:02:55 <alagalah> #topic Code merges
18:05:17 <ebrjohn> Hey guys, can you put the callin info, I still cant connect to Webex
18:05:42 <tbachman> ebrjohn: +1-866-432-9903 Call-in toll-free number (US/Canada)
18:05:43 <tbachman> +1-408-525-6800 Call-in toll number (US/Canada)
18:05:44 <tbachman> Access code: 200 742 501
18:05:53 <gzhao> Friday, the 13th
18:05:54 <ebrjohn> tbachman thanks
18:05:59 <tbachman> ebrjohn: np!
18:06:12 <tbachman> #info alagalah says there was a bug fix merged by Intel
18:06:42 <tbachman> #info alagalah says we’re hoping to merge the opencontrail renderer patch — just need to run the POC to make sure there’s no change functionally
18:07:37 <alagalah> #topic Neutron impl update
18:07:40 <tbachman> alagalah: thx!
18:08:17 <tbachman> ebrjohn:  https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit Google document that alagalah created, as an action from last week’s meeting on SFC/GBP integration
18:09:02 <tbachman> #info alagalah met with martin_sunal, who will be helping with the neutron work
18:09:03 <abhijitkumbhare> Who is in slovakia?
18:09:12 <abhijitkumbhare> OK - martin
18:09:13 <tbachman> abhijitkumbhare: martin_sunal
18:09:35 <tbachman> #info alagalah says he’s kitted up a bulk of the work for multiple EPGs per EP, and intra-group policy, and tested it
18:09:42 <tbachman> #info alagalah says from a control plane, it works great
18:10:07 <tbachman> #info alagalah says the data plane — specifically the flow pipeline — may need to be worked out a bit, with multiple EPGs
18:10:21 <tbachman> #info alagalah is looking at the issues with multi-EPGs
18:10:48 <tbachman> #info alagalah is going to compare doing this vs. trying to do this using condition groups — provide a comparison between the two
18:11:45 <tbachman> #info alagalah says that martin_sunal brought up the idea of an ANY EPG
18:11:58 <tbachman> #undo
18:11:58 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x189f390>
18:12:35 <tbachman> #info alagalah says martin_sunal had the idea of an “ANY” EP — to make a bit of a “grey list” model (instead of white list)
18:12:54 <tbachman> #info alagalah says he’s looking at the merits of all of these changes
18:13:01 <alagalah> #topic SFC and GBP Integration (continued)
18:13:16 <tbachman> #link  https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit Google document that alagalah created, as an action from last week’s meeting on SFC/GBP integration
18:13:54 <tbachman> #info alagalah says GBP and SFC are working to integrate for an external application — working on a POC for Lithium
18:14:21 <tbachman> #link https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration Wiki page that repenno created for this integration
18:15:51 <tbachman> #info mickey_spiegel asks if we’re relying on separation of topology, encaps or both for conflict avoidance
18:16:06 <tbachman> #info alagalah says we may require a constrainted topology, and will require NSH
18:17:01 <tbachman> #info ebrjohn says he’d like to see at a minimum that the first solution be flexible enough to support different encaps — specifically MPLS
18:17:36 <tbachman> #info alagalah asks where that would sit in the arch
18:17:51 <tbachman> #info ebrjohn says to use MPLS instead of NSH
18:18:04 <tbachman> #info ebrjohn says NSH doesn’t have many switches supporting it
18:18:25 <tbachman> #info ebrjohn says there’s an NSH proxy, which sits between the switch and the service function
18:18:38 <tbachman> #info ebrjohn is looking to support MPLS since it’s more common
18:19:06 <tbachman> #info alagalah says he thinks it’s achievable, but is still interested in NSH
18:19:35 <tbachman> #info ebrjohn says he isn’t advocating excluding NSH, but rather to do both — matter of resources and time
18:19:41 <tbachman> #info ebrjohn says he can do it in SFC
18:19:57 <tbachman> #info ebrjohn asks if GBP supports MPLS
18:20:09 <tbachman> #info alagalah says no, but there’s also currently no NSH encap either yet
18:20:30 <tbachman> #info alagalah says if we can get an MPLS encap from SFC, then we should be able to make something work
18:20:41 <tbachman> #info ebrjohn says he’s willing to help contribute that code in the GBP project
18:21:14 <tbachman> #info Prem says that for MPLS, the label would be used to create a similar path as NSH; asks what the benefit is of both NSH and MPLS
18:21:29 <tbachman> #info ebrjohn says he wasn’t thinking both at the same time — just one or the other
18:22:59 * tbachman blushes
18:24:15 <tbachman> #info paulq says there’s a case that might bear mentioning, where MPLS and NSH are used; allows extending policy to the services, but use MPLS for the transport
18:24:48 <tbachman> #info ebrjohn says that in the case where there are networks that don’t support NSH, the MPLS use case is helpful
18:25:51 <tbachman> #info ebrjohn says you can also do MPLS over GRE
18:26:49 <tbachman> #info paulq says it’s important to consider one goal of service chaining is the service, and extending policy to the service can be good
18:27:17 <tbachman> #info rukhsana asks about the acceptance of the NSH patches in OVS
18:27:36 <tbachman> #info paulq says the patches are in, work, and work is in place to get them upstreamed
18:29:39 <tbachman> #info abhijitkumbhare asks what the timeline is for phase 0
18:31:07 <tbachman> #info alagalah says Lithium
18:31:19 * tbachman wakes up from narcoloptic bit
18:31:38 <tbachman> #info abhijitkumbhare asks mickey_spiegel  what no encap means — no NSH?
18:32:00 <tbachman> #info mickey_spiegel asks if VxLAN stitching falls under no-encap
18:32:07 * ebrjohn Am I the only one that sees like 10 "andy"s connected in the webex?
18:32:16 <tbachman> ebrjohn: I see him (them?) too :)
18:32:29 <tbachman> #info abhijitkumbhare says no encap is reclassification at every hop
18:32:59 <tbachman> #info paulq says VxLAN is encap
18:35:17 <tbachman> #info paulq says SFC needs to hand back what can be used in the chain
18:35:42 <tbachman> #info paulq says that’s the only way to make this generalized
18:35:47 <tbachman> #info mickey_spiegel asks about the stuff that readams was bringing up on the mailing list
18:35:56 * tbachman goes to get email link
18:36:36 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000903.html email from Rob Adams, talking about mulitiple renderer issue
18:38:02 <tbachman> #info alagalah recommends addressing conflict detection/resolution in phase 1
18:39:21 <tbachman> #info ebrjohn says we may want to consider the overlay API as a longer-term goal
18:41:48 <tbachman> #info mickey_spiegel asks when SFC says Rendered Service Path, does that mean selecting what the SFFs are, or creating the data path things as well
18:42:09 <tbachman> #info paulq says it’s the actual toplogy created for hte service path — SFF1, switch62, FW3, etc.
18:44:37 <tbachman> #info repenno says a service function path is a collection of service hops that a user can input as a constraint for constructing a rendered service path
18:45:47 <tbachman> #info mickey_spiegel asks if it includes the encap details between them
18:46:42 <tbachman> #info repenno says it includes everything if the data plane locators and encaps were provided; RSP provides an ordererd list of SFFs and SFs; the data plane locators are sent through another interface/API
18:47:04 <tbachman> #info repenno then looks up the data plane locators and encaps when constructing the RSP
18:48:54 <tbachman> #info repenno says if folks want to understand SFC, he gave a demo at the SFC meeting which should help
18:49:18 <dbainbri1> link to webex?
18:49:34 <tbachman> #link https://meetings.webex.com/collabs/url/8Rbm2LrCyU5pzLsmhOoDj0yJZPpI0jb53VzcEpoFeVG00000 Webex for SFC presentation
18:49:46 <tbachman> ah
18:49:48 <tbachman> wrong one
18:49:50 <tbachman> #undo
18:49:50 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x1ab06d0>
18:49:59 <tbachman> #link https://meetings.webex.com/collabs/meetings/playRecording?recordID=14433636&meetingInstanceID=I3RF8SUSATNXF89CT7CW0PWB30-9VIB Link to SFC presentation from repenno on SFC
18:50:00 <ebrjohn> You can find more info about Reinaldo's demo here:
18:50:05 <ebrjohn> #link https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#Meetings
18:50:22 <tbachman> #link https://meetings.webex.com/collabs/url/VvVrUGAbeDLYPAxlPgmw5TlduQHGLb1gjk5_E1rxDum00000 Alternate link to webex for non-US accounts
18:50:36 <tbachman> #info alagalah says openstack GBP already integrates with ODL GBP today
18:51:09 <tbachman> #info alagalah says openstack SFC, to his knowledge, has a FW and LB encapsulated in it — when they ask for an SFC, they’re just leveraging the router’s capabilities, and is relatively static
18:51:44 <tbachman> #info alagalah asks if the SFC folks are looking to create a neutron API implementation, or is that out of scope
18:52:02 <tbachman> #info repenno says he looked into that, and is on his todo list
18:52:31 <tbachman> #info alagalah says the GBP neutron provider would also look to support SFC from openstack
18:52:53 <tbachman> #info repenno asks if GBP is doing the neutron stuff — is it possible to put this stuff outside GBP or put it in GBP
18:53:24 <s3wong> the current Service Chaining implementation is part of the GBP repo
18:53:26 <tbachman> #info alagalah says GBP will create a provider for neutron, so it can integrate with existing neutron
18:53:38 <tbachman> #info s3wong says the current Service Chaining implementation is part of the GBP repo
18:53:40 <tbachman> s3wong: thx ;)
18:53:50 <tbachman> I guess I should clarify that
18:53:53 <tbachman> #undo
18:53:53 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x19b3d10>
18:54:03 <tbachman> #info s3wong says the current Service Chaining implementation is part of the openstack GBP repo
18:54:10 <tbachman> s3wong: correct? ^^^
18:54:14 <s3wong> tbachman: yes, the OpenStack implementation
18:54:24 <s3wong> i.e., it isn't part of Neutron repo
18:54:37 <tbachman> #info ebrjohn asks if we can get GBP and SFC integrated and it works well, do we need to do this in ODL?
18:55:00 <tbachman> #info alagalah says he doesn’t want to preclude SFC from doing any integration that their project is interested in doing
18:55:09 <tbachman> #info repenno says we need to wait and see what that looks like
18:55:29 <s3wong> ebrjohn: think of OpenStack as an orchestration layer
18:55:45 <tbachman> s3wong: ah — but it uses the GBP implementation to do SFC then, right?
18:55:50 <s3wong> ebrjohn: and ODL would be the "driver" --- the layer that would realize that config/intent
18:55:51 <tbachman> s3wong: is there SFC outside of GBP?
18:56:12 <s3wong> tbachman: we have a service chain API/plugin infra on GBP repo
18:56:32 <tbachman> s3wong: got it; but is there something in neutron as well?
18:56:39 <tbachman> or is it only supported in GBP openstack?
18:56:43 <s3wong> tbachman: we have a reference implementation mapping to Neutron
18:56:46 <tbachman> ah
18:56:49 <tbachman> right
18:56:50 <tbachman> I see
18:57:08 <s3wong> tbachman: but since Neutron has no "service insertion" framework, the reference doesn't really have a good data path plumbing
18:57:17 <tbachman> #info songole says openstack has a firewalll and load balancer today;
18:57:34 <s3wong> tbachman, ebrjohn: in fact, if ODL can do the plumbing, it would be immensely useful
18:57:59 <tbachman> s3wong: that may be the key point there
18:58:24 <tbachman> #info s3wong says Neutron has no "service insertion" framework, the reference doesn't really have a good data path plumbing
18:58:51 <tbachman> #info s3wong says there is a service chain API/plugin infra on the OpenStack GBP repo
18:58:53 <tbachman> alagalah: ^^^
18:59:05 <s3wong> tbachman: the point is, since we can translate: map a flow match a classifier to direct that traffic flow to a service, the data path part would be great to have an Open-source reference that truly works
18:59:12 <s3wong> s/can/can't
18:59:45 <s3wong> sorry, guys, I am in a meeting, so not able to join webex
18:59:46 <tbachman> #info s3wong says the point is, since we can’t translate: map a flow match a classifier to direct that traffic flow to a service, the data path part would be great to have an Open-source reference that truly works
18:59:50 <tbachman> s3wong: got it
19:00:37 <tbachman> #link https://docs.google.com/presentation/d/1AO47EYrDMuTAypcpYbL3XOKFggZXu9x00XpGVwJLr9o/edit#slide=id.g612a6349b_0205 slides for neutron integration
19:03:01 <tbachman> #info alagalah asks what the best way is to track inter-project work?  Trello?
19:03:14 <tbachman> #info ebrjohn says he’s fine (as SFC PTL) for hosting this on the GBP Trello
19:03:32 <tbachman> #link https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium GBP Trello Board, with GBP/SFC integration cards
19:04:09 <tbachman> ebrjohn: ^^
19:07:17 <tbachman> #link https://git.opendaylight.org/gerrit/#/c/15255/ initial patch to start SFC/GBP conversation
19:08:41 <tbachman> #endmeeting