============================================================== #opendaylight-group-policy: GBP Requirements Meeting 6-19-2014 ============================================================== Meeting started by tbachman at 20:08:20 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-group-policy/2014/gbp_requirements_meeting_6_19_2014/opendaylight-group-policy-gbp_requirements_meeting_6_19_2014.2014-06-19-20.08.log.html . Meeting summary --------------- * UCI Use Case (tbachman, 20:09:33) * LINK: https://wiki.opendaylight.org/view/File:Extending_SDN_WP.docx (lenrow, 20:13:30) * LINK: http://www.ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf (lenrow, 20:16:15) * LINK: : http://www.ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf Link for UCIF document (tbachman, 20:16:38) * The UCI use case envisioned a service on the SDN controller and interact with flow programming, topoology, etc. in order to perform DSCP marking (tbachman, 20:20:08) * The collective opinion is that this should be replace with GBP, and to declare their intent in such a way so that renderer can translate their intent into SB rules (tbachman, 20:20:48) * readams notes that the biggest challenge is that you need a SB renderer that can support a campus LAN environment (tbachman, 20:21:13) * lenrow notes that the folks interested in this might be willing to dedicate resources for that renderer development (tbachman, 20:21:38) * lenrow says that they are essentially mapping this onto diffserve and interserve infra (tbachman, 20:25:27) * dvorkin believes this can be translated to intent pretty easily (tbachman, 20:26:18) * with telephones as endpoints (tbachman, 20:26:25) * have a group that contains end callers (tbachman, 20:26:48) * a session corresponds to a group (tbachman, 20:27:21) * where a caller and callee are in the same group (tbachman, 20:27:30) * lenrow says that uchau has slides showing proposed mappings (tbachman, 20:27:44) * lenrow sees the different services are different groups (tbachman, 20:28:36) * For example, high quality video, voice, whiteboard, etc. (tbachman, 20:28:53) * each in its own group (tbachman, 20:28:59) * lenrow sees this as a diffserve intent architecture, with DSCP markings on the backend (tbachman, 20:29:31) * dvorkinista says that thinking of each group as a session has advantages (tbachman, 20:30:19) * where you don’t have a zillion different groups based on qualities (tbachman, 20:30:35) * if you have a group per session, there are platform scalability questions (tbachman, 20:30:46) * group becomes a template-like thing, with a couple of parameters. (tbachman, 20:32:03) * uchau is concerned about building another operational store for a specific use case (tbachman, 20:33:42) * dvorkinista says that the endpoint registry could be used for these things — putting session-like constructs in there (tbachman, 20:34:09) * readams notes that many architectures will need the concept of session (tbachman, 20:34:24) * uchau shares her model (tbachman, 20:37:14) * in this model, Lync users are in one EPG (tbachman, 20:37:35) * with a Lync QoS contract (tbachman, 20:37:49) * with different EPGs within the Lync Users EPG for Voice, Video, white board, etc. (tbachman, 20:38:15) * uchau’s concern is that for each endpoint, the paired connection is not visible (tbachman, 20:39:25) * readams says that connection pair visibility can be supported even with a single EPG (tbachman, 20:39:45) * EPs can only be in a single EPG, but EPG inheritance can make EPs be scoped by multiple EPGs (tbachman, 20:40:34) * readams notes that conditions can help here (tbachman, 20:40:48) * For example, a Video condition (tbachman, 20:40:59) * uchau shows another model with users in different, dedicated EPGs (tbachman, 20:44:20) * but this model still doesn’t have pairwise association (tbachman, 20:44:37) * In this model, the source and dest EPs are in the same EPG (tbachman, 20:46:27) * Another model has all users in an EPG (tbachman, 20:46:49) * The contract does an all-to-all clause, with different subjects (tbachman, 20:47:02) * voice, video, etc. (tbachman, 20:47:09) * The classifier would be modified in the subject to create the pairwise association (tbachman, 20:47:48) * The clause for this model just says “use all these subjects”, so theoretically doesn’t need to be explicit in the policy (tbachman, 20:49:12) * Another model has each EPG is a new user, e.g. voice user 1, voice user 2, which use contracts for each QoS (tbachman, 20:50:11) * this has a huge number of EPGs (tbachman, 20:50:23) * uchau has concerns about the complexity with the amount of indirection when representing in JSON (tbachman, 20:51:59) * going back to model with EPG with all the Lync Users (tbachman, 20:53:14) * The classifiers would point to some kind of a grouping of sessions (tbachman, 20:53:43) * All of those sessions are incorporated by reference (tbachman, 20:53:53) * That way you don’t have to change the sessions, you change the operational state (tbachman, 20:54:05) * readams notes that you need a way to refer to groups of sessions (tbachman, 20:54:58) * Some sort of tag (tbachman, 20:55:06) * dvorkinista thinks this should be added to the Endpoint Registry (tbachman, 20:56:03) * because the concept of session is very common (tbachman, 20:56:10) * The session reference would point to existing endpoints, or it could contain the endpoint itself. (tbachman, 20:56:34) * readams says the key that given two endpoints, he needs to be able to look something up for those two endpoints quickly (tbachman, 20:57:26) * With the goal being to try to minimize the number of lookups (tbachman, 20:57:42) * The Lync server will add a session to the session store (possibly EP registry) (tbachman, 20:58:58) * then the pair of EPs can be looked up to get the relevant session info (tbachman, 20:59:16) * lenrow says that a session for them is a 5-tuple micro-flow (tbachman, 21:00:33) * dvorkinista says that a session is a collection of endpoints engaged in communication that is mutually consistent with each other (tbachman, 21:00:50) * uchau has to leave, so recommending we reconvene in tomorrow’s model meeting (tbachman, 21:12:21) * AGREED: (tbachman, 21:12:24) Meeting ended at 21:12:27 UTC. People present (lines said) --------------------------- * tbachman (74) * odl_meetbot (6) * lenrow (2) * regXboi (2) * s3wong (1) * alagalah (0) Generated by `MeetBot`_ 0.1.4