21:11:42 <dbainbri> #startmeeting ONF NBI Session 2
21:11:42 <odl_meetbot> Meeting started Thu Feb 12 21:11:42 2015 UTC.  The chair is dbainbri. Information about MeetBot at http://ci.openstack.org/meetbot.html.
21:11:42 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:11:42 <odl_meetbot> The meeting name has been set to 'onf_nbi_session_2'
21:19:34 <dbainbri> #info is a service function (SF) an EP in terms of the intent interface? What about a service chain?
21:23:54 <dbainbri> #info (david commentary, and if a SF is just a new EP inserted in between two other EPs, does this mean that we need to consider that an intent isn't a src and dest EPG, but a chain for EPGs ?)
21:29:37 <dbainbri> #info ONFs implementation plan is to provide shared (core) intent code in the ONF GIT repo and then have that leveraged in an ONOS and ODL implementation
21:31:35 <dbainbri> #info ONF is funding INOCYBE to implement the core aspects of intent in ONF
21:32:14 * dbainbri wonders how this meshes with the current work underway and in the NIC project
21:36:24 <ShaunWackerly1> This seems very problematic, for ONF to be expecting to develop code that NIC will use, outside of a NIC audience ...
21:39:02 * dbainbri nods
21:42:53 <dbainbri> #info an end point registry is required and is shared state across all controllers (across domains)
21:45:26 <dbainbri> #info also need a "registry" of domain interconnects
21:49:17 <dbainbri> #info DaveL talking about a providing the intent engine a pool of resources (SF instances) and the controller picks an instance to build a SFC
21:50:16 <dbainbri> #info DavidB asks, if SF are EP, why not just use standard EP resolution as opposed to introduce a standard "resource pool concept"?
21:52:11 * dbainbri wonders what it means when the guy beside me at the NBI meeting has fallen to sleep
21:56:33 <ShaunWackerly1> dbainbri: A service function (SF) will be different than an endpoint (EP), because a SF may occur on its way to the EP. The SF doesn't necessarily replace the EP as the destination of the traffic. For that reason, the intent must express both the EP and the SF that traffic will traverse on its way to the EP.
21:58:49 <dbainbri> ShaunWackerly1: agree, the question is can we treat a SF as just another EP, so intent EP1 to EP2 becomes EP1 to EP3 to EP2, where EP3 == SF1
21:59:17 <dbainbri> then, from the intent perspective it is just connecting up a series of EPs
22:00:23 <ShaunWackerly1> dbainbri: I think intent needs to know the difference between an EP and SF because traffic to a SF gets tunnelled/encapsulated, and traffic to an EP does not.
22:01:24 <dbainbri> ShaunWackerly1: can you expand on that please. not sure why this might not be true for any EP
22:02:36 <dbainbri> one concern about treating SF as "something different" is that there is now a precedence (i.e. something that doesn't fit the general model), and this opens the door for other things as well and soon we can end up with multiple special cases
22:03:43 <ShaunWackerly1> dbainbri: I thought that an SFC presentation last week showed that a packet destined for a SF gets sent to a tunnel (or something like it), where it's encapsulated with a header which denotes the service chain that it's traversing.
22:05:19 <ShaunWackerly1> I think that a service implementation would be an endpoint, but the service function and chain aspect needs to be identified somewhere outside of the endpoint.
22:05:25 <dbainbri> ShaunWackerly1: i don't recall, but i suspect that it is possible that this same pattern may be valid (encapsulation) outside of SFC as well. So i would rather see a common pattern even in this case that can also be used for SFC.
22:07:03 <dbainbri> ShaunWackerly1: i would agree that the chain is identified outside of intent and EP, but wondering if that can just be surfaced to the intent processing and the controller as an EP because the intent and controller doesn't really care that it is a SFC, just that it has to include it in a network path.
22:07:21 <ShaunWackerly1> I think that a SF would just be referenced via a tag/attribute/label as the destination of a given policy/operation. For instance, the application would specify a src/dstEPG, classifier/filter (if the team decides that's what we want), and then a policy like this:
22:07:21 <ShaunWackerly1> policy = "inspect via DNSInspector"
22:07:53 <ShaunWackerly1> and then our intent engine would translate DNSInspector to a SFF (service function forwarder) and SFI (service function instance)
22:08:22 <ShaunWackerly1> I think Duane will have some input on this, he's done more work than I have in SFC
22:08:27 <ShaunWackerly1> Let me get him to join on the chat and explain
22:09:22 <dbainbri> in recursive processing of the intent, the src, dest, + policy (insert DNSInspector) turns into ep1 (src) to ep2 (dns inspector) to ep3 (dest) and then this gets processed as a series of "allow" policies
22:10:02 * dbainbri nods on bringing Duane in
22:10:57 <ShaunWackerly1> I think he might be able to join, I am emailing the conversation history to bring him up to speed. I don't think it shows up when you newly join.
22:11:53 <dbainbri> dmentze: welcome
22:14:35 <dmentze> howdy
22:15:08 <ShaunWackerly1> dbainbri: how do you make IRC use the "*** dbainbri ..." notation when marking an action?
22:15:56 * dbainbri like this?
22:16:02 <ShaunWackerly1> yes
22:16:07 <dmentze> i read the history on the shaun/david discussion
22:16:14 <dbainbri> prefix the statement with "/me"
22:16:18 <ShaunWackerly1> ah, thanks!
22:16:20 <dmentze> nic has not really had a good long discussion on SFC yet
22:16:52 <dbainbri> conversation was initiated by DaveL presenting at the ONF NBI meeting today
22:17:45 <dmentze> ok - as this is a complex topic it will may take a while to get each others perspectives…
22:18:19 <ShaunWackerly1> dmentze: would this be better to work through with use cases?
22:18:44 <dmentze> i agree the  SF are EPs.  However the fact that they can provide a SF makes them special.
22:19:30 <dmentze> For EPs so far we have identified dynamic attributes (consisting of ID info ip/mac, static info <like group memberships>, and dynamic attributes <e.g. infected>)
22:20:36 <dmentze> I suspect the SF is very similar to attributes.  We just need to figure out what all the info is that is needed to represent them as a SF.   Then, does it lend itself to simply be an attribute.
22:20:58 <dmentze> SF aspects include forwarding types (tunnel, of raw) as well as interfaces for establishing SF health.
22:21:04 <ShaunWackerly1> dmentze: I think that dbainbri was concerned that if we treat SF specially, then that sets a precedent that "special" things need a change to the NIC API. Are you saying that we would treat SF as a special EP, or that the attributes/labels which reference them would be special?
22:21:09 <dmentze> Also SF loading
22:21:49 <dbainbri> loading of SF is a different issues and not handled by the intent engine, that is a SF manager
22:22:09 <dmentze> I agree.  So figuring out what is SF manager and what is Intent is key.
22:22:14 <dbainbri> so just expose SFs as EPs in the intent framework and allow the framework to query 1 of N based on a tag
22:23:20 <dmentze> The PE can treat non SF tags fairly generically.  However SF tags (in my thinking) semantically occur in a different place than non SF tags.
22:23:29 <dbainbri> and the SFM (manager) can surfaces SFs into the controller as a keyed (1 of N) query and receive notification when an EP is used (as the intent may do for all EPs) and then the SF can create / delete / etc instances as it sees fit based on utilization notifications
22:23:44 <dmentze> Also what the PE has to do wtih SF tags is different than the non SF tags - at least in my thinking.
22:23:58 <dbainbri> PE?
22:24:03 <dmentze> SF tags are realized into dynamic service chain requests, and the others are not.
22:24:10 <dmentze> PE = policy engine
22:25:21 <dbainbri> i am assuming that the PE looks up a SF (that already exists and was surfaces into the controller by the SFM) and to be fair the lookup function could just as easily go call something else to instantiate a new instance
22:25:32 <dbainbri> PE->query 1 of N from tag FOO
22:26:27 <dbainbri> query handler (and their could be different handlers) one could just return one of an existing pool another could spin up a VM etc
22:26:47 <dbainbri> (PE = policy engine … duh, multi-plexing error)
22:26:54 <dmentze> kind of.  I was thinking the PE simply 'assumes' a SF instance exists and creates a 'requested chain'.  The SFM then does the calcs to create a chain instance to realize the request and passes it back to the PE.
22:28:06 <dmentze> So if a few policies have requests SF1 and SF2 for the same region of endpoints/traffic, the PE would decide the order needed:  SF1, SF2.  Request a chain.  the SFM (service function manager) creates it.
22:28:07 <dbainbri> agree, from the PE's perspective the SF is simply returned from a query, so it essentially assumes it exists. but how it is brought into existence can vary
22:28:09 <dmentze> PE then uses it.
22:29:59 <dbainbri> I am starting to view that the PE gets EP1 to EP2 if the policy determines that SF1 and SF2 must be inserted then the PE generates a new chain of EPs (EP1 to EP1.1 (SF1) to EP1.2 (SF2) to EP2)
22:31:03 <dbainbri> to get EPs which represent SF instances the PE essentially invokes the same lookup function to resolve any EP and that may return a referenced to a pooled SF instance or trigger the SFM to create a new instance and return that
22:31:44 <dbainbri> but it separates the PE logic from how or where EPs are resolved as well as from the concept of SF (because everything is just an EP)
22:31:59 <dbainbri> and gives a pattern for inserting other things in intents beyond SFs
22:36:23 * dbainbri notes his note taking has suffered as he started to engage in the SF discussion ;)
22:37:03 <ShaunWackerly1> haha
22:37:17 <ShaunWackerly1> I was wondering if the ONF meeting had gone on break
22:38:07 * dbainbri also wonders if it is time for a f2f NIC meeting to iron some of this stuff out in person on a white board
22:39:18 <dmentze> i agree a f2f soon would be good
22:39:29 <dmentze> maybe we can discuss at friday's meeting
22:40:00 * ShaunWackerly1 will bring an ironing board and some starch.
22:40:15 <dmentze> :)
22:41:51 <dmentze> it would be nice to also get some time w/ the SFC guys…maybe after we synch
22:50:50 <dbainbri> #info there is a NBI sub group about service APIs
22:51:44 <dbainbri> #info (david commentary: really unclear what the purpose is or what a service API subgroup is for if we are going down an intent API model. no value in an L3 VPN API model)
22:51:55 <dmentze> Also, given that the ODL GBP guys are meeting w/ the ODL SFC, NIC probably needs to get is SFC ideas together and meet with the ODL SFC guys
22:52:43 <dbainbri> might be worth to meet as one big happy GBP/NIC family with SFC so that we are all hearing the same thing and have a common understanding.
22:54:45 <dmentze> I would lean towards the ODL-SFC team taking requirements from various projects (NIC, GBP).  Let them handle their interfaces.   Otherwise we could get derailed into comparing GBP/NIC.
22:56:55 <dmentze> I think it is likely NIC has different SFC requirements, as it is likely that it is handling SF conflict detection and SF - Chain composition.  This something I have not seen anyone else yet tackle.
22:57:02 <dbainbri> i would have thought NIC and GBP take requirements from SFC. i agree we don't want to get into a comparison between GBP/NIC, i would really much rather see GBP and NIC merge. Just remember the pain coming into ODL when there were two SALs, fear we are reliving that with GBP and NIC
23:00:33 <dbainbri> #info the NBI modeling group is developing API models for things like inventory and topology
23:01:09 <dbainbri> #info NBI modeling group is a ONF subgroup of the NBI group, formally known as NBI framework and architecture
23:01:12 <dmentze> possibly.  But the NIC project proposal had clear distinctions from GBP and so for now it would be nice to be able to drive on them - a community driven solution, which solves the multi write problem, is simple to use, takes into account stds bodies efforts on api.
23:01:35 <ShaunWackerly1> dbainbri: I'm a little confused as to what you'd mean by NIC and GBP taking requirements from SFC, since a few lines up you said that SFC would be "taking requirements from various projects (NIC, GBP)" ...
23:01:51 * ShaunWackerly1 will be back in a bit ...
23:02:00 <dbainbri> but it both NIC and GBP talk directly to the NEs (nodes), multi writer problem not solved.
23:02:29 <dbainbri> and I don't think there is agreement that either GBP will translate to NIC or NIC to GBP, so we are in the two writer situation still
23:03:54 <dbainbri> ShaunWackerly1: I believe dmentze stated that SFC would take requirements from NIC/GBP. I am suggesting the reverse is true. In reality it is likely a negotiation between SFC and (GBP/NIC)
23:04:19 <dbainbri> If it typed that SFC takes requirements from GBP/NIC then I mis-typed ;)
23:04:24 <dmentze> If apps talk Intent to NIC, then NIC solves the multi-app writer problem.  If apps talk to both NIC and GBP I would wonder why?
23:04:57 <dbainbri> one app may not talk to both, but APP1 might talk to GBP and APP2 might talk to NIC and …. boom
23:05:19 <dmentze> That is why we need the Intent API to be sufficient for both apps1 and app2.
23:05:49 <dmentze> yes - may be  a bit opptmistic.....
23:05:54 <dbainbri> but we can't force any given app to use NIC and right now apps have two choices and they have to decide
23:06:04 <dbainbri> it is AD-SAL/MD-SAL all over again.
23:06:36 <dbainbri> right now MD-SAL one, but ODL developers users are now in a place where they have to pick a horse, which makes ODL adoption difficult.
23:07:11 <dbainbri> i get the 1000s flowers issue, but there is also an adoption and productization issue. and if a customers wants APP1 and APP2 and they selected different horses, life is not fun.
23:07:37 <dbainbri> which is why I would like to see GBP and NIC evolve into a best of both seeing as they really are attempting to solve the same problem.
23:07:57 * dbainbri feels like we may have jumped into philosophy
23:08:01 <dmentze> I don't think GBP tried a community effort - or am I mistaken?
23:08:29 <dmentze> I thought there was quite a bit of 'unilateral' decision making.
23:08:39 <dbainbri> doesn't matter. what i mean is, it exists, doesn't matter how it came to exist.
23:08:51 <dbainbri> and as a ODL developer i have to choose
23:08:52 <dmentze> So why did you join NIC?
23:09:48 <dbainbri> because Ciena as a company is interested in developing an intent capability on ODL (and other controllers). but as part of that effort we (I) also see value in working towards bringing these projects together.
23:10:06 <dbainbri> interesting ( i ) translates to (I)
23:11:24 <dbainbri> because I suspect Ciena customers will utilize multiple APPS from multiple vendors and if they can't play together that is bad for Ciena customers.
23:11:33 <dbainbri> (and even for customers that are not yet ours ;))
23:12:31 <dmentze> I can see advocating them coming together - but is the goal of being PTL to advance NIC or to advance the idea of not having 2 projects?
23:13:02 <dbainbri> i view the goal of PTL as pushing for the best solution for ODL and all the apps sitting on top of ODL.
23:13:22 <dbainbri> I think we learn from GPB and NIC efforts and push for the best solution.
23:13:53 <dmentze> The idea of NIC is to get the community to create a best in class intent system for everyone, not just a single vendor.  It seems cienna would be very excited about that.
23:13:53 <dbainbri> the goal is to have a solution that APPS can interoperate and co-habitat
23:15:49 <dbainbri> We are, but "best in class intent system for everyone" means those currently involved in GBP as well or leveraging GBP today. I understand that there seems to have been some past issues around GBP and others. But, we need to figure how to move ODL forward. and not solving the multi-writer problem doesn't do that. so we have to consider the issue.
23:17:18 <dmentze> I generally agree.  For now I view the multi-writer problem more of a 'multi-app' writer problem.  If we can get any api (NIC or GBP) to solve that it will be progress.  Later solving the multi-api problem probably will not be as difficult.
23:19:00 <dbainbri> Solving the issue where any given app speaks multiple "intent" APIs is easy in that I suspect an APP developer will choose and API (GBP or NIC) and use it. We have seen the multi-app problem already in ODL in that in both releases of ODL not all apps are compatible with each other.
23:19:40 <dbainbri> #info sess that ice cream is being served, ah the joys of technical conferences
23:19:44 <dbainbri> #endmeeting