#opendaylight-meeting: tsc

Meeting started by colindixon at 17:59:54 UTC (full logs).

Meeting summary

  1. roll call and agenda bashing (colindixon, 18:00:04)
    1. colindixon (colindixon, 18:00:08)
    2. https://wiki.opendaylight.org/view/TSC:Main the agenda in it’s usual place (colindixon, 18:00:23)
    3. dlenrow (dlenrow, 18:00:33)
    4. edwarnicke (edwarnicke, 18:02:17)
    5. kwatsen (kwatsen, 18:02:27)
    6. colindixon asks rexpugh and steve dean if they need to present their proposals today, they say no, but that they can if we have time (colindixon, 18:03:20)
    7. LuisGomez (LuisGomez, 18:03:35)
    8. https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-12-04-18.00.html meeting minutes from last week for action items (colindixon, 18:03:43)
    9. Youcef Laribi (Youcef, 18:03:53)
    10. ACTION: colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here (colindixon, 18:04:43)
    11. mohnish (mohnish, 18:07:43)
    12. Discussion about version bumping better with zxiiro mlemay and edwarnicke (dfarrell07, 18:07:47)
    13. Chris Price (apologies I'm late) (ChrisPriceAB, 18:08:08)
    14. regXboi - here to apologize for not being here - and then running away (regXboi, 18:08:33)
    15. phrobb working with tykeal to get new certs for OSX, progress but no solution yet (dfarrell07, 18:08:49)
    16. phrobb worked with CAPWAP to revise project proposal (dfarrell07, 18:09:53)
    17. ACTION: edwarnicke and jan medved to work with phrobb to the mac certificate issue (colindixon, 18:10:21)
    18. colindixon hopes we can approve CAPWAP via email (dfarrell07, 18:13:49)
    19. phrobb has sent mail about timezones for TSC meetings (dfarrell07, 18:14:12)
    20. phrobb is still working on intern stuff (dfarrell07, 18:14:58)
    21. Need to propose intern projects, people are asking for them (dfarrell07, 18:15:22)
    22. phrobb notes that job board will go live next week, good for posting inter positions, phrobb will add link next week (dfarrell07, 18:16:04)

  2. updates (colindixon, 18:16:32)
    1. Apparently there are projects listed on ODL wikis that were never approved (dfarrell07, 18:17:10)
    2. ACTION: phrobb will help to clean up the non-projects from the wiki (colindixon, 18:17:25)
    3. ACTION: colindixon will try to explore the use categories which allow for easier curation of this (colindixon, 18:17:43)
    4. Everyone, please watch the wiki for mistakes like this (dfarrell07, 18:18:14)
    5. Call for papers for Summit comes out next week (dfarrell07, 18:18:43)
    6. ACTION: phrobb to start an e-mail thread on when to do a when to do a face-to-face meeting, initial ideas is 4/14-4/15 (colindixon, 18:19:30)
    7. Chris Wright (cdub, 18:20:08)
    8. zxiiro got the Lithium autobuild works and he has a simpler version he wants to propose (colindixon, 18:20:44)
    9. zxiiro will send email about Li autobuild to describe what he did (dfarrell07, 18:21:16)
    10. M1 for offset 0 is today (dfarrell07, 18:21:30)
    11. Do all the required things, projects that are offset 0 (dfarrell07, 18:21:56)
    12. No committer promotions today (dfarrell07, 18:22:25)

  3. Unified Secure Channel Creation Review (colindixon, 18:23:22)
    1. https://wiki.opendaylight.org/view/Project_Proposals:USC the project proposal page (colindixon, 18:23:42)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000203.html it was proposed on 11/20/2014 (colindixon, 18:24:10)
    3. https://wiki.opendaylight.org/view/File:Odl-usc-2014_11_20.pdf <— slide deck "very close" to what is being currently presented (phrobb, 18:24:39)
    4. jmedved (jmedved, 18:24:50)
    5. the general idea is to provide a secure channel (or tunnel) between a device and the controller as well as a way to “call home” (colindixon, 18:27:50)
    6. the idea is to do it in a way that is independent of the control protocol rather than each protocol having it’s own security (colindixon, 18:28:16)
    7. they can also tunnel multiple protocols in a single “channel” effectively sharing a single security model across them (colindixon, 18:29:47)
    8. the intent is to provide three main components: USC manager, USC plugin, and a USC agent (colindixon, 18:30:41)
    9. abhijitkumbhare asks if they want to apply this to OpenFlow’s secure channel (colindixon, 18:33:27)
    10. Helen responds saying that it’s not in scope at the moment, but they might try to support that in the future (colindixon, 18:33:59)
    11. edwarnicke (and rexpugh on IRC) ask what the underlying protocol for the secure channel is (colindixon, 18:34:48)
    12. Answer: multiple underlying protocols for secure channel (dfarrell07, 18:36:26)
    13. they will start with ssh as the underlying part (colindixon, 18:36:39)
    14. kwatsen says that what NETCONF does is just use ssh, it works for only TCP connections, but works for all TCP connections (colindixon, 18:37:50)
    15. later they will look into more general solutions as well in the future (colindixon, 18:38:11)
    16. kwatsen offers to work with the team on the approach to solving this, he seems to be an expert in the area (he mentions IETF call-home standards) (colindixon, 18:40:14)
    17. LuisGomez points out that "Control Channel" or "Management Channel" might should be in the title or description (dfarrell07, 18:41:14)
    18. LuisGomez asks if this is going to be used for management and control traffic only and if this could be added it might make things clearer (colindixon, 18:41:18)
    19. Presenter points out that they might want to make it more general in the future, so "Control Channel" or "Management Channel" might not make as much sense in the future (dfarrell07, 18:42:23)
    20. colindixon asks, and Helen confirms that this is intended to be *one* thing you could use, not *the* solution that all people should/must use (colindixon, 18:42:41)
    21. LuisGomez clarifies that his worry is that the name USC might be overly broad, but doesn’t seem to strenuously object (colindixon, 18:43:18)
    22. Helen says their intent is to make it as broad as possible and so the name fits (colindixon, 18:43:37)
    23. LuisGomez seems to move to consensus with Helen that name is okay (dfarrell07, 18:43:38)
    24. ACTION: gzhao will find username of Duanjingzhu (dfarrell07, 18:45:46)
    25. ACTION: gzhao will fill in the Duan Jingzhu’s username (colindixon, 18:45:48)
    26. rexpugh asks what the overlap is with SNBi (colindixon, 18:47:29)
    27. Helen responds that she originally thought there was significant overlap, but after talking to Franke she thinks much less so at least in the short run (colindixon, 18:48:23)
    28. SNBi is focused on L2 inside the data center building trust hop-by-hop (colindixon, 18:48:35)
    29. USC is focused on longer-distance communication through tunnels (colindixon, 18:49:03)
    30. in the future they two might merge, but for now they’re very different (colindixon, 18:49:13)
    31. VOTE: Voted on "Shall the TSC approve Unified Secure Channel project to Incubation?" Results are, +1: 11 (dfarrell07, 18:50:25)
    32. AGREED: USC has been moved to Incubation (dfarrell07, 18:50:45)

  4. welcome Rajeev as the rep from Intel (colindixon, 18:51:00)
    1. the TSC welcomes RajeevK from Intel :) (dfarrell07, 18:51:06)
    2. colindixon has updated Project Proposal main page with before/after HOWTO info (dfarrell07, 18:52:55)

  5. LACP Creation Review (phrobb, 18:53:19)
    1. https://wiki.opendaylight.org/view/Project_Proposals:Link_Aggregation_Control_Protocol the project proposal (colindixon, 18:54:10)
    2. https://wiki.opendaylight.org/view/File:LACP_Proposal.pptx the presentation (colindixon, 18:54:26)
    3. https://lists.opendaylight.org/pipermail/project-proposals/2014-October/000184.html the project was proposed on 10/22/2014 (colindixon, 18:54:43)
    4. LACP is an IEEE spec that defines a protocol to bundle multiple switch links into a single logical interface providing link redundancy and bandwidth aggregation (colindixon, 18:55:32)
    5. the spec is IEEE 803.2ad (thanks mohnish) (colindixon, 18:57:05)
    6. the general idea it to implement the LACP protocol with its various state machines (there seem to be 6 state machines) (colindixon, 18:58:48)
    7. current plan is to speak LACP via packet_in/packet_out using the OpenFlow plugin (colindixon, 18:59:16)
    8. this implementation is focused on LACP with switches/servers that are externals to SDN network (mohnish, 18:59:57)
    9. they are defining 5 yang files that govern the protocol and implementation (colindixon, 19:00:56)
    10. they describe various ways to implement LACP-equivalents with OpenFlow internally to the SDN fabric. e.g., using group table entries of type “select" (colindixon, 19:02:16)
    11. we are trying to preserve existing ODL apps behavior with respect to port or logical port (mohnish, 19:03:19)
    12. the project would like to translate physical ports in OpenFlow to logical ports so that most SDN applications need not know about the LACP to take advantage of it (colindixon, 19:04:48)
    13. this would need to not apply to LACP and LLDP messages, because those need to know about physical ports (colindixon, 19:05:23)
    14. port's transition to participate in LAG requires state changes in L2switch modules (mohnish, 19:09:42)
    15. there is a long discussion in the slides about the implications of translating physical port to the logical (bonded) port and how that impacts other apps, e.g., the L2 Switch (colindixon, 19:10:14)
    16. colindixon asks is if it’s OF-specific on behalf of dlenrow (colindixon, 19:14:50)
    17. the response is that it’s mostly OF-Independent except for getting packet_in/packet_out (colindixon, 19:15:16)
    18. response is also that it’s just using the MD-SAL FlowProgramming concepts even for the OF-specific parts (colindixon, 19:15:39)
    19. LuisGomez says likes the proposal because (1) the use case is clear and (2) it’s looks carefully at impacts on other projects (colindixon, 19:16:32)
    20. LuisGomez asks if they intent to support Multi-chassis LAG, the answer is maybe in the future (colindixon, 19:17:09)
    21. tykeal asks (as always) that the committers list include UIDs (dfarrell07, 19:17:14)
    22. ACTION: mohnish will get the remaining User IDs for the project (colindixon, 19:17:55)
    23. VOTE: Voted on "Shall the TSC approve LACP project to Incubation?" Results are, +1: 8 (dfarrell07, 19:18:53)
    24. AGREED: The TSC votes to move the LACP project to incubation (colindixon, 19:19:00)

  6. Time Series Data Repository Creation Review (dfarrell07, 19:19:58)
    1. https://wiki.opendaylight.org/view/Project_Proposals:Time_Series_Data_Repository the project proposal (colindixon, 19:20:44)
    2. https://wiki.opendaylight.org/view/File:TSDR_Proposal_ODL.pptx the slides (colindixon, 19:20:54)
    3. https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000193.html the proposal happened on 11/7/2014 (colindixon, 19:21:14)
    4. Time Series Data Repository (TSDR) is trying to capture things that might be time-varying values for the same “keys”, e.g., stats counters, performance data, health status, etc. (colindixon, 19:22:14)
    5. for Lithium the focus is on OF stats (colindixon, 19:22:31)
    6. major functions are data collection, storage, queries, aggregation and purge (colindixon, 19:23:58)
    7. mohnish notes that the time series is the focus here, but the OF stats are the first logical thing to apply it to (colindixon, 19:24:51)
    8. ChrisPriceAB has to leave the call, abhijitkumhare will take my vote on coming actions. (ChrisPriceAB, 19:26:44)
    9. dbainbri asks if this could be done with OpenTSDB ( http://opentsdb.net/ ) (colindixon, 19:27:45)
    10. mohnish says that their ideas are inline with that (e.g., they both use HBase on the back end) (colindixon, 19:28:22)
    11. the approach is to have the TSDR service track certain places in the MD-SAL and copy that data (with it’s historical values) in a parallel data store (maybe a parallel MD-SAL data store instance) (colindixon, 19:29:19)
    12. dfarrell07 will take over for cdub for Red Hat's vote (dfarrell07, 19:29:40)
    13. the goal is that the TSDR could use multiple backing stores, e.g., HBase and Splunk (colindixon, 19:31:21)
    14. dbainbri asks about how this would be integrated into existing ODL apps, can it be accessed from the MD-SAL? is it intended to be added to the existing apps, e.g., the DLUX GUI (colindixon, 19:33:11)
    15. mohnish says that this isn’t in the scope yet, but it could be done later? (colindixon, 19:34:01)
    16. colindixon asks if this will be via parallel APIs to the MD-SAL or be extensions to the existing APis in the MD-SAL (colindixon, 19:36:28)
    17. mohnish responds that he, jmedved and other are still discussing this (colindixon, 19:36:47)
    18. dfarrell07 thinks this would be useful for his work on ODL Perf and Tools sub-team of Integration team (dfarrell07, 19:37:27)
    19. the plan is persist all the TSDR data and provide queries to get metrics from the recorded data (colindixon, 19:38:51)
    20. mohnish adds (on the parallel vs. extended APIs) that the APis to access the TSDR will be new (and thus likely parallel to the MD-SAL) (colindixon, 19:39:40)
    21. dbainbri asks about the granularity of the time data, e.g., OpenTSDB was only at second granularities (colindixon, 19:42:04)
    22. the response is that the goal is provide something can receive events at the subsecond (e.g., millisecond time granularity will be accepted), but the goal for use cases is providing data back on the order minutes (colindixon, 19:44:52)
    23. jmedved, dbainbri, mohnish, and others talk about how performant it will be and/or needs to be (colindixon, 19:45:37)
    24. rexpugh asks if TSDR will use the persistence project’s APIs, the response is yes they’re working with mark to consume those APIs (colindixon, 19:46:13)
    25. dbainbri notes that adding things like HBase drastically increases the difficult to deploy the controller as it adds more nodes and servers that need to be deployed (colindixon, 19:48:09)
    26. mohnish says that this has come up before and the goal is to package *something* that “works” out of the box, but can be scaled out to multiple hosts and process if need be (colindixon, 19:48:47)
    27. dbainbri, edwarnicke say that the TSC may want to figure out deployment models and how we keep things to be both easy to deploy quickly and run across multiple nodes (colindixon, 19:49:22)
    28. VOTE: Voted on "Shall the TSC approve the TSDR project to incubation?" Results are, +1: 11 (dfarrell07, 19:50:29)
    29. AGREED: TSC approves TSDR to Incubation (dfarrell07, 19:50:49)
    30. TSDR needs up update wiki with UIDs of committers (dfarrell07, 19:51:46)
    31. ACTION: mohnish needs to update TSDR wiki with UIDs of committers (dfarrell07, 19:52:32)

  7. using the TSC meeting as a cross-project coordination (colindixon, 19:53:13)
    1. colindixon notes that TSC calls often bubble up issues that are cross-project in nature. He asks "should a Project Lead be at least following the TSC list and reading the TSC minutes.. and hopefully that the Project Leads attend TSC meetings as often as possible" (colindixon, 19:53:19)
    2. ACTION: colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC (colindixon, 19:54:34)

  8. supporting the AD-SAL (colindixon, 19:54:47)
    1. rgowrishankar points out that we’re having lots of problems with supporting the AD-SAL in Helium (colindixon, 19:55:07)
    2. this seems to be causing a lot of confusion among ODL users (colindixon, 19:55:17)
    3. the question is (i) can we deprecate the AD-SAL and compatibility layer, (ii) if not who will maintain it, (iii) how do we convey the level of support (or lack thereof) to users (colindixon, 19:56:39)
    4. colindixon asks edwarnicke if the AD-SAL is going to be deprecated in Lithium (colindixon, 19:58:32)
    5. edwarnicke responds saying nobody is maintaining the AD-SAL and hasn’t been for a while, he fixed bugs at the end of Helium, but doesn’t want to keep doing things (colindixon, 19:59:18)
    6. edwarnicke says personally he would like to deprecate (colindixon, 19:59:28)
    7. ACTION: rgowrishankar, edwarnicke will reach out to people using AD-SAL. They should either come up with a way to maintain it or move to MD-SAL. (dfarrell07, 20:01:11)


Meeting ended at 20:03:40 UTC (full logs).

Action items

  1. colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here
  2. edwarnicke and jan medved to work with phrobb to the mac certificate issue
  3. phrobb will help to clean up the non-projects from the wiki
  4. colindixon will try to explore the use categories which allow for easier curation of this
  5. phrobb to start an e-mail thread on when to do a when to do a face-to-face meeting, initial ideas is 4/14-4/15
  6. gzhao will find username of Duanjingzhu
  7. gzhao will fill in the Duan Jingzhu’s username
  8. mohnish will get the remaining User IDs for the project
  9. mohnish needs to update TSDR wiki with UIDs of committers
  10. colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC
  11. rgowrishankar, edwarnicke will reach out to people using AD-SAL. They should either come up with a way to maintain it or move to MD-SAL.


Action items, by person

  1. colindixon
    1. colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here
    2. colindixon will try to explore the use categories which allow for easier curation of this
    3. colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC
  2. edwarnicke
    1. colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here
    2. edwarnicke and jan medved to work with phrobb to the mac certificate issue
    3. rgowrishankar, edwarnicke will reach out to people using AD-SAL. They should either come up with a way to maintain it or move to MD-SAL.
  3. gzhao
    1. gzhao will find username of Duanjingzhu
    2. gzhao will fill in the Duan Jingzhu’s username
  4. mlemay
    1. colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here
  5. mohnish
    1. mohnish will get the remaining User IDs for the project
    2. mohnish needs to update TSDR wiki with UIDs of committers
  6. phrobb
    1. edwarnicke and jan medved to work with phrobb to the mac certificate issue
    2. phrobb will help to clean up the non-projects from the wiki
    3. phrobb to start an e-mail thread on when to do a when to do a face-to-face meeting, initial ideas is 4/14-4/15
  7. rgowrishankar
    1. rgowrishankar, edwarnicke will reach out to people using AD-SAL. They should either come up with a way to maintain it or move to MD-SAL.


People present (lines said)

  1. colindixon (142)
  2. dfarrell07 (71)
  3. mohnish (30)
  4. odl_meetbot (25)
  5. edwarnicke (18)
  6. tykeal (14)
  7. dlenrow (13)
  8. ChrisPriceAB (12)
  9. dbainbri (12)
  10. abhijitkumbhare (11)
  11. mlemay (9)
  12. phrobb (8)
  13. kwatsen (7)
  14. LuisGomez (6)
  15. rexpugh (6)
  16. RajeevK (6)
  17. rovarga (5)
  18. jmedved (5)
  19. regXboi (4)
  20. cdub (4)
  21. gzhao (4)
  22. alagalah (4)
  23. Youcef (3)
  24. rgowrishankar (1)


Generated by MeetBot 0.1.4.