#opendaylight-nic: nic_weekly

Meeting summary

1. roll call (gzhao, 16:02:22)
   1. duane (dmentze, 16:03:30)
   2. gzhao (gzhao, 16:04:00)
   3. dbainbri (dbainbri, 16:05:11)
   
   
2. Model discussions (gzhao, 16:09:32)
   1. right now there three models proposed in NIC, Shuan/Duane, Luis/Cathy and George (gzhao, 16:10:15)
   2. meeting conflict with neutron caused no recording for nic (gzhao, 16:16:01)
   3. https://wiki.opendaylight.org/view/Network_Intent_Composition:Composite_Endpoint the wiki page which Louis is presenting on Composite Endpoints (colindixon, 16:18:32)
   4. to be clear, we’re unsure if there’s a conflict, but if there is and we try to claim the host code when there is a conflict, we’ll be kicked out and everyone will have to rejoin (colindixon, 16:18:53)
   5. LouisF says multiple tags and values can be attached to endpoint (gzhao, 16:20:06)
   6. dmentze asks questions about the relationship of descriptors, tags, and attributes (colindixon, 16:20:58)
   7. dmentze says there dosn’t appare to be an endpoint database, but where the is the database? (colindixon, 16:22:23)
   8. different approach: move infected to a different EPG. don't apply attributes to EPs.Apply them only to EPGs and relationships between EPGs. (dlenrow, 16:22:44)
   9. dmentze says it looks like there are no endpoints, there are only descriptors (which I think are expressions across traffic flows) (colindixon, 16:23:20)
   10. ACTION: dmentze is going to send email to furthur discuss his question for composite endpoints (gzhao, 16:28:03)
   11. colindixon asks are we converging or diverging (gzhao, 16:29:39)
   12. colindixon notes that this model (coposite endpoints) focuses a lot on endpoint definition and endpoint group definition, which was explicity made orthogonal to dbainbri’s original model (colindixon, 16:33:05)
   13. colindixon notes that this might make them easy to merge, that is this model offers ways to define endpoints and groups in some detail, while the action/policy/operation bit about how to treat traffic between endpoint groups seems much more similar (colindixon, 16:34:34)
   14. Cathy asks would the term operation be the right term for the thing that happens to traffic between two endpoints (colindixon, 16:36:57)
   15. colindixon says disjoint path is more like property than operation. (colindixon, 16:37:04)
   16. dmentze asks if use name operation or constrains (colindixon, 16:37:11)
   17. colindixon notes that he’s not saying he’ll block the model (if people like it) for the name, but it doesn’t quite fit the set of things that we’d actually do (colindixon, 16:37:53)
   18. dmentze suggests to have model decided first. (gzhao, 16:39:23)
   19. colindixon and dlenrow note that they’d rather not spend time trying to come up with a name on confernce call with lots of people on it (colindixon, 16:39:24)
   
   
3. Nemo Model (colindixon, 16:40:32)
   1. https://wiki.opendaylight.org/view/File:Nemo_object_model.jpg the diagram being talked about (colindixon, 16:42:18)
   2. gzhao says that this is actually very similar to Cathy’s model (colindixon, 16:43:00)
   3. a connection is a path through the network without source or destinations, the actual physical path (colindixon, 16:43:35)
   4. a flow an established flow of data with source and destinations (colindixon, 16:44:02)
   5. gzhao notes that Nemo has an IETF proposed standard, it’s also been proposed in OPNFV, ONF, and likely will be an ODL project soon (colindixon, 16:44:36)
   6. Louis says that the flow is very similar to a classifier in dmentze’s previous model (colindixon, 16:45:19)
   7. central to other intent models is the idea that intent is about relationships between EPGs. end-points, connections, flows, are not intent, they are implementation detail. (dlenrow, 16:45:46)
   8. gzhao notes that the *only* difference is the new addition of connections and flows (colindixon, 16:46:08)
   9. Cathy points out that they need to have some access to lower-level details than just endpoints and they want access to them (colindixon, 16:50:03)
   10. colindixon says that in general, when you have a higher-level asbtraction that is too complex and you want more details, you do that by providing the more details below in a lower layer (colindixon, 16:50:32)
   11. pairwise relationships between singletons are not interesting at scale. It's about EPGs and relationships between large numbers of entities with similar behaviors (dlenrow, 16:50:38)
   12. colindixon says in this case it looks like conections (basically path level stuff) would be a good candidate for how to provide some specific constraint/policy/operation, rather than being another abstraction on the same level with endpoint groups (colindixon, 16:51:32)
   13. colindixon goes on to say that the flow sounds like it might actually be better provided as a way to define endpoints that then are collected into endpoint groups (colindixon, 16:52:02)
   14. colindixon says that he thinks a lot of disagreement is talking at different layers (colindixon, 16:54:24)
   15. colindixon says that, unfortunately, this might make things harder rather than easier because now we need models at multiple levels (colindixon, 16:54:53)
   16. it might help the discussion at least to bin objections to models into 3 bins: “this model is too high-level, I can’t speicfy things I care about in the detail I care about”, “this model is too low-level, I have to jump through hoops to translate what I want to do into it” and “at the level of this model, we could do this in a different/better way" (colindixon, 16:56:58)
   17. dlenrow notes that he thinks intent is an overlay and is completely virtual. disjoint path, and flow processing is part of the mapping required before intent is overlayed, but it is not part of intent. If four-nines should map to disjoint path, that gets mapped in pre-intent configuration. The one and only intent NBI offered is the "four-nines" constraint (colindixon, 16:57:14)
   
   
4. changes to shaun’s and dmentze’s model (colindixon, 16:58:23)
   1. https://wiki.opendaylight.org/view/File:Nic_usecase_5_LyncCallQoS.txt the text file that dmentze is talking to (colindixon, 16:59:33)
   2. dmentze talks about endpoint attributes and traffic attributes and why he thinks they’re very important (colindixon, 17:00:13)
   3. Louis says he still doesn’t why you need to specify the different attributes need to be split (colindixon, 17:00:57)
   4. IMO to much emphasis on classifier looking stuff. Intent model and verbs need progress. Need to abstract end-points away and get on with it. (dlenrow, 17:03:47)
   5. dmentze says its because in many controllers we will know things about endpoints at run time and the traffic attributes are things you might not know (or at least that was my understanding) (colindixon, 17:04:12)

Action items

1. dmentze is going to send email to furthur discuss his question for composite endpoints

Action items, by person

1. dmentze
   1. dmentze is going to send email to furthur discuss his question for composite endpoints

People present (lines said)

1. colindixon (42)
2. gzhao (18)
3. dlenrow (9)
4. odl_meetbot (8)
5. dbainbri (6)
6. tbachman (4)
7. LouisF (3)
8. helenchen (1)
9. dmentze (1)