============================= #opendaylight-sfc: sfc_weekly ============================= Meeting started by tbachman at 17:00:00 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-sfc/2015/sfc_weekly/opendaylight-sfc-sfc_weekly.2015-02-12-17.00.log.html . Meeting summary --------------- * agenda (tbachman, 17:00:13) * 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 (tbachman, 17:00:23) * LINK: https://lists.opendaylight.org/pipermail/sfc-dev/2015-February/000907.html Agenda for today’s meeting (tbachman, 17:01:20) * SFC/GBP integration (tbachman, 17:06:09) * LINK: https://wiki.opendaylight.org/view/Service_Function_Chaining:Group_Based_Policy_Integration wiki page describing the integration (tbachman, 17:08:48) * ebrjohn says the EPGs determine which traffic gets sent into the chain (tbachman, 17:09:07) * SFC is responsible for getting the packets through the chain and to the termination point (tbachman, 17:09:27) * alagalah says it would help to frame the conversation around scope (tbachman, 17:10:43) * alagalah asks ebrjohn if it’s okay to delineate scope (tbachman, 17:11:14) * ebrjohn says its good to make clear that it’s a POC (tbachman, 17:11:31) * paulq agrees with addressing scope (tbachman, 17:12:01) * alagalah says someone else provisions the service chain (tbachman, 17:12:37) * alagalah says there are two EPGs, with instances on two different servers, can talk over VxLAN tunnel (tbachman, 17:12:59) * alagalah says one of the things between the two EPGs is the contract with an action called CHAIN, with an action referenced by name (tbachman, 17:13:19) * alagalah says there’s an outer list and an inner list — the inner list says how to get in and how to come out (tbachman, 17:13:40) * in the reverse direction is also needed — the entry and exit point (tbachman, 17:13:55) * GBP has to then encap in NSH and get it there — black boxing SFC (tbachman, 17:14:10) * paulq says that sounds fine (tbachman, 17:14:23) * abhijitkumbhare asks for the prototype — will it be possible to extend it to other transport types such as MPLS (tbachman, 17:14:59) * 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 (tbachman, 17:16:18) * ebrjohn says the communication between GBP and SFC is NSH — does it always have to be NSH (tbachman, 17:16:44) * 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 (tbachman, 17:17:43) * paulq says we’re assuming that GBP is receiving the requisite information to start the chain — be it NSH, et. al. (tbachman, 17:18:12) * ebrjohn says it needs to be flexible enough to use SFC with other technologies than NSH (tbachman, 17:19:06) * paulq emphasizes that SFC will return the requisite information for the appropriate encap (tbachman, 17:19:32) * 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 (tbachman, 17:20:07) * paulq doesn’t agreee with that statement (tbachman, 17:20:14) * alagalah says he kind of agrees with it, but has a question on that (tbachman, 17:20:26) * alagalah says with NSH there’s no chance of openflow “glare” with GBP (tbachman, 17:20:50) * paulq says he may have misunderstood mickey_spiegel’s comment (tbachman, 17:21:17) * mickey_spiegel says it’s only the multiple writers that he’s addressing (tbachman, 17:22:17) * paulq agrees (tbachman, 17:22:21) * alagalah recommends a phased approach for long term (tbachman, 17:23:31) * ebrjohn agrees — what would be the next step (tbachman, 17:24:20) * LINK: https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium Group Based Policy Trello board with cards for SFC (tbachman, 17:25:12) * vina_ermagan asks when you say terminating EPG, is that the final SFF, or the where the final endpoint is located (tbachman, 17:26:06) * ebrjohn says it’s after the SFF (tbachman, 17:26:13) * vina_ermagan says that information has to be conveyed to SFC so that it knows where to send it (tbachman, 17:26:24) * GBP would ask for the chain and at the last hop, send it to this location (tbachman, 17:26:37) * ebrjohn says the difference between SFC as it is now vs. sending it to the terminating EPG — is there any difference for SFC? (tbachman, 17:27:38) * paulq says there shouldn’t be — as long as we can impose the classification (tbachman, 17:27:48) * LINK: https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit (alagalah, 17:27:59) * mickey_spiegel says there’s the issue of creating the tunnel from the SFF (tbachman, 17:28:02) * LINK: https://docs.google.com/document/d/1ZnLHuSiyOmVFR0pW65K4enB7QcYbLL18yzxYgmK_iDo/edit SFC+GBP phased design brainstorming (alagalah, 17:28:13) * mickey_spiegel says there’s an action at the end of the chain that’s GBP-ish for the tunnel (tbachman, 17:28:41) * 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 (tbachman, 17:29:22) * 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 (tbachman, 17:29:55) * vina_ermagan says both SFC and GBP both have the ability to do the encap (tbachman, 17:30:35) * paulq says post service chain — the packet comes out w/o NSH (tbachman, 17:30:36) * normal routing/forwarding has to handle that (tbachman, 17:30:43) * in the case of GBP, the overlay has to handle that (tbachman, 17:30:52) * in the case of non-GBP, it would just be handled by normal routing (tbachman, 17:31:01) * mickey_spiegel asks who puts the overlay there at the last SFF — GBP or SFC (tbachman, 17:31:16) * paulq says that after the service chain, SFC is done (tbachman, 17:31:23) * alagalah says that’s his understanding as well - and vice versa — inside the service chain GBP doesn’t care (tbachman, 17:31:39) * vina_ermagan says that there’s an overlap there tho (tbachman, 17:31:47) * paulq says not really — the SFC rules are written on NSH; post-decap, it’s just an IP packet (tbachman, 17:32:12) * alagalah would request SFC #1, gets back ‘you will send packets to start chain on OVS-1, port 1, NSH header A’ (tbachman, 17:34:11) * alagalah says at the end, coming out of the tunnel openflow switch 2 port 2 — also getting this from SFC (tbachman, 17:34:31) * alagalah says we also get the reverse path (tbachman, 17:34:40) * 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 (tbachman, 17:35:29) * alagalah says coming out, we just have to take the packets from the tunnel and strip the headers (tbachman, 17:36:07) * alagalah says SFC has now knowledge that GBP is using a VxLAN overlay (tbachman, 17:36:27) * vina_ermagan says then GBP must have control over wherever the last SFF is to be able to get back the packet (tbachman, 17:37:17) * alagalah says yes, the OVS would be shared (tbachman, 17:37:51) * alagalah says that’s everything that’s SFC is matching on an NSH field (tbachman, 17:38:40) * paulq says for the POC, let’s assume it’s NSH end to end, which allows us to avoid the multiple writers issue (tbachman, 17:40:03) * vina_ermagan says that sounds good — the handoff is local from SFC to GBP on the vSwitch (tbachman, 17:40:22) * mickey_spiegel says if we’re doing the local handoff on the vSwitch, then some details need to be worked out (tbachman, 17:40:43) * alagalah agrees (tbachman, 17:40:46) * 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 (tbachman, 17:41:05) * ebrjohn asks what the difference between alagalah’s google doc and the wiki page that repenno started (tbachman, 17:41:36) * alagalah says this is just a brainstorming document — prefers gdoc with history, etc. (tbachman, 17:41:52) * alagalah says the gdoc is also meant to address phases/goals beyond the POC (tbachman, 17:42:19) * 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 (tbachman, 17:43:20) * paulq says yes — for POC, there’s a clear separation of who controls which switch (tbachman, 17:43:33) * paulq says the only constraint is that the last SFF has to deliver an IP packet to GBP (tbachman, 17:43:49) * ebrjohn asks if we should consider a “no encap” option (tbachman, 17:44:08) * paulq says it does mean that the forwarding is “clean” on the intermediate switches (tbachman, 17:44:29) * paulq says when you have a clear identifier in the packet then it’s easy to avoid any conflicts in the middle (tbachman, 17:44:55) * ebrjohn asks if we want to address the different phases in alagalah’s document (tbachman, 17:45:22) * alagalah says we should push the transparent case to a later phase (tbachman, 17:47:33) * ebrjohn asks if there’s anything else we should mention for phase 0 (tbachman, 17:48:19) * ebrjohn asks folks to review repenno’s document (tbachman, 17:49:18) * tbachman is looking into providing an example patch on how SFC and GBP might integrate for the POC (tbachman, 17:52:13) * ebrjohn asks if we should continue this in the GBP meeting (tbachman, 17:52:31) * folks agree to continue in GBP (tbachman, 17:52:38) Meeting ended at 17:54:37 UTC. People present (lines said) --------------------------- * tbachman (97) * odl_meetbot (5) * alagalah (2) * abhijitkumbhare (2) * ebrjohn (1) Generated by `MeetBot`_ 0.1.4