#opendaylight-group-policy: GBP Requirements Meeting 6-19-2014
Meeting started by tbachman at 20:08:20 UTC
(full logs).
Meeting summary
- UCI Use Case (tbachman, 20:09:33)
- https://wiki.opendaylight.org/view/File:Extending_SDN_WP.docx
(lenrow,
20:13:30)
- http://www.ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf
(lenrow,
20:16:15)
- : 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
(full logs).
Action items
- (none)
People present (lines said)
- tbachman (74)
- odl_meetbot (6)
- lenrow (2)
- regXboi (2)
- s3wong (1)
- alagalah (0)
Generated by MeetBot 0.1.4.