#opendaylight-group-policy: group-policy-requirements

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

Meeting summary

  1. model presentation by Dvorkin (tbachman, 20:10:03)
    1. model is presented as a CLI-like concept (tbachman, 20:10:23)
    2. model is less verbose, and aims for improved clarity from yang model (tbachman, 20:10:45)
    3. contracts can be provided or consumed by name (tbachman, 20:13:44)
    4. Additional “mutual” concept is for intra-EPG contracts (tbachman, 20:14:30)
    5. groups can have requirements (optional), capabilities (optional), and conditions (optional) (tbachman, 20:15:28)
    6. “mutual” is what we had previously called “peer” contracts (tbachman, 20:15:59)
    7. contracts can also be provided/consumed using expressions (tbachman, 20:16:20)
    8. expressions can use AND/OR/XOR/NOT-like expressions (tbachman, 20:16:35)
    9. need to specify how the group relates to a network domain. Can be subnet-domain, flood-domain, bridge-domain (tbachman, 20:17:51)
    10. l3-subnet-domain has an address-range (e.g. IPv4/v6 ranges), and can be part of a network domain or default L3 domain (tbachman, 20:19:10)
    11. contracts can be selected by one of two means: by name, or by identifier (tbachman, 20:20:13)
    12. Walking through example (tbachman, 20:22:54)
    13. using tenant dave, with EPG deveness (tbachman, 20:23:13)
    14. The default behavior is that two endpoints within the same EPG can communicate w/o a contract (tbachman, 20:24:26)
    15. tenant dave also has another EPG awesomeness (tbachman, 20:24:40)
    16. tenant dave also has a contract pingability (tbachman, 20:25:02)
    17. The pingability contract has a subject, with a classifier called reflexive icmp (tbachman, 20:25:27)
    18. clauses are implied in this case (tbachman, 20:26:05)
    19. mickey_spiegel says that you don’t have to provide and consume to make it bi-directional (tbachman, 20:26:56)
    20. dvorkinista says that we can add a “peer” contract to both provide and consume (tbachman, 20:28:51)
    21. mickey_spiegel says that classifier and action have in/out/bi- in the UML model (tbachman, 20:29:16)
    22. to continue this example, something needs to assign and endpoint to group daveness, and a second endpoint to group awesomeness, and then the two endpoints can communicate with the pingability (tbachman, 20:30:45)
    23. contract (tbachman, 20:30:51)
    24. lenrow asks what we mean by tenant (tbachman, 20:32:02)
    25. dvorkinista says that it can be thought of as just a container (tbachman, 20:32:13)
    26. lenrow asks if it can have more than one L2 context (tbachman, 20:32:23)
    27. dvorkinista says yes (tbachman, 20:32:34)
    28. to extend the model, an l2-bridge-domain named foo is added, which has part-of-domain mystuff (tbachman, 20:32:55)
    29. and an l3-domain mystuff is definied (tbachman, 20:33:05)
    30. and the part-of-domain foo is added to the daveness and awesomeness groups (tbachman, 20:33:48)
    31. The model is extended further by adding another tenant (tbachman, 20:34:19)
    32. Another tenant called common is created (tbachman, 20:34:41)
    33. The pingability contract is moved to the common tenant (i.e. instead of being part of the dave tenant) (tbachman, 20:35:08)
    34. where the “common” tenant name is a special name (tbachman, 20:35:20)
    35. This allows multiple tenants to share the tenant common items (tbachman, 20:35:53)
    36. extending further, a new tenant named keith is added (tbachman, 20:36:08)
    37. keith also has a group that references the pingability contract defined in teh common tenant (tbachman, 20:36:35)
    38. question about AAA was raised (tbachman, 20:37:50)
    39. that needs to be defined in ODL first (tbachman, 20:38:01)
    40. And then it can be used for GBP (tbachman, 20:38:18)
    41. mickey_spiegel asks if there are multiple groups in scope, are we using longest-match prefix? (tbachman, 20:48:11)
    42. dvorkinista that can be one way (tbachman, 20:48:19)
    43. longest-prefix match (tbachman, 20:49:09)
    44. question asked for when policy is definied, is that applicable to a specific topology that’s been reported? (tbachman, 20:50:19)
    45. this is high-level intent — a policy model (tbachman, 20:50:43)
    46. as an example, a high-level intent for network virtualization (tbachman, 20:50:58)
    47. provides a mean of specifiying things like access-control, without having to worry about what’s underneath, which makes it more portable (tbachman, 20:51:59)
    48. The point is that the southbounds have high-variability, so portability is important (tbachman, 20:52:25)
    49. question is asked what marries this policy to low level things (tbachman, 20:53:23)
    50. the renderers provide this mapping (tbachman, 20:53:34)
    51. Question was asked if the peer contract pingability was needed in teh amazingness and awesomeness groups, given that both groups had part-of-domain greatstuff (tbachman, 20:58:43)
    52. the answer is that the l3-domain greatstuff is addressability, but not reachability (tbachman, 20:59:02)
    53. so, the contract is needed for reachability (tbachman, 20:59:09)

  2. what to do with the model presented by Dvorkin (tbachman, 21:03:23)
    1. Dvorkin just saw this as an instrument to better explain how this works (tbachman, 21:03:39)
    2. mickey_spiegel notes that we can do the same thing in yang that was done with this CLI-type model (tbachman, 21:05:35)
    3. readams notes that things like provide/consume type relationships in yang is a bit tricky, as extraneous information isn’t magically filtered out (tbachman, 21:08:43)
    4. mickey_spiegel asks if it makes sense to demonstrate this with restconf (tbachman, 21:10:16)
    5. readams notes that you can do the same in JSON (tbachman, 21:10:32)
    6. lenrow would like to see a user interface that is easier to pick up and understand that what’s done in JSON (tbachman, 21:22:55)
    7. readams notes that there would be some binding on top of this to make it easier to use (e.g. python bindings) (tbachman, 21:23:39)
    8. lenrow says that people care about the APIs, not the bindings (tbachman, 21:23:54)
    9. readams notes that a new encoding could be added to the northbound, if that’s found to be easier. (tbachman, 21:24:38)
    10. yang does have some constructs it can’t support, which causes some of the constructs seen in the yang model (tbachman, 21:34:24)
    11. ACTION: lenrow to provide a link for a document of the UC&C use case (tbachman, 21:38:01)
    12. propose using Thurday status meeting for continuation (tbachman, 21:39:45)

  3. update on steering/redirection (tbachman, 21:39:57)
    1. seeking more input from IETF SFC team (tbachman, 21:40:15)
    2. need to propose way to integrate the rendering needs of SFC into the GBP project (tbachman, 21:40:32)
    3. developing intro presentation for conversation with IETF SF (tbachman, 21:40:55)
    4. SFC (tbachman, 21:40:59)
    5. UCIF requirements (tbachman, 21:43:45)

  4. UCIF requirements (tbachman, 21:43:47)
    1. UCIF QoS: A proposal for marking flows (tbachman, 21:44:01)
    2. described in terms fo DSCP markings (tbachman, 21:44:09)
    3. Need to propose intent expressions instead (tbachman, 21:44:19)
    4. DSCP marking would be a rendering technique for particular SB (tbachman, 21:44:35)
    5. http://www.ucif.org/Portals/0/documents/2014_02_27_Use_case.pdf (tbachman, 21:45:06)
    6. UCIF Automated TE (tbachman, 21:45:13)
    7. Allows asynch updates to change marking for specific flows (tbachman, 21:45:25)
    8. Allow explicit reallocation of bandwidth pool between classes of service (tbachman, 21:45:42)
    9. Working on permission required to share in ODL (tbachman, 21:45:48)
    10. discussion on need for realizing more use cases (tbachman, 21:56:51)
    11. in order to uncover any possible corner cases or issues (tbachman, 21:57:06)
    12. ACTION: lenrow to propose continuing this discussion on Thursday’s status meeting (tbachman, 22:00:24)


Meeting ended at 22:00:31 UTC (full logs).

Action items

  1. lenrow to provide a link for a document of the UC&C use case
  2. lenrow to propose continuing this discussion on Thursday’s status meeting


People present (lines said)

  1. tbachman (93)
  2. odl_meetbot (4)
  3. alagalah (0)


Generated by MeetBot 0.1.4.