16:03:51 <colindixon> #startmeeting nic weekly
16:03:51 <odl_meetbot> Meeting started Fri Feb 27 16:03:51 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:03:51 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:51 <odl_meetbot> The meeting name has been set to 'nic_weekly'
16:03:56 <colindixon> #topic agenda bashing
16:04:24 <colindixon> #info devond wants to cover the release plan
16:04:29 <dbainbri> do we need to #info attendance?
16:04:42 <colindixon> dbainbri: I don’t generally for times when it’s not importatn for quorum
16:05:00 <colindixon> there were three things?
16:05:06 <dbainbri> ACK
16:05:19 <colindixon> #info dlenrow may cover the SFC use case a bit
16:05:22 <colindixon> what was the third thing?
16:05:43 <devond> #1 "Discuss Release Plan"  #2 "Jonathan's Slides" #3 Dave's SFC
16:06:31 <colindixon> #info covering jonathan’s slides
16:07:14 <colindixon> #info dmentze  also wants to cover the sample code and YANG (devond says that this is likley part of the release plan)
16:07:19 <colindixon> #topic release plan deliverables
16:07:44 <colindixon> #info devond points out that the M3 deadline is 3/19 (~3 weeks) and isn’t getting any further away
16:08:06 <colindixon> #info we promised to deliver Feature Freeze, YANG Freeze, Use Case Freeze, HIgh Level Design
16:09:16 <colindixon> #info colindixon asks whether we seem to be converging on the YANG model or are we headed toward some collision when we need to actually pick a model?
16:09:34 <gzhao> ＃link https://lists.opendaylight.org/pipermail/release/2015-February/001493.html <--M3 template
16:09:41 <colindixon> #info devond says he’s seeing more converging than conflicts on the horizon
16:10:22 <colindixon> #link https://lists.opendaylight.org/pipermail/release/2015-February/001493.html gzhao points out that there is more to the M# release and this is the template
16:10:47 <dbainbri> To answer Colin's question, I think we have a path forward and it has been the correct approach to see if we can encode the known use cases using the proposed model.
16:11:56 <colindixon> #info dbainbri responds to colindixon by saying “I think we have a path forward and it has been the correct approach to see if we can encode the known use cases using the proposed model.”
16:12:10 <colindixon> #info the consensus seems to be that we’re moving in the right direction, but we just need to keep moving
16:12:19 <gzhao> #info dlenrow said as offset 2 project, if necessary we can ask TSC approve for API update after function freeze.
16:12:47 <colindixon> dlenrow: if you want to see logs so long, they’re here: https://meetings.opendaylight.org/opendaylight-nic/2015/nic_weekly/opendaylight-nic-nic_weekly.2015-02-27-16.03.log.txt
16:13:13 <colindixon> #info dlenrow asks if attendance here is declining because people aren’t interest or if we’re driving them away because we’re not listening
16:13:29 <colindixon> #action dlenrow to poll people to figure out if we’re losing people for bad reasons?
16:13:57 <dbainbri> #info Dave is baffled by the new fangled technology known as the scrollbar ;)
16:14:08 <colindixon> #topic API
16:14:42 <colindixon> #info dmentze says that we’re trying to work out the API and he asked for people get use cases in by 2/20 to be able to have some core set to evaluate the YANG/API
16:14:43 <dlenrow> dbainbri: Those GUI's will never catch on
16:15:07 <colindixon> #info dmentze wants to be clear that he really doesn’t want to freeze bringing new use cases, just get some key ones so we can talk
16:15:39 <colindixon> #info two people took the time to write REST invocations for the use cases to evaluate them
16:16:44 <colindixon> #info one came from Shaun and another came from Louis, they were targeting two different YANG models
16:17:16 <colindixon> #link https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases use cases on the wiki
16:17:33 <colindixon> anyone know where there REST invocations are so I can link to them?
16:20:17 <gzhao> is the yang model in the prototype available on git?
16:21:47 <colindixon> gzhao: not sure
16:23:12 <colindixon> #info Louis and dmentze talk back and forth about Louis’s use case with respect to looking at endpoint attributes and network attributes at the same time
16:23:22 <colindixon> #undo
16:23:22 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x189fa50>
16:23:41 <colindixon> #info Louis and dmentze talk back and forth about Louis’s use case with respect to looking at endpoint attributes and traffic attributes at the same time (also source and destination attributes)
16:24:25 <gzhao> is this the yang model for prototype?  https://git.opendaylight.org/gerrit/#/c/15687/1/use_cases/intent.yang
16:24:58 <colindixon> gzhao: it’s a good question, I think there are (at least) two different YANG files
16:25:50 <gzhao> colindixon: I think this is for the prototype,  need confirmed by dmentze
16:28:11 <colindixon> #info dlenrow asks if we’re still thinking we want endpoints to be very flexible, e.g., hosts vs. traffic prefixes vs. L4 flows, etc., and if that can move us away from traffic classification
16:28:35 <colindixon> #info colindixon says he’s pretty sure we’re all in agreement that we want endpoints to be more flexible than just hosts
16:30:08 <dbainbri> It seems to me that in wireshark there is a good example of selecting "network" things. I am a fan of leveraging things that exist and are proven in nature. we could then extend that to meet our other needs such as label (tag) searching and mapping of service names to ports and protocols.
16:30:24 <colindixon> #info colindixon says there is some debate if this means we don’t need traffic classification in addition to endpoint details, e.g., trapping all DNS traffic is harder to express using just endpoints than you might like
16:30:50 <dbainbri> as was stated i don't think this invalidates the proposed yang models, it is just a syntax to express the query
16:32:11 <dlenrow> #info we need to be extremely carefull about building our NBI based on anticipating the implementation. When the primary goal is ease of use, and we know theres a risk of making this too complicated to consume, we don't want to pollute the user experience with implementation driven detail. The whole point of intent is to not pollute the user experience with
16:32:11 <dlenrow> implementation
16:33:02 <colindixon> #link https://lists.opendaylight.org/pipermail/nic-dev/2015-February/000293.html the mailing list thread on DNS and how it can/can’t map to purely EPG-based things
16:33:17 <dlenrow> #there are many examples of intent approaches that are not consumable because engineers spent too much time anticipating implementation details
16:33:37 <dbainbri> #info It seems to me that in wireshark there is a good example of selecting "network" things. I am a fan of leveraging things that exist and are proven in nature. we could then extend that to meet our other needs such as label (tag) searching and mapping of service names to ports and protocols.
16:34:18 <colindixon> #action everyone should look over the use cases on the wiki and figure out how they think about them, so we can look at it over the week
16:35:14 <colindixon> dbainbri: that’s a good point
16:35:37 <colindixon> dbainbri: also short ~1 line #info’s tend to work better in notes :-)
16:35:56 <dbainbri> colindixon: ACK
16:36:15 <colindixon> #info Helen and gzhao say that they’ve been trying to make endpoints work for carrier use cases and they have been having trouble
16:36:20 <dbainbri> #info we also need to keep in mind IPv6 and not just IPv4
16:36:34 <dbainbri> (not that we aren't already, just want to put that out there)
16:36:40 <colindixon> dbainbri: hence IP prefix without saying anything more
16:37:03 <colindixon> #info dmentze asks for Helen to document this and bring it to the mailing list and wiki this week so we can have a discussion
16:38:37 <dbainbri> colindixon: yep, understood.
16:39:35 <colindixon> if you want to see the full log since the meeting started it’s here: https://meetings.opendaylight.org/opendaylight-nic/2015/nic_weekly/opendaylight-nic-nic_weekly.2015-02-27-16.03.log.txt
16:40:20 <colindixon> #topic Jonathan’s slides (presentation from Inocybe/Mathieu)
16:40:42 <dbainbri> how the deal between ONF and Inocybe been struck?
16:40:45 <colindixon> #info the idea is to create an open intent runtime that runs across controllers
16:40:49 <dbainbri> s/how/has
16:41:20 <dbainbri> lol
16:42:19 <colindixon> #action jfokkan will post the slides after the call
16:42:58 * dbainbri gets even less polite, sorry
16:42:59 <colindixon> #info dbainbri asks if the deal between ONF and Inocybe has been finalized? dlenrow says not yet.
16:43:03 <colindixon> dbainbri: :p
16:43:46 <colindixon> #info the proposal (at least on the slides) shows an open intent engine that compiles down to both ONOS and ODL
16:44:35 <colindixon> #info dlenrow and dbainbri ask if this is still relevant given mlemay’s recent statements and the fact that the ODL intent project seems very hesitant to take code from from external sources and more amenable to taking models
16:45:24 <colindixon> #Info there’s a timeline with a Proof of Concept being delivered by June
16:46:06 <colindixon> #Info dmentze asks about when the infomodel is coming since he doesn’t even see it in the slides
16:46:18 <dbainbri> dlenrow: offline translation tool from what to what?
16:46:37 <colindixon> #info the answer is that the “runtime” on the slides is actually an offline translation tool from a common infomodel to controller-specific infomodels
16:46:52 <colindixon> dlenrow and jfokkan is that right to answer dbainbri’s quesiton?
16:47:11 <dlenrow> dbainbri: i assume UML to YANG
16:48:20 <colindixon> #info dbainbri if ODL has an intent model of it’s own, what’s the value proposition of deploying, testing, scaling, etc. a separate intent model layer
16:48:37 <colindixon> #info response is that the goal (as dbainbri suggested) is really just a standard model
16:49:15 <colindixon> #info dlenrow says ONF does infomodeling in UML and that’s what the ONF standard interface is likely to be while ODL does infomodeling in YANG
16:49:22 * dbainbri worries about the added performance hit, deployment complexity, etc of another layer for a standard API
16:49:31 <colindixon> dbainbri: +1
16:50:05 * colindixon realizes his skills at being in a WebEx and on IRC and taking notes at the same time have developed a lot in the last 1-2 years
16:50:30 <LouisF> colindixon: good work
16:50:46 <colindixon> #info dlenrow, dmentze, and dbainbri seem somewhat skeptical of this approach if it’s anything more complicated than a basic translator from ONF UML operations to ODL YANG/RESTCONF operations
16:50:50 * gzhao saw colindixon even sent email on top of webex and irc
16:51:09 <colindixon> hypertasking
16:51:16 <gzhao> :)
16:51:32 <dbainbri> colindixon: well your no Shaun, but very close ;) thanks for doing the notes
16:52:09 <colindixon> #info it sounds like there’s really cool stuff going on, but the exact details seem to be in flux
16:52:24 <colindixon> #topic intent prototype
16:52:52 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/15629/ the prototype git
16:55:07 <colindixon> #info colindixon asks if we can break down the patch into smaller chunks that are more understandable
16:55:22 <colindixon> #info people ask for a deep dive that is remote-friendly
16:55:43 * dbainbri reminds colindixon that grok is now a trademarked term (http://numenta.com/grok/)
16:55:48 <colindixon> #action devond and dmentze will set up that meeting, likely not for next week, but for the next week
16:56:21 * dbainbri questions if roseville is really in the valley ;)
16:56:40 <colindixon> dbainbri: can they do that with a common word from a book? doesn’t Heinlein own it?
16:56:59 <colindixon> dbainbri: it’s in *a* valley
16:57:05 <dbainbri> colindixon: don't know, not a lawyer
16:57:10 <tbachman> Heinlein owns Roseville?
16:57:14 <dbainbri> :)
16:57:21 <devond> Just don't use any word L Ron Hubbard ever wrote
16:57:41 <colindixon> #info dmentze asks if people have opinions on whether this is just a good example or if it’s good code to accelerate Li development
16:58:12 <colindixon> devond: :-)
16:58:13 * dbainbri will be out of country (Haiti) from March 13 to 28, not that this matters.
16:58:17 <dlenrow> I'm assuming if I have to fly from boston the roseville crowd has to drive to the valley. HP does have a few facilities there :)
16:58:32 <devond> Roseville is just like the valley, back when it was affordable
16:59:06 <devond> Yes, driving to the valley is doable for us
16:59:39 <dbainbri> numenta has some interesting ideas, some of the work based on a really good book (opin) http://www.onintelligence.com/
16:59:54 <dlenrow> Not a ton of flights to sacramento, although I don't mind being an hour from tahoe when the meetings end
16:59:59 <colindixon> #info colindixon asks if we can do a deep dive next week to make sure we can get something started if we think we might want to use the code for some of our M3 deliverables
17:00:38 <dbainbri> www.google.com/flights
17:00:45 <dlenrow> I have the code memorized, NOT!
17:01:36 <colindixon> #action dmentze and devond to schedule a deep dive for next week
17:01:40 <colindixon> #action everyone to work hard on the API
17:01:44 <colindixon> #endmeeting