#opendaylight-nic: f2f

Meeting started by dbainbri at 18:09:19 UTC (full logs).

Meeting summary

    1. tbachman (Noiro) (tbachman, 18:11:23)
    2. dmentze says that HP has experience with commercial grade SDN controllers; hoping to bring that experience in for the benefit to ODL (tbachman, 19:08:14)

  2. Multiple application support (Duane) (gzhao, 19:08:58)
    1. dmentze says the multi-writer problem can occur with a single API — app A and app B calling same API, can result in collision (tbachman, 19:09:59)
    2. dmentze says he doesn’t want to get stuck on the terminology; wants to address the technology, their definitions, and how do they address the problems that are trying to be solved (tbachman, 19:12:57)
    3. dmentze says the Intent API is used by applications to: specify desried network behavior; and exchange real-time network information (tbachman, 19:13:45)
    4. goals include: easy for app-writiers (don’t need to become networking experts); suport multiple-apps (no need to coordinate — interface addresses potential for conflict); decoupled from physical network changes (apps don’t need to react or be aware of changes in the topology or technology) (tbachman, 19:14:41)
    5. dmentze provides a VOIP Call Optimization exmample (tbachman, 19:21:37)
    6. Step 1, VOIP server provides a NOtify: new Lync session (lp1, lp2) (tbachman, 19:21:54)
    7. An Optimizer App receives the Notify, calls the SDN Controller with GetNetworkNode DPID, Port(Ip) (tbachman, 19:22:31)
    8. the Optimizer App calls the SDN Controller SendFlowMod(Write dscp, output port) (tbachman, 19:22:54)
    9. (and GetNetworkNode means "get me the location of two endpoints" (ShaunWackerly, 19:23:07)
    10. the SDN Controller makes an Openflow FlowMod(Write dscp, Output port) to the appropriate nodes (tbachman, 19:23:34)
    11. Another use case is Network Monitor (tbachman, 19:24:00)
    12. An admin selects a user to monitor — provides it to a Monitor App (tbachman, 19:24:23)
    13. the Monitor App calls GetNetworkNode DPID, Port(Ip) (tbachman, 19:24:32)
    14. the Monitor App calls SendFlowMod(output port+tunnel) (tbachman, 19:24:51)
    15. dmentze illustrates how the Monitor App and the Optimizer app can collide here (tbachman, 19:25:36)
    16. dmentze says this is the multi-writer problem, illustrated through multi-apps (tbachman, 19:25:56)

  3. Prototype Intent API syntax presentation (tbachman, 19:26:21)
    1. dmentze provides of intent-based policy examples (tbachman, 19:26:55)
    2. example: “DNS queries are allowed, but only when directed to one of our authorized DNS servers and all of these DNS queries are to be inspected first by one of our IPS servers” (tbachman, 19:27:36)
    3. dmentze provides an example of the model (tbachman, 19:28:03)
    4. source group, destination group, classifier, policy, and context are the model elements (tbachman, 19:28:32)
    5. the source group and destination group intersect with the classifier and policy, all within the scope of a context (tbachman, 19:29:02)
    6. Intent are “principles” that applications and administrators specify to guide decisions on the treatment of traffic on the network (tbachman, 19:29:36)
    7. Policies are set for specific communication between two endpoint groups on the network (tbachman, 19:30:07)
    8. Intent-based policies are network topology and technology independent (tbachman, 19:30:19)
    9. dmentze says that the concept of Dynamic Endpoint Groups have been mentioned on the wiki (tbachman, 19:30:54)
    10. source and destination endpoint groups specify the set of hosts for the policy (tbachman, 19:31:07)
    11. Group descriptions are Boolean expressions with endpoint attributes as terms (tbachman, 19:31:19)
    12. 3 types of EPGs are: ID, group, dynamic (tbachman, 19:31:27)
    13. https://wiki.opendaylight.org/view/Network_Intent_Composition:Dynamic_Attributes (ShaunWackerly, 19:31:32)
    14. dbainbri asks how hosts are defined (tbachman, 19:31:33)
    15. mickey_spiegel says there’s been discussion on the mailing lists — doesn’t believe this has been completely resolved (tbachman, 19:32:07)
    16. CharlesClark says he defines endpoint as a source/sink of information (ShaunWackerly, 19:32:42)
    17. Atributes are applications and customer defined statically or dynamically applied to endpoints in the endpoint database; and dynamically evaluated by the SDN controller policy engine (tbachman, 19:32:42)
    18. Access control restricts permitted applications to use and change specific endpoint attributes (tbachman, 19:32:55)
    19. examples include: “employee AND multifactorAuthenticated”; “tablet AND corporateDevice”; “server2003sp3 AND NOT ufeiBios” (tbachman, 19:33:53)
    20. 3 types of endpoints are identification (ip/mac), group (administratively assigned), and dynamic (change w/network condition) (ShaunWackerly, 19:36:04)
    21. someone asks difference between an endpoint group and an endpoint attribute (tbachman, 19:36:16)
    22. an attribute is a single value, and a group is a logical expression of attributes (ShaunWackerly, 19:36:58)
    23. correction: 3 types of endpoint attributes, not 3 types of EPGs (ShaunWackerly, 19:37:45)
    24. dbainbri says that groups are very dynamic; difference has to do with rate of change (tbachman, 19:38:42)
    25. dmentze says dynamic is something changing on its own; group is something that is changed administratively (tbachman, 19:40:03)
    26. Extnsible policies are covered next (tbachman, 19:40:21)
    27. the 3-type distinction isn't codified into the prototype (ShaunWackerly, 19:40:27)
    28. policies decribe the treatement to be applied to the communication between endpoint groups (tbachman, 19:40:42)
    29. each intent contains a sequence of actions (tbachman, 19:40:50)
    30. policies are executed in the order specified (tbachman, 19:40:58)
    31. e.g. multiple inspect policy actions (service chaining) are performed according to the order specified. (tbachman, 19:41:55)
    32. Cathy asks if there is separate classifier for source + dest EPG (ShaunWackerly, 19:44:39)
    33. dmentze says our prototype chose to use single classifier for both (ShaunWackerly, 19:44:54)
    34. break for lunch, back @ 12:15 (ShaunWackerly, 19:46:28)
    35. starting up again (ShaunWackerly, 20:17:43)
    36. dbainbri asks if "traffic" is being used as "classifier" (ShaunWackerly, 20:20:35)
    37. dmentze says yes (ShaunWackerly, 20:20:42)
    38. dbainbri asks if "traffic" and "policy" could be combined into 'VOIP' in the example (ShaunWackerly, 20:21:04)
    39. CharlesClark says yes (ShaunWackerly, 20:21:13)
    40. CharlesClark says we chose a particular set of classifiers and actions to use in the prototype (ShaunWackerly, 20:21:37)
    41. mickey_spiegel says the first 3 things listed are what flows are being affected; the last one is what you do with it (tbachman, 20:22:37)
    42. note: this in the context of an Intent API, with an example like this: Intent(user1, employee, Traffic=all, Audit) (tbachman, 20:23:24)
    43. another example of the use of the Intent API is: Intent(user1, user2, traffic=voip, QOS(high)) (tbachman, 20:24:02)
    44. dmentze says this slide isn’t about the actual interface — the interface was just a necesarry in order to demonstrate how it could be used (tbachman, 20:25:14)
    45. dmentze says the compiler takes the two intents and creates two compiled nodes (tbachman, 20:27:39)
    46. dmentze says the definition of orthogonality is that no packets can get the same region (tbachman, 20:28:08)
    47. dmentze says this is an example of composition; compiled policies can possibly conflict (tbachman, 20:28:55)
    48. dmentze says in the VOIP Call Optimization and Monitor, the policy space is orthogonal (tbachman, 20:29:26)
    49. mickey_spiegel says that in making this orthogonal, you’re making these as disjoint sets? (tbachman, 20:29:43)
    50. dmentze says yes (tbachman, 20:29:47)
    51. dmentze browses to unit test code for this example (ShaunWackerly, 20:31:12)
    52. dmentze explains that since this is a unit test, it is adding network basis to give a network upon which the prototype will operate (ShaunWackerly, 20:31:41)
    53. dmentze begins example 2 (ShaunWackerly, 20:36:31)
    54. in dmentze's examples, "Monitor" translates to the following use case: (ShaunWackerly, 20:38:09)
    55. https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#Network_Monitoring_of_a_Single_User (ShaunWackerly, 20:38:13)
    56. in dmentze's examples, "Optimizer" translates to the following use case: (ShaunWackerly, 20:38:39)
    57. https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#Lync_call_QoS (ShaunWackerly, 20:38:41)
    58. in dmentze's examples, "Security" translates to the following use case: (ShaunWackerly, 20:39:04)
    59. https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases#DNS_monitoring_for_infection (ShaunWackerly, 20:39:06)
    60. dbainbri comments on scalability issue on adding tags etc (gzhao, 20:42:26)
    61. mickey_spiegel questions whether wildcarding with exceptions (all hosts except 10.0.0.1) will result in explosion of output (ShaunWackerly, 20:42:39)
    62. CharlesClark says that some ideas exist for mitigating that problem (ShaunWackerly, 20:43:29)
    63. CharlesClark says that the prototype is displaying IP addresses, but it could also just display EPG expression instead (ShaunWackerly, 20:44:51)
    64. Cathy says intent specified "infected", asks how endpoint is associated with "infected" (ShaunWackerly, 20:46:16)
    65. dmentze says a security service on the network tells the controller which endpoint is "infected" (ShaunWackerly, 20:46:33)
    66. My question was whether the compiler output is in terms of individual endpoints or in terms of endpoint groups, e.g. the intersection of two endpoint groups (mickey_spiegel, 20:47:19)
    67. Heard the latter is correct (mickey_spiegel, 20:47:28)
    68. alagalah asks if endpoint attributes are tagged on multiple endpoints, then the endpoint database is queried to get the matching set of endpoints for a specific attribute or group (ShaunWackerly, 20:56:25)
    69. confirmed as correct interpretation (ShaunWackerly, 20:56:49)
    70. CharlesClark points out that example 1 was an example of composition (fulfilling both intents) (ShaunWackerly, 20:57:58)
    71. CharlesClark points out that example 2 was an example of conflict, where 'block' conflicts with 'set QoS' and a winner is chosen (ShaunWackerly, 20:58:28)
    72. dmentze identifies extensibility in endpoint database and codegenerator (ShaunWackerly, 21:00:42)
    73. dbainbri asks if policy compiler output should be written to ODL's existing model (ShaunWackerly, 21:03:02)
    74. dmentze says that what's being displayed is the intermediate language between policy compiler and codegenerator (ShaunWackerly, 21:03:31)
    75. alagalah points out that codegenerator is similar to a renderer in GBP (ShaunWackerly, 21:03:52)
    76. CharlesClark points out the code generation portion is plug-able, people can customize it. (gzhao, 21:05:34)
    77. dbainbri suggests ODL to have a common abstract model and plugin derive it to talk to device. (gzhao, 21:07:38)
    78. mickey_spiegel, dbainbri and others discuss whether things with network-wide view within ODL (GBP, OVSDB) talk to the intent API to get their work done, or whether something like GBP or OVSDB could set underneath codegenerator and retain its network-level view. (ShaunWackerly, 21:10:50)
    79. mickey_spiegel asks if SFC would be incorporated into codegenerator (ShaunWackerly, 21:13:44)
    80. dmentze says we'll get to it later (ShaunWackerly, 21:13:50)
    81. end point database (gzhao, 21:15:46)
    82. dynamic SFC (gzhao, 21:15:56)
    83. mickey_spiegel notes some action such as allow and block has relations. (gzhao, 21:18:35)
    84. dbainbri asks how this approach would accomodate path computation (ShaunWackerly, 21:24:22)
    85. CharlesClark said inspect here means SFC (gzhao, 21:24:27)
    86. dmentze says a slide later will address it (ShaunWackerly, 21:27:30)
    87. mickey_spiegel asks if a single composable flag is sufficient (ShaunWackerly, 21:27:44)
    88. CharlesClark says it would really end up being a matrix (ShaunWackerly, 21:27:53)
    89. policy conflict resolution: exclusive->composable-> action precedence-> app priority (gzhao, 21:44:01)
    90. question who defines precedence (gzhao, 21:44:20)
    91. CharlesClark said you need to define actions before intent (gzhao, 21:45:27)
    92. ShaunWackerly said that actions are registered with policy compiler (for use by apps in Intent statements) and action translators are registered with the code generator (for use in translating an action to a native protocol, like OpenFlow). (ShaunWackerly, 21:49:25)
    93. CharlesClark said ODL needs to first declare a set of supported actions, then application can select from those actions, dmentze said precedence is an attribute of action. (gzhao, 21:56:01)
    94. daveL suggest not to use terms as policy and app (gzhao, 21:59:08)
    95. multiple people discuss how codegenerator and forwarding engine cooperate to control policy and forwarding together, without stomping on eachother. (ShaunWackerly, 22:11:56)

  4. Service Function Chainiing (gzhao, 22:42:16)
    1. hideyuki asks for the relationship with the prototype code with ODL NIC (gzhao, 23:11:24)
    2. CharlesClark says there is no relationship between the ONF SFC prototype and the prototype that dmentze presented today (ShaunWackerly, 23:21:19)
    3. multiple people discuss whether the prototype dmentze presented would make a good starting point for NIC, or whether it would be better to start from scratch or another prototype/code set. (ShaunWackerly, 23:22:02)
    4. dmentze points out that if the prototype leads to a NIC implementation, we'd need to place requirements on SFC to work with attributes (ShaunWackerly, 23:23:19)
    5. dlenrow says intent is an overlay (ShaunWackerly, 23:28:22)
    6. dlenrow says first you build physical layer, then build virtual layer on top of it. Intent is an overlay layer that comes in later that allows portability and external NBI support. (ShaunWackerly, 23:29:17)
    7. dlenrow identifies border control (ie: edge characteristics) and underlay control (ie: tunnels) as areas where physical specifics are needed, need layer on top (ShaunWackerly, 23:32:15)
    8. dlenrow identifies virtual function pool could be an EPG (ShaunWackerly, 23:32:44)
    9. dbainbri says we can look at SFC as a black box from the controller (or policy engine) (ShaunWackerly, 23:34:48)
    10. dbainbri says service functions could get injected into resource pools, where the policy engine could pick from that resource pool when it needs a service instance (ShaunWackerly, 23:35:43)
    11. dlenrow says this would allow a network fault to be handled by the controller, rather than a lower layer (ShaunWackerly, 23:36:17)
    12. dbainbri says that service functions could be exposed like endpoints, questions whether we are picking from a pool or merely resolving an attribute to a specific instance (ShaunWackerly, 23:37:48)
    13. dbainbri notes that a query may request a service instance, but include restrictions/criteria related to location (ShaunWackerly, 23:38:51)
    14. dbainbri and dlenrow discuss whether constraints are given as part of calling context, or if they are specified with each request (I think) (ShaunWackerly, 23:40:32)
    15. dbainbri shows that intents may decompose into more-and-more precision, including insertions of SFCs (ShaunWackerly, 23:43:58)
    16. louisfourie says it would be nice if we could tag service instances with attributes (ShaunWackerly, 23:47:54)
    17. CharlesClark explains that the prototype model had an EndpointGroup class, and a ServiceGroup which extended it (ie: both based on attributes) (ShaunWackerly, 23:48:36)
    18. dbainbri asks whether attributes have a value or namespace, or whether they merely exist in isolation (ShaunWackerly, 23:49:51)
    19. dbainbri says we should avoid building typing into attribute definition (ShaunWackerly, 23:50:15)
    20. CathyZhang presents about composite endpoint descriptor (CED), which consists of a set of flexible endpoint descriptors (ShaunWackerly, 00:00:30)
    21. CathyZhang shows FEDs (flexible endpoint descriptors) as each having a type and value, combined in logical expressions (ShaunWackerly, 00:02:27)
    22. CathyZhang shows that FEDs could be included in endpoint groups to classify flow as part of endpoint group definition (ShaunWackerly, 00:03:30)
    23. CathyZhang says there would be a base set of well-known endpoint descriptor types, and that a CED may also references another CED. (ShaunWackerly, 00:04:13)
    24. dlenrow asks if the current GBP project has higher-level EPG registry could be made compatible with (or used by) NIC (ShaunWackerly, 00:06:07)
    25. dbainbri says we have an existing endpoint database in the inventory (ShaunWackerly, 00:06:30)
    26. the EPG stored by GBP stores duplicate data as compared with inventory (ShaunWackerly, 00:08:44)
    27. dbainbri worries that duplicated data complicates adding endpoints (ShaunWackerly, 00:09:18)
    28. CathyZhang proposes that endpoints not be defined as a "host", but rather at any L1-L7 layer (ShaunWackerly, 00:10:57)
    29. CathyZhang says such a model is very flexible (ShaunWackerly, 00:11:13)
    30. (?) this flexible model would be difficult to map to what already exists and is tracked by ODL (hosts/OpenFlow/etc) (ShaunWackerly, 00:12:17)
    31. dlenrow says that NIC/Intent may need to extend what's already in ODL to get what it needs (ShaunWackerly, 00:13:48)
    32. dbainbri disagrees ... (ShaunWackerly, 00:14:00)
    33. discussion of where classifier should belong (gzhao, 00:15:41)
    34. dbainbri says reusability of components (classifier, EPG, etc) is important to him (ShaunWackerly, 00:17:31)
    35. ONF SFC discussion will be deferred to Friday's team meeting (gzhao, 00:48:27)

  5. terminology discussion (gzhao, 01:04:00)
    1. ACTION: ShaunWackerly is going to put presentation slides on wiki (gzhao, 01:09:46)


Meeting ended at 01:09:54 UTC (full logs).

Action items

  1. ShaunWackerly is going to put presentation slides on wiki


Action items, by person

  1. ShaunWackerly
    1. ShaunWackerly is going to put presentation slides on wiki


People present (lines said)

  1. ShaunWackerly (105)
  2. tbachman (103)
  3. gzhao (35)
  4. dbainbri (11)
  5. odl_meetbot (7)
  6. mickey_spiegel (4)
  7. rukhsana (2)


Generated by MeetBot 0.1.4.