#opendaylight-group-policy: MODEL

Meeting started by dconde at 17:05:16 UTC (full logs).

Meeting summary

    1. jmedved was to convert model to YANG (dconde, 17:05:42)
    2. and workarounds and changes to model (dconde, 17:05:50)
    3. recap coming w/ requirements of model (dconde, 17:06:11)
    4. YANG cannot expressed self contained constructs (dconde, 17:06:23)

  2. Discussion of YANG and UML capabailities (alagalah, 17:06:33)
    1. linear chains are preferred to mimic containment (dconde, 17:06:36)
    2. jmedved was to convert model to YANG (alagalah, 17:06:42)
    3. recap coming w/ requirements of model (alagalah, 17:06:51)
    4. YANG cannot expressed self contained constructs (alagalah, 17:06:55)
    5. how to implement nested logical stmts (dconde, 17:07:04)
    6. we can either keep formulas as blobs or str (dconde, 17:07:20)
    7. specifically for matchers (alagalah, 17:07:24)
    8. to simplify the matchers (dconde, 17:07:47)
    9. we will use YANG as a authoritative description of model, rather than diagram (dconde, 17:09:00)
    10. from readams (dconde, 17:09:08)
    11. ought to extend YANG? (dconde, 17:09:29)
    12. ACTION: dvorkinista (Mike D) to modify Matcher logic to be either ANDs, ORs, with Label EXCLUDE for negation. This will be a single level ie (A AND B AND C), (A OR B OR C), EXCLUDE (A AND B) (alagalah, 17:09:29)
    13. but that is second phase. (dconde, 17:09:43)
    14. dvorkinista recommends no circumstances and scoring. (dconde, 17:10:17)
    15. assume there exists a governance system to update the endpoints. (dconde, 17:10:29)
    16. as an external input (dconde, 17:10:38)
    17. here (mickey_spiegel, 17:10:48)
    18. it will not reduce the attractiveness of the model. (dconde, 17:11:14)
    19. lenrow says we don't need to do all the use-cases. (dconde, 17:11:47)
    20. no matter what we do, we have to architect for extensibility. (dconde, 17:12:27)

  3. MD-SAL / YANG requirements discussion - broader discussion (alagalah, 17:12:41)
    1. best thing for community is to look at readams's paper on how we can achieve goals for simplification. (dconde, 17:13:33)
    2. paper to be finalized and shared next week. (dconde, 17:13:46)
    3. we will assume jmedved is in agreement. since he wasn't on this moment. (dconde, 17:14:37)
    4. we can look at what readams has transcribed. (dconde, 17:15:37)

  4. review of readams's yang model for 0.97 (dconde, 17:15:59)
    1. we are reviewing the doc now on hangout screen share now. (dconde, 17:16:35)
    2. early next week (dconde, 17:17:41)
    3. trying to get inhr and obj modl to map to UML doc. (dconde, 17:18:14)
    4. challenge. model is complex (dconde, 17:18:25)
    5. starting w/ jmedved's model and adding constructs - issues are complexity and decipher the "runes" w.r.t. inconsistencies that readams will rsolve w/ dvorkinista (dconde, 17:19:29)
    6. same type @ two levels of hier. (dconde, 17:19:42)
    7. he is using grouping but still needs to be mapped to a different location. (dconde, 17:20:26)
    8. running into restrictions Java that is generated. (dconde, 17:22:35)
    9. other challenge. relator object (dconde, 17:23:15)
    10. inheritance is problematic. children override values, so what should be in base class? (dconde, 17:23:52)
    11. are you using AUGMENT? readams is using groupings. (dconde, 17:24:21)
    12. discussing whether we are overriding base types. how best to do that? (dconde, 17:25:21)
    13. if super class has restrictions, we can reason at that level? or shall we use REFINE stmt? It's all tricky. (dconde, 17:26:22)
    14. dvorkinista says we used to have match type in relator in original. so we have a vestigial item that needs to resolved. (dconde, 17:27:23)
    15. it's possible to just have a relator. use a target, selector, and that's it. can be named or not-named. (dconde, 17:28:01)
    16. dvorkinista is fine not using inheritance. (dconde, 17:29:52)
    17. relator can be a providing selector or a consumer selector. do not treat them as separate things. (dconde, 17:30:15)
    18. once we have a proper model, it will be resolved in a concrete yang model (dconde, 17:32:33)
    19. yang becomes authoritative. (dconde, 17:32:51)
    20. but let us remembe that UML is easier to read... (dconde, 17:33:36)
    21. ACTION: alagalah will write a whitepaper that describes the UML model. (dconde, 17:34:19)
    22. and text is ambiguous. so we do not want to replace UML (dconde, 17:35:01)
    23. should we annotate UML? dvorkinista prefers that. (dconde, 17:35:36)
    24. we will disucss how best to do it (dconde, 17:36:20)
    25. ACTION: we will annotate UML instead -- alagalah (dconde, 17:36:32)
    26. lenrow has a "for dummes" draft in progress. (dconde, 17:37:07)

  5. open forum. (dconde, 17:38:25)
    1. mickey_spiegel notices that many pages of model refers to same thing. dvorkinista says it is used to describe concept. (dconde, 17:39:09)
    2. alagalah says each page tries to express a concept in context. (dconde, 17:39:26)
    3. ACTION: dvorkinista to restruct model in structure, definition use (dconde, 17:40:24)
    4. lenrow questions. (dconde, 17:40:47)
    5. is traffic chaining expression difficult? (dconde, 17:41:19)
    6. we are missing some items. like sensitivities ! (dconde, 17:41:41)
    7. dvorkinista will update model according to how it was expressed in YANG. (dconde, 17:42:09)
    8. we meant to say service chaining, not traffic chaining. (dconde, 17:42:44)
    9. let us try to model this. we are trying to pull in people from L4-L7 companies for their perspective. (dconde, 17:43:29)
    10. let's have a discussion on what to include -- (dconde, 17:44:39)
    11. we are speculating what RADware wants to do, or F5. (dconde, 17:45:12)
    12. there is a project proposal for service chaining and see if it's common or not. (dconde, 17:45:23)
    13. new svc chaining encapsulation type -- being proposed. (dconde, 17:46:35)
    14. https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining (raghu67, 17:47:04)
    15. project is service function chaning that is being proposed. (dconde, 17:47:30)
    16. visions from ETSI and IETF, etc. (dconde, 17:47:38)
    17. there are lots of projects with some overlap (dconde, 17:48:43)
    18. we can render to it. (dconde, 17:48:53)
    19. mickey_spiegel says - is this a matter of rendering, or referring to their model? (dconde, 17:49:56)
    20. they are concentrating on instance. GBP can focus on policy. this is complementary. (dconde, 17:51:32)
    21. we will have a conversation. (dconde, 17:52:11)
    22. ACTION: alagalah will talk w/ ewarnicke (dconde, 17:52:35)
    23. ACTION: alagalah will talk w/ ed warnicke regarding service chaining. (dconde, 17:53:03)
    24. their diagram has more stuff than svc chaining ought to have. (dconde, 17:55:29)


