#opendaylight-group-policy: model/arch redux

Meeting started by regXboi at 18:16:36 UTC (full logs).

Meeting summary

    1. Is creating a tenant in response to a new flow a good idea? answer: no (tbachman, 18:17:18)
    2. however, we still need a bulk operation to create tenants (tbachman, 18:17:33)
    3. orchestration systems (openstack) allows for the bulk creation of networks (tbachman, 18:18:23)
    4. readams asserts that's fine (tbachman, 18:18:28)
    5. tenant/EPG changes shouldn't be continuous operations (tbachman, 18:19:20)
    6. regXboi notes the M&A use case, which implies a running system, and a new bulk has been dumped on it (tbachman, 18:20:06)
    7. time constant for convergence should be relatively short (tbachman, 18:22:29)
    8. regXboi would like to see the time constant for convergence on the order of seconds (tbachman, 18:24:37)
    9. and by time constant, that's the "1/e time" (tbachman, 18:24:56)
    10. There are situations where a renderer running on physical switches running OF and creating L2 flows of 10k/second, and 50 switches, it's possible that there could be changes in policy that could change flows everywhere, making for a convergence time on the order of minutes (tbachman, 18:26:24)
    11. but those are seen as "rare" occurrences (tbachman, 18:26:38)
    12. It would be good if we could make some statement on the convrgence time of some cases. (tbachman, 18:27:21)
    13. regXboi asks what call rate they're looking at for UC&C use case (tbachman, 18:31:42)
    14. uchau says about 200 flows/second, 10-100k sessions active at any one time (tbachman, 18:31:59)
    15. correction 200 sessions/second (tbachman, 18:32:17)
    16. alagalah asks for clarification of 10-100k number -- active, or total possible number (tbachman, 18:33:51)
    17. Actually what I said was clarify 10k-100k concurrent sessions or that number of endpoints (alagalah, 18:35:03)
    18. lost audio (tbachman, 18:35:05)
    19. clarification on what a dynamic classifier is (tbachman, 18:36:04)
    20. The config says this is the description of how these endpoints in different EPGs are allowed to communicate (tbachman, 18:39:02)
    21. It's not a rate of change number that separates operational vs. config changes. (tbachman, 18:42:52)
    22. subject feature definition is a global configuration item (tbachman, 18:43:37)
    23. A rule is defined that consists of a classifier that's associated with the flow (tbachman, 18:44:29)
    24. the action would be "allow", "apply QoS" (tbachman, 18:44:40)
    25. The renderer gets a packet_in, it goes through policy resolution, discovers that it needs to classify with the lync flow classifier (tbachman, 18:46:12)
    26. readams recommends reading the policy resolution spec on the wiki (tbachman, 18:46:28)
    27. resolve the EPG of the EP, using the EPG repo (tbachman, 18:46:36)
    28. https://wiki.opendaylight.org/view/Group_Policy:Architecture/Policy_Model (tbachman, 18:47:21)
    29. https://wiki.opendaylight.org/view/Group_Policy:Architecture (tbachman, 18:47:33)
    30. there is something like an orchestration system that assigns EPs to EPGs (tbachman, 18:48:34)
    31. regXboi makes Lync call to self (tbachman, 18:50:02)
    32. policy was improperly specified (tbachman, 18:50:14)
    33. renderer gets information, ensures that EP gets assigned to proper EPG (tbachman, 18:50:41)
    34. There's some mechanism for assigning/mapping an EP to it's EPG (tbachman, 18:51:50)
    35. regXboi has 10 more minutes before his next meeting (regXboi, 18:51:51)
    36. Lync flow classifier has something backing it -- the Lync session info (tbachman, 18:52:47)
    37. The point is that the operational data can be treated differently than the configuraiton data. (tbachman, 18:54:25)
    38. there's going to be auditing, AAA, logging, etc. (tbachman, 18:55:15)
    39. Still a question of how an EP is mapped to an EPG -- readams says this is a longer conversation, but there's got to be some configuration of your network that does that (tbachman, 19:01:00)
    40. For example, in UC&C case, the devices making the calls can be the EPs (tbachman, 19:03:59)
    41. Lync session server pushes information about lync session into some storage, which triggers an event to the renderer (tbachman, 19:05:39)
    42. what's in the policy is how does the application want to treat these flows (tbachman, 19:06:02)
    43. FOr example, only allow calls to other parties in a specific region (tbachman, 19:06:25)
    44. the renderer listens to the policy repository and to the store that keeps the sessions (tbachman, 19:06:46)
    45. uchau expresses concern about having a per-application renderers (tbachman, 19:08:35)
    46. readams notes that the renderers could be generalized -- e.g. campus LAN renderer (tbachman, 19:08:49)
    47. the goal for UC&C is to support campus, enterprise, and datacenter (tbachman, 19:16:15)
    48. the ONF is wondering if GBP can support the use cases they're looking at (tbachman, 19:17:03)
    49. ACTION: alagalah to send a diagram of what this may look like (tbachman, 19:20:35)
    50. ACTION: uchau to provide link for UC&C (tbachman, 19:20:42)
    51. the policy model is extremely general, but the first implementation is OpenStack focused (tbachman, 19:21:36)


Meeting ended at 19:25:41 UTC (full logs).

Action items

  1. alagalah to send a diagram of what this may look like
  2. uchau to provide link for UC&C


Action items, by person

  1. alagalah
    1. alagalah to send a diagram of what this may look like
  2. uchau
    1. uchau to provide link for UC&C


People present (lines said)

  1. tbachman (57)
  2. regXboi (13)
  3. odl_meetbot (4)
  4. alagalah (3)
  5. uchau (3)


Generated by MeetBot 0.1.4.