#opendaylight-group-policy: gbp_requirements

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

Meeting summary

    1. Sanjay brings up other possible use cases (iWAN) (tbachman, 20:04:56)

  2. Strawman of intent elements for UCI use case (tbachman, 20:08:54)
    1. uchau has put together JSON that can be used for this. (tbachman, 20:09:26)
    2. uchau goes over use case with older version of the model (tbachman, 20:10:32)
    3. In this scenario, there is a single EPG for Users (tbachman, 20:10:46)
    4. With a single contract with subjects for each media (voice, video, app sharing) (tbachman, 20:11:21)
    5. And a single class, with Subject of ALL (tbachman, 20:11:37)
    6. s/class/clause/ (tbachman, 20:12:05)
    7. All flows go into classififier of 5-tuple for each user (tbachman, 20:12:28)
    8. the EPG is both the provider and consumer of the contract (tbachman, 20:12:40)
    9. Using named selectors (tbachman, 20:12:49)
    10. The default clause allows all subjects to be active (tbachman, 20:13:03)
    11. note that the new model would allow the 3rd type of selector, so that the EPG can use that selector to both provide and consume the contract (tbachman, 20:14:09)
    12. uchau describes the json (tbachman, 20:14:46)
    13. lenrow says that the keyword “voice” would allow the renderer to derive some meaning (e.g. latency) so that the backend can do something with it (tbachman, 20:18:16)
    14. uchau says that the action hjas a value, which provides a mapping, such as “Interacive Voice”, which can be further mapped to things like DSCP markings (tbachman, 20:19:02)
    15. mickey_spiegel says that in previous discussions that we had an additional level of indirection (tbachman, 20:20:19)
    16. lenrow says that if we call out things that are specific, then we can have duplication of functionality in renderers — is seeking sufficient abstractions (tbachman, 20:20:50)
    17. uchau feels that there are series of renderers, which can leverage these actions. (tbachman, 20:21:20)
    18. uchau and that we should at least have a base renderer that meets these needs. (tbachman, 20:21:38)
    19. mickey_spiegel says we need to distinguish between a couple of things (tbachman, 20:21:50)
    20. mickey_spiegel asks if we need well-known class names so that it can be supported across different providers (tbachman, 20:22:24)
    21. uchau asks what providers is here (tbachman, 20:22:31)
    22. mickey_spiegel meant service providers (tbachman, 20:22:38)
    23. mickey_spiegel adds that these APIs should be able to be used in multiple environments. (tbachman, 20:22:56)
    24. the question is whether these keywords have to be remapped in different provider environments (tbachman, 20:23:13)
    25. uchau says that their goal is to provide something more commonly used (e.g. Interactive Voice), but what it gets mapped to (e.g. DSCP markings) depends on the provider environment. (tbachman, 20:24:02)
    26. mickey_spiegel is worried whether we can satisfy everyone with a single definition (tbachman, 20:24:57)
    27. mickey_spiegel notes that QoS discussions get ugly pretty fast, with strong opinions (tbachman, 20:25:11)
    28. lenrow notes that ACL policies might be easier, but QoS is indeed harder (tbachman, 20:25:25)
    29. uchau says we can start with this as a goal to make it as reusable as possible (tbachman, 20:25:42)
    30. uchau finishes but doesn’t preclude configurability (tbachman, 20:25:58)
    31. ucha finishes “doesn't preclude others from building what they need" (tbachman, 20:26:39)
    32. Sanjay asks where the actions are represented (tbachman, 20:27:18)
    33. as an example, policing (tbachman, 20:27:25)
    34. uchau says that actions are specified as parameters (tbachman, 20:27:38)
    35. mickey_spiegel says that dvorkinista wanted a layer of indirection, to avoid hard-coding things to an environment (tbachman, 20:28:09)
    36. mickey_spiegel adds that the value can be treated as a class name and the definition of the class gets defined somewhere else (tbachman, 20:28:31)
    37. lenrow says that a possible place for this is in operational state (tbachman, 20:28:52)
    38. mickey_spiegel says that this indirection allows the provider to specify it, not the user (tbachman, 20:29:07)
    39. mickey_spiegel asks whether we should have default class names so that they can be portable across providers (tbachman, 20:29:53)
    40. lenrow says that this is what we need to take back to the UCIF folks as a proposal (tbachman, 20:30:53)
    41. uchau notes that this model is very similar to how the UCIF folks are laying out their requirements (tbachman, 20:31:34)
    42. uchau says that they do want feedback as part of the request, to understand what was actually assigned (tbachman, 20:31:52)
    43. lenrow asks what happens if the promise cant’ be met (tbachman, 20:32:59)
    44. dconde says that this can result in an exception notification (tbachman, 20:33:12)
    45. uchau asks whether some of the things in the model are optional (e.g. some of the things in the action-ref) (tbachman, 20:34:43)
    46. Sanjay asks whether this is translatable from yang/ (tbachman, 20:35:13)
    47. uchau says this is translated from the yang model (tbachman, 20:35:25)

  3. Sanjay presents dynamic use cases (tbachman, 20:36:30)
    1. firs tuse case is “Demand Usecase 2.1: IWAN Routing” (tbachman, 20:37:37)
    2. useful for multiple large enterprises with many branch offices (10-15k) (tbachman, 20:37:53)
    3. The use case has multiple ISPs, and want to monitor the WAN connection, based on a quality matrix (tbachman, 20:38:31)
    4. They also may want service chaining, WAN optimization (tbachman, 20:39:13)
    5. This effectively a netflow-based threshold crossing measurement between branch routers and border routers (tbachman, 20:40:06)
    6. https://wiki.opendaylight.org/view/File:Policy_Usecases.pptx <= slides for presentation (tbachman, 20:41:08)
    7. lenrow asks whether the assumption is whether the SDN controller spreads across all of this, and the infrastructure is under the control of the SDN controller (tbachman, 20:42:46)
    8. the pieces are measurement (border-router to border-router), testing measurements against policy (i.e. intent) (tbachman, 20:44:55)
    9. and if rules are satisfied, then no action (tbachman, 20:45:05)
    10. and if rules aren’t satisfied, new policies need to be deployed (tbachman, 20:45:16)
    11. This is dynamically changing the membership of the flow from one EPG to another EPG, resulting in traffic taking a different path (tbachman, 20:45:56)
    12. lenrow asks whether monitoring of border routers as a renderer thing, or an application thing (tbachman, 20:46:16)
    13. Sanjay says it could be either, but would prefer business logic to handle this (tbachman, 20:47:05)
    14. So, the application becomes aware that a promise isn’t kept, and asks for a new promise (tbachman, 20:47:55)
    15. lenrow asks from a requirements perspective, whether Sanjay feels this can be supported with current constructs (tbachman, 20:48:56)
    16. Sanjay believes it can be supported, and the only thing is that we haven’t gone through the forwarding use cases as we have the policy use cases (tbachman, 20:49:15)
    17. Sanjay also isn’t sure whether he can do the forwarding modeling himself (may need help here) (tbachman, 20:49:39)
    18. mickey_spiegel says he isn’t sure how this relates to GBP (tbachman, 20:50:10)
    19. mickey_spiegel says that policy is all about intent and abstraction, not deep into the data plane (tbachman, 20:51:58)
    20. dconde adds that this is crossing different domains, of intent and implementation (tbachman, 20:52:19)
    21. Sanjay says that he believes there’s an intent and rendering dimension here (tbachman, 20:52:32)
    22. The policy is the business routing is the intent, and the rendering handles the forwarding for certain traffic classes (how traffic classes get mapped) (tbachman, 20:53:26)
    23. mickey_spiegel says that the traffic forwarding is owned by the network admin, not by the application (tbachman, 20:54:38)
    24. lenrow thinks the intent is clear — but maybe what’s lacking is a clearer picture of what the details of efficiently using resources in the renderer look like (tbachman, 20:55:49)
    25. mickey_spiegel says that operational policies and renderer aren’t the same thing (tbachman, 20:56:34)
    26. lenrow says that a lot of this is details that can be (and should be) managed by the renderer (tbachman, 20:59:29)
    27. lenrow says that POCs for comparing/contrasting can help make clearer distinctions on this concepts (tbachman, 21:00:08)
    28. Sanjay introduces a second use case of security across the WAN (tbachman, 21:00:28)
    29. where measurements are made (tbachman, 21:00:48)
    30. and threshold crossings are rerported to an operational application, which can implement things like threat-detection logic (tbachman, 21:01:15)
    31. lenrow says that this is identical to the Defense4All use case (tbachman, 21:02:08)
    32. the renderer in Defense4All might look different in WAN vs. LAN, but use case is similar (tbachman, 21:02:35)
    33. A third use case is a threat-detection use case in the datacenter (tbachman, 21:02:53)
    34. lenrow thinks that the event rates for DDoS detection are probably less than the UCI use case (tbachman, 21:03:25)
    35. Sanjay says that he hears that for IWAN routing and perhaps security use cases, intent is expressed at a higher level, rather than an operational level, and operational intent should be expressed/handled in the renderer logic (tbachman, 21:04:58)
    36. alagalah asks whether we can post these to the email list (tbachman, 21:08:28)
    37. Sanjay says he will send the link again (tbachman, 21:08:34)
    38. alagalah suggests that we can give reviews of Sanjay’s (and others’) work in the status meeting. (tbachman, 21:10:05)

  4. Enterprise Hierarchical Resource Accessuse case (tbachman, 21:11:13)
    1. Sanjay believes the policy model covers this well (tbachman, 21:11:34)
    2. There is an EPG called Users, with an India-Empl Users and US-Empl Users as children EPGs (tbachman, 21:14:26)
    3. HR and Wiki are EPGs within a Web EPG (tbachman, 21:14:45)
    4. there is a single Contract A (tbachman, 21:14:57)
    5. the Web EPG provides the contract, and the Users EPG consumes the contract (tbachman, 21:15:54)
    6. the Contract has two subjects, HTTP_low and HTTP_Hi, for low and high security, respectively (tbachman, 21:16:18)
    7. There are several rules, mapping thes to HTTP_low or HTTP_hi (tbachman, 21:17:35)
    8. lenrow asks if there are other agenda items (tbachman, 21:18:30)


Meeting ended at 21:18:41 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. tbachman (107)
  2. odl_meetbot (4)
  3. uchau (2)
  4. lenrow (0)


Generated by MeetBot 0.1.4.