Meeting ended at 17:56:19 UTC (full logs).

Action items

  1. dvorkinista (Mike D) to modify Matcher logic to be either ANDs, ORs, with Label EXCLUDE for negation. This will be a single level ie (A AND B AND C), (A OR B OR C), EXCLUDE (A AND B)
  2. alagalah will write a whitepaper that describes the UML model.
  3. we will annotate UML instead -- alagalah
  4. dvorkinista to restruct model in structure, definition use
  5. alagalah will talk w/ ewarnicke
  6. alagalah will talk w/ ed warnicke regarding service chaining.


Action items, by person

  1. alagalah
    1. alagalah will write a whitepaper that describes the UML model.
    2. we will annotate UML instead -- alagalah
    3. alagalah will talk w/ ewarnicke
    4. alagalah will talk w/ ed warnicke regarding service chaining.
  2. UNASSIGNED
    1. dvorkinista (Mike D) to modify Matcher logic to be either ANDs, ORs, with Label EXCLUDE for negation. This will be a single level ie (A AND B AND C), (A OR B OR C), EXCLUDE (A AND B)
    2. dvorkinista to restruct model in structure, definition use


People present (lines said)

  1. dconde (82)
  2. alagalah (10)
  3. odl_meetbot (5)
  4. lenrow (3)
  5. raghu67 (2)
  6. jmedved (1)
  7. mickey_spiegel (1)


Generated by MeetBot 0.1.4.