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