#opendaylight-group-policy: Usecase discussion

Meeting started by alagalah at 20:02:46 UTC (full logs).

Meeting summary

  1. Traffic steering use cases (alagalah, 20:03:45)
    1. dvorkin shares code showing the service chain of consumer and provider (alagalah, 20:08:27)
    2. https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2014-July/000367.html example of sketch of service chaining (tbachman, 20:09:52)
    3. mickey_spiegel asks why we need to distinguish between provider connection and service connection (tbachman, 20:10:06)
    4. dvorkinista says that there are some cases where there are more than a single input (tbachman, 20:10:21)
    5. mickey_spiegel asks for an example of input (tbachman, 20:10:28)
    6. dvorkinista says input is a consumer and output is a provider (tbachman, 20:10:36)
    7. depending on the differen consumer, they can be processed differently (tbachman, 20:10:55)
    8. consumer is the beginniing of the chain (tbachman, 20:11:04)
    9. sanjay asks to see an example (tbachman, 20:11:56)
    10. dvorkinista goes over example provided in the email (tbachman, 20:12:06)
    11. the consumer-connector is basically a terminator (tbachman, 20:12:36)
    12. the chain is expressed in terms of coming towards the provider (tbachman, 20:13:17)
    13. mickey_spiegel asks if it’s bi-directional, why do you need a provider-connector? (tbachman, 20:14:06)
    14. dvorkinista says the last stage of the chain is the one that’s facing the provider. (tbachman, 20:14:47)
    15. the first stage of the chain faces the consumer and the last stage of the chain is the one facing the provider (tbachman, 20:16:25)
    16. mickey_spiegel asks why we need two in statements at each hop to support this (tbachman, 20:16:38)
    17. dvorkinista says these are needed for direct return (tbachman, 20:16:46)
    18. mickey_spiegel asks how you can figure out direction (tbachman, 20:19:27)
    19. dvorkinista says the only way you can figure out direction is through configuration of a logical function, which currently isn’t being done (tbachman, 20:19:57)
    20. the chain itself as a function is bi-directional (tbachman, 20:21:24)
    21. but within the chain, there is flexibility (tbachman, 20:21:32)
    22. mickey_spiegel asks if we want to do more than forward and backward (tbachman, 20:21:46)
    23. dvorkinista says you can have more if you want (tbachman, 20:21:55)
    24. mickey_spiegel says that the way the direction works right now, it’s kind of confusing (tbachman, 20:23:16)
    25. dvorkinista says that for this time around, we’re not talking about configuration (tbachman, 20:23:38)
    26. mickey_spiegel asks what “in prov-side” means (tbachman, 20:24:26)
    27. dvorkinista says he’s trying to keep it at a logical level. Think of it as a logical uni-directional construct (tbachman, 20:24:46)
    28. clarification requested on line 71 (next cons-conn cons) (tbachman, 20:25:24)
    29. dvorkinista says it can talk to the load balancer or talk to the consumer connector (tbachman, 20:25:40)
    30. where the “cons” is just a name (tbachman, 20:25:59)
    31. says that this is not configuring the firewall, but configuring the direction within the network (tbachman, 20:26:50)
    32. it just says “go back to the consumer" (tbachman, 20:27:00)
    33. dvorkinista re-emphasizes this is not configuration, but just plumbing (tbachman, 20:28:00)
    34. mickey_spiegel says right now there are two next statements. How do we know which one to use (tbachman, 20:30:45)
    35. dvorkinista says that’s just configuration of the function (tbachman, 20:31:04)
    36. hemanth, sanjay, and mickey_spiegel all prefer “back” to use of next (tbachman, 20:31:58)
    37. dvorkinista says you can use that if you prefer, as it makes no difference to the renderer (tbachman, 20:32:22)
    38. mickey_spiegel asks if coupling of in and next the way to answer the question of which one to use? (tbachman, 20:33:33)
    39. dvorkinista modifies to have two seperate cases, scoped by the side it came in on (tbachman, 20:34:33)
    40. “in consumer-side => next cool-slb/cons-side" (tbachman, 20:34:47)
    41. “in prov-side => next cons-conn cons" (tbachman, 20:34:59)
    42. sanjay says that cases where there are multiple interfaces that it can go out on, you can have multiple next statements (tbachman, 20:35:44)
    43. dvorkinista provides an l3 example (tbachman, 20:38:02)
    44. mickey_spiegel asks how you can have multiple nexts on one interface (tbachman, 20:41:03)
    45. dvorkinista says that each next is an interface (tbachman, 20:41:13)
    46. mickey_spiegel says we need something as a handle — sometimes its interface, sometimes its next (tbachman, 20:46:17)
    47. dvorkinista says he’s already identified two types of interfaces — input and output (tbachman, 20:46:31)
    48. sanjay asks whether the next selection should be part of the intent (tbachman, 20:47:02)
    49. dvorkinista says there is no way to express this here, b/c we’re not configuring the firewall itself. (tbachman, 20:47:50)
    50. This language is just for specifying the plumbing (tbachman, 20:48:20)
    51. mickey_spiegel says that when a packet comes out from the service, we need to express the next thing/function to use (tbachman, 20:48:50)
    52. and that something has to come from the packet (tbachman, 20:49:00)
    53. We're kind of trapped in details. What I get so far is the proposal is that the entire service chain be built so that it can be inserted betweeen EPGs like other contracts. We are arguing about how to build the service chain data structures, but should maybe first ask if this does a good job of solving the problem, as opposed to e.g. make the virtual (dlenrow, 20:49:08)
    54. mickey_spiegel asks if we can use one abstraction for that. (tbachman, 20:49:10)
    55. dvorkinista emphasizes we’re talking about the plumbing aspects of the service chain (tbachman, 20:50:40)
    56. and next we’d talk about the configuration (tbachman, 20:50:47)
    57. this discussion is focused on just the plumbing (tbachman, 20:50:55)
    58. seems like this is not abstract enough. Surely theres a high level concept of a chain that can allow us to build them declaratively without such a complex, redundant description of how each VF ties bidirectionally to the others. If we model these as Endpoints (things that can be reached over the network) building chain gets really simple (dlenrow, 20:52:35)
    59. dvorkinsta says that there are two use cases here (tbachman, 20:53:59)
    60. one is where there is an explicitly desired SFC (tbachman, 20:54:10)
    61. the second is the provider SFC that’s inserted transparently (tbachman, 20:54:19)
    62. dvorkinista says lets first discuss the former use case (tbachman, 20:54:32)
    63. tbachman notes that dvorkinista is pretty good at ASCII art ;) (tbachman, 20:56:02)
    64. mickey_spiegel asks if there’s a difference between a function connector and logical interface (tbachman, 21:01:47)
    65. dvorkinista says that interfaces are symantically overloaded and mean something (tbachman, 21:02:04)
    66. The connector here identifies the input into a function (tbachman, 21:02:42)
    67. That’s how you get in to the function, and therefore the chain (tbachman, 21:02:54)
    68. mickey_spiegel asks if line inputs and connectors are 1-to-1 (tbachman, 21:04:07)
    69. dvorkinista says no — you can have others (tbachman, 21:04:21)
    70. dvorkinista draws an example of multiple lines to a single connector (tbachman, 21:04:40)
    71. dlenrow asks if a load balancer is different enough worth treating differently (tbachman, 21:07:06)
    72. dvorkinista notes that lines come out of the function, not the connectors (tbachman, 21:08:27)
    73. the lines go in to a connector (tbachman, 21:08:33)
    74. mickey_spiegel says that connector is just an abstraction and giving a name to it. (tbachman, 21:08:49)
    75. sanjay asks if we can have input and output connectors, each having an input, an output, or bi-dir (tbachman, 21:13:16)
    76. dvorkinista asks what happens when you try to specify next (tbachman, 21:13:36)
    77. mickey_spiegel says it comes down to “what is a connector" (tbachman, 21:14:52)
    78. dvorkinista then draws up a model with a single connector, with multiple next statements underneath it (tbachman, 21:15:43)
    79. mickey_spiegel says he wants connectors with next’s that specify what they connect to (tbachman, 21:16:09)
    80. mickey_spiegel says this way is an abstraction around x (tbachman, 21:16:49)
    81. dvorkinista says in this case, connector doesn’t do anything (tbachman, 21:16:58)
    82. mickey_spiegel says it gives you a point where you can do something once you get to the discussion on configuration (tbachman, 21:17:18)
    83. sanjay says that connectors are vertices and nexts are links (tbachman, 21:17:40)
    84. mickey_spiegel asks if there is some operational model that maps connectors to somting (tbachman, 21:20:42)
    85. How do we use this. Assume there is a good way to describe the service chain. (suspend syntax argument for now). What does it look like to add SC1 between Sales EPG and the Internet EPG and add SC2 between finance EPG and special server EPG? (dlenrow, 21:23:48)
    86. mickey_spiegel says if you look at the openstack model, there’s the same question of the port (tbachman, 21:24:23)
    87. sanjay says that it’s about context — each connector provides a context (tbachman, 21:24:44)
    88. dlenrow says that it’s worth taking a step back at this point (tbachman, 21:26:10)
    89. dvorkinista says there’s a fundamental question of do we want an interface ,and what we want to call it. (tbachman, 21:26:50)
    90. dlenrow says independent of that, ther’es the question of what it looks like when you bring in EPGs and specific instances of virtual functions into the picture (tbachman, 21:27:19)
    91. mickey_spiegel says that this is a good point, b/c you get into this by associating to groups (tbachman, 21:27:52)
    92. dvorkinista says we shouldn’t confuse how things behave on the wire vs. what the traffic is subjected to (tbachman, 21:28:24)
    93. (i.e. what kinds of things can communicate and how they communicate vs. what operations are perfomed on the traffic) (tbachman, 21:28:54)
    94. dvorkinista says that the next/prev provides a context, and the rest of it is the configuration of the appliance (tbachman, 21:30:52)
    95. dvorkinista says you can treat an SLB as something that has its own contract, but its implicit (tbachman, 21:39:53)
    96. mickey_spiegel says this kind of seems like you’re hopping contracts (tbachman, 21:41:36)
    97. dvorkinista says that this is correct (tbachman, 21:41:42)
    98. ACTION: dvorkinista will look into providing the slides (tbachman, 21:44:33)
    99. we’ll think about the connector description and how that’s used (tbachman, 21:45:01)
    100. ACTION: dvorkinista wil send the slides to sanjay, who will upload them to the wiki (tbachman, 21:45:37)
    101. ACTION: mickey_spiegel will put syntax of the SFC with the connector definition and the behavior of a LB with VIPs and contracts applied onto Friday’s agenda (tbachman, 21:46:10)


Meeting ended at 21:46:54 UTC (full logs).

Action items

  1. dvorkinista will look into providing the slides
  2. dvorkinista wil send the slides to sanjay, who will upload them to the wiki
  3. mickey_spiegel will put syntax of the SFC with the connector definition and the behavior of a LB with VIPs and contracts applied onto Friday’s agenda


People present (lines said)

  1. tbachman (102)
  2. alagalah (10)
  3. odl_meetbot (6)
  4. dlenrow (4)
  5. hemanthravi (4)
  6. dconde (0)


Generated by MeetBot 0.1.4.