#opendaylight-group-policy: Requirements and Arch carry over

Meeting started by alagalah at 19:59:20 UTC (full logs).

Meeting summary

  1. dvorkin to present SFC model (alagalah, 20:00:24)
  2. Discuss proposed model for SFC and traffic steering intent: detailed syntax and semantics including "connector" or "interface" definition (alagalah, 20:02:49)
    1. https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 (alagalah, 20:07:19)
    2. https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 (alagalah, 20:07:31)
    3. https://cisco.webex.com/ciscosales/j.php?MTID=m98f331fdbf75117ff8046a55ed272913 (tbachman, 20:07:58)
    4. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:REQUIREMENTS (alagalah, 20:09:19)
    5. https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:REQUIREMENTS#Agenda (alagalah, 20:09:44)
    6. mickey_spiegel asks if we change address (e.g. destination address changes from VIP to different server), is this supported? (tbachman, 20:11:35)
    7. dvorkinista says under the hood, it will look like a change of contract, but the goal should be to keep the original contract (tbachman, 20:12:22)
    8. mickey_spiegel says from an enforcement point of view, address is all we have to on (tbachman, 20:12:43)
    9. dvorkinista says that certain things can be done in an implicit fashion (tbachman, 20:13:00)
    10. the external interfaces that deal with these things should be self-consistent with the model that’s been defined, rather than the model that’s implicit (tbachman, 20:13:22)
    11. mickey_spiegel is concerned about restrictions from a user’s perspective when provisioning (tbachman, 20:14:20)
    12. mickey_spiegel says that 2 groups of servers behind the same VIP, do that have to be in the same EPG? (tbachman, 20:14:36)
    13. dvorkinista says they can be in different ones (tbachman, 20:15:10)
    14. dvorkinista says there are two ways to do this (tbachman, 20:15:25)
    15. do we want to treat things that involve address transformation as an EPG? (tbachman, 20:15:42)
    16. if we do this, then we’re saying that this behavior is not simulatable within the hypervisor (tbachman, 20:15:59)
    17. We end up making things more concrete than they have to be (tbachman, 20:16:15)
    18. mickey_spiegel says that the LB in the hypervisor is for East-West, with distributed implementation of the LB (tbachman, 20:16:38)
    19. says the problem in hiding some of this, if there’s anything before the LB, you only have the VIP to go on (tbachman, 20:17:23)
    20. dvorkinista says we can entertain a notion of a concept as treating a LB as it’s own EPG with a specific contract (tbachman, 20:17:47)
    21. once you start doing direct server return, you start violating the intent of the EPG (tbachman, 20:18:26)
    22. mickey_spiegel is concerned that there are certain configurations that are unachievable (tbachman, 20:19:09)
    23. 2 groups of servers, A and B, and they’re behind the same VIP, and have from the outside-in one or more services before the LB (tbachman, 20:19:31)
    24. dvorkinista invents the twinky service (tbachman, 20:22:11)
    25. dvorkinista says you can use two different chains that get realized on the same set of devices (tbachman, 20:23:18)
    26. or you can rely on labels (tbachman, 20:23:22)
    27. depending on what roles are used (consumer or provider) (tbachman, 20:23:39)
    28. mickey_spiegel says that with 2 different VIPs, you can easily distinguish this (tbachman, 20:23:51)
    29. mickey_spiegel maintains that this still is a problem with a single VIP (tbachman, 20:24:04)
    30. dvorkinista says that with a single VIP, we can’t do this w/o knowledge of the LB (tbachman, 20:24:49)
    31. mickey_spiegel says he’s just trying to say that this configuration shouldn’t be allowed (tbachman, 20:25:02)
    32. mickey_spiegel asks if the user has input on what the VIP is? (tbachman, 20:25:17)
    33. dvorkinista says the user has the ability to provide this input (tbachman, 20:25:34)
    34. mickey_spiegel says if the customer’s directly saying what the VIP is, then we get into trouble (tbachman, 20:26:24)
    35. but if they provide a pool of VIPs, it’s not a problem (tbachman, 20:26:34)
    36. dvorkinista agrees this should not be hard-coded into the intent (tbachman, 20:26:44)
    37. but it has to come from somewhere (tbachman, 20:26:48)
    38. it can be added into some EPR field (tbachman, 20:27:01)
    39. there can be multiple ways (tbachman, 20:27:16)
    40. mickey_spiegel says whether it’s one-to-one vs. many-to-one is the real issue (tbachman, 20:27:27)
    41. dvorkinista says that there is another orchestration system that configured the guts of the LB (tbachman, 20:27:50)
    42. dvorkinista says we can say a VIP is popualated in an EPR by an act of magic (tbachman, 20:29:02)
    43. mickey_spiegel asks what makes the association of the VIP and the chain? (tbachman, 20:29:21)
    44. dvorkinista says that it’s only in the rendering time when those things come into scope (tbachman, 20:29:33)
    45. when the chain gets rendered, this information becomes available (tbachman, 20:29:46)
    46. using continuous evaluation (tbachman, 20:29:57)
    47. mickey_spiegel says we have to know whether these two chains are using the same chain or not so we can add restrictions to their content (tbachman, 20:30:15)
    48. dvorkinista says we can have something in the LB like “VIP desire” (tbachman, 20:31:29)
    49. mickey_spiegel asks if this is related to the connector concept (tbachman, 20:31:42)
    50. dvorkinista says that it’s like a special kind of connector (tbachman, 20:31:53)
    51. mickey_spiegel says that anything that has any form of NAT is a problem scenario (tbachman, 20:32:47)
    52. dvorkinista says this is represented in the IP desire (tbachman, 20:33:38)
    53. Sanjay asks if this is working in both directions (tbachman, 20:33:48)
    54. dvorkinista says he doesn’t know yet (tbachman, 20:33:53)
    55. mickey_spiegel says that in the middle of a chain, it’s not an issue. (tbachman, 20:34:17)
    56. There is a question of the return from the LB (tbachman, 20:35:59)
    57. is there a separate sub-connector for the VIP Desire (tbachman, 20:36:09)
    58. or a separate connector (tbachman, 20:36:13)
    59. dvorkinista draws a diagram with the in/out connectors as sub-elements of VIP Desire (tbachman, 20:37:16)
    60. mickey_spiegel says that in our previous discussions, we wanted to allow many-to-one, but there are some special cases (tbachman, 20:37:54)
    61. mickey_spiegel says that many to one in to the service we definitely want (tbachman, 20:41:43)
    62. mickey_spiegel and sanjay say that many-to-one out of a service is questionable (tbachman, 20:41:58)
    63. mickey_spiegel is fine with allowing it (tbachman, 20:42:05)
    64. dvorkinista says that this is important, b/c we may be limiting things — like awareness of how many groups are providing the contract (tbachman, 20:43:09)
    65. mickey_spiegel says as an example, if you add P3, you don’t have to change the configuration. (tbachman, 20:43:28)
    66. SLB configuration (mickey_spiegel, 20:43:49)
    67. dvorkinista points out that you can think of the terminal as a completely different pool (tbachman, 20:45:15)
    68. mickey_spiegel says that on the left of the SLB, if you’re in the same desire group, and you’re going from right to left, there’s no way to distinguish (tbachman, 20:46:17)
    69. dvorkinista says unless you have an understanding of what’s going on in the appliance (tbachman, 20:46:36)
    70. mickey_spiegel says there’s a question of whether the appliance puts anything in the dataplane that can be used (tbachman, 20:47:00)
    71. mickey_spiegel says that on the left of the SLB, if you’re in the same desire group, and you’re going from right to left, there’s no way to distinguish whether it came from pool 1 or pool 2 (tbachman, 20:50:09)
    72. mickey_spiegel says this is only a problem if they’re providing different contracts (tbachman, 20:50:31)
    73. dvorkinista says that the single VIP is the problem (tbachman, 20:59:49)
    74. in the diagram that dvorkinista drew, CONTR1 and CONTR2 are contracts consumed by ePG C1 (tbachman, 21:01:37)
    75. and CONTR1 is provided by EPGs P1 and P22 (tbachman, 21:01:56)
    76. and CONTR2 is provided by EPG P2 (tbachman, 21:02:04)
    77. mickey_spiegel asks if inheritance can be used in a way where it’s applied on the left side of the chain but not the right (tbachman, 21:03:58)
    78. dvorkinista says let’s not go there just yet (tbachman, 21:04:06)
    79. dvorkinista says that the direct return creates problems (tbachman, 21:04:20)
    80. dvorkinista proposes that we don’t support graph, we only support a chain (tbachman, 21:08:29)
    81. which means we only have one terminal out of the chain, not two (tbachman, 21:08:40)
    82. mickey_spiegel says chain or graph doesn’t matter, it only matters if p1 and p2 are the same (tbachman, 21:09:03)
    83. if you add that restriction, then none of this comes up. (tbachman, 21:09:15)
    84. mickey_spiegel proposes any contract gets its own VIP (tbachman, 21:09:25)
    85. dvorkinista says this is a fair restriction (tbachman, 21:09:37)
    86. sanjay asks how multiple VIPs helps (tbachman, 21:10:34)
    87. mickey_spiegel says the destination address tells you the VIP, regardless of which side of the SLB you’re on (tbachman, 21:10:54)
    88. mickey_spiegel says that we need to think about whether there are cases where people need the same VIP (tbachman, 21:11:15)
    89. dvorkinista says it would be nice to validate these assumptions with the service chaining folks (tbachman, 21:13:51)
    90. ACTION: dvorkinista and mickey_spiegel to talk with the service chaining folks (tbachman, 21:14:24)

  3. connectors (tbachman, 21:14:36)
    1. dvorkinista drew connectors as into the function (tbachman, 21:14:47)
    2. mickey_spiegel says that we want connectors out of the function as well (tbachman, 21:15:26)
    3. dvorkinista draws function with a terminal (tbachman, 21:15:49)
    4. where terminal has an in and out (tbachman, 21:15:55)
    5. and a function can have multiple terminals (tbachman, 21:16:17)
    6. and they can be on the inputs and outputs (tbachman, 21:16:27)
    7. mickey_spiegel is fine with this (tbachman, 21:16:35)
    8. mickey_spiegel asks that regardless of whether these terminals represent VLANs, interfaces, etc. — that’s part of the abstraction (tbachman, 21:17:37)
    9. dvorkinista says that yes, this is part of the abstraction (tbachman, 21:17:44)
    10. sanjay says that depending on the function, you will have one or more terminals (tbachman, 21:18:06)
    11. but that there is a terminal per mapping (e.g. one is a VXLAN tunnel, one is VLANs) (tbachman, 21:18:38)
    12. dvorkinista says that won’t be in the intent (tbachman, 21:18:45)
    13. and that architecture-specific constraints shouldn’t be called out in the intent (tbachman, 21:18:59)
    14. mickey_spiegel says that what the terminal maps to is rendering (tbachman, 21:19:12)
    15. or enforcement (tbachman, 21:19:34)
    16. mickey_spiegel notes we have an API freeze in a week (tbachman, 21:20:00)
    17. is this for post-helium (tbachman, 21:20:04)
    18. dvorkinista says yes, this is post-helium (tbachman, 21:20:12)
    19. sanjay asks whether flow-based exceptions will be covered, or will this be post-helium (tbachman, 21:20:41)
    20. dvorkinista says that helium is just proof of concept, so let’s do it after helium (tbachman, 21:21:00)


Meeting ended at 21:21:24 UTC (full logs).

Action items

  1. dvorkinista and mickey_spiegel to talk with the service chaining folks


Action items, by person

  1. mickey_spiegel
    1. dvorkinista and mickey_spiegel to talk with the service chaining folks


People present (lines said)

  1. tbachman (111)
  2. alagalah (12)
  3. odl_meetbot (4)
  4. mickey_spiegel (2)
  5. dconde (1)


Generated by MeetBot 0.1.4.