#opendaylight-group-policy: GBP Requirements Meeting 6-19-2014

Meeting started by tbachman at 20:08:20 UTC (full logs).

Meeting summary

  1. UCI Use Case (tbachman, 20:09:33)
    1. https://wiki.opendaylight.org/view/File:Extending_SDN_WP.docx (lenrow, 20:13:30)
    2. http://www.ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf (lenrow, 20:16:15)
    3. : http://www.ucif.org/Portals/0/documents/2014_02_27_Use_Case.pdf Link for UCIF document (tbachman, 20:16:38)
    4. 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)
    5. 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)
    6. readams notes that the biggest challenge is that you need a SB renderer that can support a campus LAN environment (tbachman, 20:21:13)
    7. lenrow notes that the folks interested in this might be willing to dedicate resources for that renderer development (tbachman, 20:21:38)
    8. lenrow says that they are essentially mapping this onto diffserve and interserve infra (tbachman, 20:25:27)
    9. dvorkin believes this can be translated to intent pretty easily (tbachman, 20:26:18)
    10. with telephones as endpoints (tbachman, 20:26:25)
    11. have a group that contains end callers (tbachman, 20:26:48)
    12. a session corresponds to a group (tbachman, 20:27:21)
    13. where a caller and callee are in the same group (tbachman, 20:27:30)
    14. lenrow says that uchau has slides showing proposed mappings (tbachman, 20:27:44)
    15. lenrow sees the different services are different groups (tbachman, 20:28:36)
    16. For example, high quality video, voice, whiteboard, etc. (tbachman, 20:28:53)
    17. each in its own group (tbachman, 20:28:59)
    18. lenrow sees this as a diffserve intent architecture, with DSCP markings on the backend (tbachman, 20:29:31)
    19. dvorkinista says that thinking of each group as a session has advantages (tbachman, 20:30:19)
    20. where you don’t have a zillion different groups based on qualities (tbachman, 20:30:35)
    21. if you have a group per session, there are platform scalability questions (tbachman, 20:30:46)
    22. group becomes a template-like thing, with a couple of parameters. (tbachman, 20:32:03)
    23. uchau is concerned about building another operational store for a specific use case (tbachman, 20:33:42)
    24. dvorkinista says that the endpoint registry could be used for these things — putting session-like constructs in there (tbachman, 20:34:09)
    25. readams notes that many architectures will need the concept of session (tbachman, 20:34:24)
    26. uchau shares her model (tbachman, 20:37:14)
    27. in this model, Lync users are in one EPG (tbachman, 20:37:35)
    28. with a Lync QoS contract (tbachman, 20:37:49)
    29. with different EPGs within the Lync Users EPG for Voice, Video, white board, etc. (tbachman, 20:38:15)
    30. uchau’s concern is that for each endpoint, the paired connection is not visible (tbachman, 20:39:25)
    31. readams says that connection pair visibility can be supported even with a single EPG (tbachman, 20:39:45)
    32. EPs can only be in a single EPG, but EPG inheritance can make EPs be scoped by multiple EPGs (tbachman, 20:40:34)
    33. readams notes that conditions can help here (tbachman, 20:40:48)
    34. For example, a Video condition (tbachman, 20:40:59)
    35. uchau shows another model with users in different, dedicated EPGs (tbachman, 20:44:20)
    36. but this model still doesn’t have pairwise association (tbachman, 20:44:37)
    37. In this model, the source and dest EPs are in the same EPG (tbachman, 20:46:27)
    38. Another model has all users in an EPG (tbachman, 20:46:49)
    39. The contract does an all-to-all clause, with different subjects (tbachman, 20:47:02)
    40. voice, video, etc. (tbachman, 20:47:09)
    41. The classifier would be modified in the subject to create the pairwise association (tbachman, 20:47:48)
    42. 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)
    43. 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)
    44. this has a huge number of EPGs (tbachman, 20:50:23)
    45. uchau has concerns about the complexity with the amount of indirection when representing in JSON (tbachman, 20:51:59)
    46. going back to model with EPG with all the Lync Users (tbachman, 20:53:14)
    47. The classifiers would point to some kind of a grouping of sessions (tbachman, 20:53:43)
    48. All of those sessions are incorporated by reference (tbachman, 20:53:53)
    49. That way you don’t have to change the sessions, you change the operational state (tbachman, 20:54:05)
    50. readams notes that you need a way to refer to groups of sessions (tbachman, 20:54:58)
    51. Some sort of tag (tbachman, 20:55:06)
    52. dvorkinista thinks this should be added to the Endpoint Registry (tbachman, 20:56:03)
    53. because the concept of session is very common (tbachman, 20:56:10)
    54. The session reference would point to existing endpoints, or it could contain the endpoint itself. (tbachman, 20:56:34)
    55. 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)
    56. With the goal being to try to minimize the number of lookups (tbachman, 20:57:42)
    57. The Lync server will add a session to the session store (possibly EP registry) (tbachman, 20:58:58)
    58. then the pair of EPs can be looked up to get the relevant session info (tbachman, 20:59:16)
    59. lenrow says that a session for them is a 5-tuple micro-flow (tbachman, 21:00:33)
    60. dvorkinista says that a session is a collection of endpoints engaged in communication that is mutually consistent with each other (tbachman, 21:00:50)
    61. uchau has to leave, so recommending we reconvene in tomorrow’s model meeting (tbachman, 21:12:21)
    62. AGREED: (tbachman, 21:12:24)


Meeting ended at 21:12:27 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (74)
  2. odl_meetbot (6)
  3. lenrow (2)
  4. regXboi (2)
  5. s3wong (1)
  6. alagalah (0)


Generated by MeetBot 0.1.4.