15:11:24 <alagalah> #startmeeting FriApr25 MODEL - Mickey's notes
15:11:24 <odl_meetbot> Meeting started Sat Apr 26 15:11:24 2014 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:11:24 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:11:24 <odl_meetbot> The meeting name has been set to 'friapr25_model___mickey_s_notes'
15:11:37 <alagalah> #topic Consumers, Providers, formula
15:11:37 <alagalah> #info Mike notes once you xxx contract, set of clauses
15:11:41 <alagalah> #info These consumer rules, under the conditions, can talk to these provider capabilities, under these conditions
15:11:41 <alagalah> #info That maps you into a set of subjects that are within scope
15:11:42 <alagalah> #info This way we can say consumers have roles
15:11:44 <alagalah> #info Providers have capabilities
15:11:46 <alagalah> #info We can change the names, think about them as properties that indicate something
15:11:50 <alagalah> #info You have providers, capabilities, and conditions
15:11:51 <alagalah> #info Consumers have roles and conditions
15:11:52 <alagalah> #info Whenever consumers have certain roles, certain conditions, providers have certain capabilities, conditions, they can talk to each other, results in certain subjects being in scope
15:11:54 <alagalah> #info Mickey notes only one endpoint group per endpoint
15:11:57 <alagalah> #info But that endpoint group can have many capabilities and roles
15:11:58 <alagalah> #info Mike clarifies there can be many, not restricted to one
15:12:02 <alagalah> #info Ryan asks to explain symbology
15:12:03 <alagalah> #info Understand F is some sort of match or formula, might be different for consumers and providers
15:12:05 <alagalah> #info Mike explains we have consumer roles that can be fed into a formula
15:12:06 <alagalah> #info Ryan’s first stupid question
15:12:08 <alagalah> #info Mathematically speaking, if you use the same capital F, you mean they are the same formula
15:12:10 <alagalah> #info Mike does not mean that
15:12:12 <alagalah> #info Some sort of formula at each point, not the same
15:12:14 <alagalah> #info Daljeet asks if roles are published by providers?
15:12:17 <alagalah> #info Mike notes provider has capabilities, consumer has roles
15:12:18 <alagalah> #info They meet together in the contract
15:12:21 <alagalah> #info Have different formulas, match on roles, can specify ANDs, ORs, XORs
15:12:22 <alagalah> #info Have access to provider capabilities under these conditions
15:12:24 <alagalah> #info When met, these subjects are in scope
15:12:27 <alagalah> #info This set of roles under these conditions, logical multiplier, modulate
15:12:28 <alagalah> #info Change “F” to “F1”, “F2”, “F3”, not the same function
15:12:31 <alagalah> #info Mike notes meant to communicate an idea, not meant to be mathematically sound
15:12:32 <alagalah> #info What it means, for these roles under these conditions, however you combine those things, you can talk to providers under those conditions
15:12:34 <alagalah> #info You map to a set of subjects on which you can communicate
15:12:36 <alagalah> #info Ryan would love to have a concrete example
15:12:38 <alagalah> #info Not today, but thinking there will be a whole lot of folks who look at this, go WTF
15:12:40 <alagalah> #info Concrete example would help
15:12:43 <alagalah> #info Rob suggests adding onto the end, a network
15:12:45 <alagalah> #info That is what it looks like in UML, trying to express
15:12:46 <alagalah> #info Role matchers can match themselves, allows for nested formulas
15:12:48 <alagalah> #info Keith shows nested inheritance
15:12:50 <alagalah> #info Rob notes it is a matcher, implemented the way matchers are implemented
15:12:52 <alagalah> #info Basically have a group
15:12:55 <alagalah> #info Through relator, normal selector or names
15:12:57 <alagalah> #info Select contract
15:12:58 <alagalah> #info Then you have clauses, based on roles and conditions, this is how you can talk to capabilities under certain conditions
15:13:00 <alagalah> #info Roles, conditions, capabilities, if want to rename them, propose names
15:13:02 <alagalah> #info Does not matter what they are
15:13:09 <alagalah> #info Just felt like these names made sense
15:13:09 <alagalah> #info Mickey is not thrilled about capability, have to think of something to change to
15:13:09 <alagalah> #info Rob usually associates a role with a user
15:13:11 <alagalah> #info Mike cannot find words that are vague enough, not used today
15:13:13 <alagalah> #info Tried to use requirement before, people did not like it
15:13:15 <alagalah> #info Rob prefers requirement to role
15:13:17 <alagalah> #action Keith to create plain English definitions of each “noun”
15:13:18 <alagalah> #info Definition of concepts, then show how concepts worked together
15:13:20 <alagalah> #info Rob asks if this is something that can be understood by normal human users?
15:13:22 <alagalah> #info Or something you have to be a programmer to understand?
15:13:26 <alagalah> #info Mike ran it by people who do firewalls, enterprise applications
15:13:27 <alagalah> #info They can understand it
15:13:29 <alagalah> #info We can reduce it to English grammar
15:13:31 <alagalah> #info Just a formal UML diagram
15:13:32 <alagalah> #info Translating to word grammar
15:13:34 <alagalah> #info For example group name has selector that points to this thing
15:13:38 <alagalah> #info Then within this thing there is a contract, rule, for these roles under these conditions talk to the capabilities under those conditions
15:13:38 <alagalah> #info Jan asks why not take to Yang directly?
15:13:41 <alagalah> #info Mike wants to agree on concepts first
15:13:42 <alagalah> #info At a given time, object only contained by one, either relator or the group
15:13:44 <alagalah> #info Some requirements can be defined at group level, some at relator level
15:13:48 <alagalah> #info If define at relator level, specified in context of relationship with a given contract
15:13:48 <alagalah> #info Jan asks, configure role and condition directly?
15:13:51 <alagalah> #info Mike notes scope to which it applies
15:13:53 <alagalah> #info If role under selector, only evaluated in contracts that this selector refers to
15:13:54 <alagalah> #info If put in group, applies to all contracts
15:13:57 <alagalah> #info Certain roles you have in life regardless of your current function
15:13:59 <alagalah> #info Special roles when poor, at home, when you visit your grandmother
15:14:01 <alagalah> #info Work is your contract, expressed through relator
15:14:03 <alagalah> #info Certain roles defined within context of that relationship
15:14:04 <alagalah> #info Those roles do not apply to you when you are at home
15:14:07 <alagalah> #info Jan notes one kind of uber selector, where roles and conditions apply by default
15:14:08 <alagalah> #info Mike notes you do, under the group
15:14:10 <alagalah> #info Mike notes certain roles are universal regardless of where you are
15:14:12 <alagalah> #info Jan asks why clause and subject both?
15:14:14 <alagalah> #info Mike notes only clause under contract
15:14:17 <alagalah> #info Mickey notes clause is choosing a subject
15:14:19 <alagalah> #info Consumers under these conditions can talk to the provider capabilities under these conditions, on these subjects
15:14:20 <alagalah> #info Can you have subject without clause?
15:14:22 <alagalah> #info Mike notes subject is contained, within contract
15:14:24 <alagalah> #info Clause is who can talk to whom on what subject
15:14:26 <alagalah> #info Jan asks why clause not contained in a subject?
15:14:28 <alagalah> #info Mike notes clause can map to 20 subjects, a tree
15:14:31 <alagalah> #info Keith notes sigma symbol
15:14:32 <alagalah> #info Mickey asks about condition again?
15:14:34 <alagalah> #info Mike notes can mark endpoint group, or endpoint, saying this one is insecure
15:14:37 <alagalah> #info Things meant to be more or less transient, think about them as modulators
15:14:38 <alagalah> #info For example, posture
15:14:41 <alagalah> #info Discussion of Affinity (not the project, the VM concept)
15:14:42 <alagalah> #info Mike notes not how we are reasoning about this
15:14:44 <alagalah> #info Put secure as a condition
15:14:46 <alagalah> #info Secure is allowed to talk to anybody on all of the subjects
15:14:48 <alagalah> #info Conditions can be on consumer or provider side, do not have to be the same conditions on either side
15:14:50 <alagalah> #info Don’t have to think about identifiers
15:14:52 <alagalah> #info Mike’s example
15:14:55 <alagalah> #info You can assign a score to an endpoint
15:14:56 <alagalah> #info Go to scorer table, that maps you into a condition, gets inherited
15:14:58 <alagalah> #info Relates how you enforce the policy
15:15:01 <alagalah> #info Circumstances, how connected, where you came from, whatever
15:15:03 <alagalah> #info Allows inheritance of conditions based on circumstances
15:15:04 <alagalah> #info Group can be put into a circumstance, or an endpoint can be put into a circumstance
15:15:06 <alagalah> #info When you come to Cisco building 7, connect through wireless, subjected to different set of rules, versus connected directly to Ethernet port
15:15:08 <alagalah> #info Under circumstance of being connected in Cisco building, through Ethernet port rather than wireless
15:15:12 <alagalah> #info Also circumstance, connected on your laptop versus iPad
15:15:12 <alagalah> #info Condition inheritance mechanism
15:15:16 <alagalah> #info Jan notes applying label to whole bunch of conditions
15:15:17 <alagalah> #info Asks if it is inheritance or grouping?
15:15:19 <alagalah> #info Mike claims both, can inherit a bunch of conditions
15:15:20 <alagalah> #info Circumstance can be a tree, at each level define conditions, when terminate at one of the leafs or nodes, inherit everything
15:15:22 <alagalah> #info Jan asks if conditions point to endpoints?
15:15:24 <alagalah> #info Mike notes endpoint ends up containing the condition, a string
15:15:31 <alagalah> #info In xxx, this computer is deemed evil
15:15:31 <alagalah> #info Say congress application from OpenStack makes call to Endpoint Registry, says mark this endpoint as insecure
15:15:31 <alagalah> #info You are under this circumstance, know which labels to inherit
15:15:32 <alagalah> #info Keith notes can force into contract where do IPS or IDS
15:15:34 <alagalah> #info Jan notes endpoints in registry independent of our policies, then reference them in our policies?
15:15:37 <alagalah> #info Mike counters, in our endpoint registry, you always know which group you belong to
15:15:38 <alagalah> #info How you get there, will not discuss here
15:15:41 <alagalah> #info Also know which xxx you are subjected to
15:15:42 <alagalah> #info Those conditions are used in determining what rules apply to you, who can talk to you, and how
15:15:45 <alagalah> #info Keith notes previously in formula, consumer modulated by conditions, determined which providers it can talk to, modulated by its conditions, …
15:15:46 <alagalah> #info Can circumstances modulate the conditions?
15:15:49 <alagalah> #info Mike notes if endpoint assigned to a circumstance, you inherit a bunch of conditions
15:15:51 <alagalah> #info Keith realizes it is additive, augments condition string
15:15:52 <alagalah> #info Mike notes group can have a circumstance
15:15:59 <alagalah> #topic Tenant
15:15:59 <alagalah> #info Mike notes need to distinguish between tenant and VRF-like xxx concepts
15:16:00 <alagalah> #info One way to think about tenant, the object that contains everything we talked about
15:16:00 <alagalah> #info Can have 3 categories of tenant
15:16:03 <alagalah> #info One is regular tenant, organization
15:16:05 <alagalah> #info Common tenant where all shared stuff is sitting
15:16:06 <alagalah> #info Infrastructure tenant
15:16:08 <alagalah> #info Common tenant, when tenants need to consume services from each other, publish into common tenant, that is how you know who you can access
15:16:10 <alagalah> #info Someone asks about infra tenant?
15:16:12 <alagalah> #info Mickey asks more like provider or group within a provider?
15:16:14 <alagalah> #info Yes
15:16:16 <alagalah> #info Keith notes questions whether inventory part would go into that
15:16:18 <alagalah> #info Mike notes can provide DNS, DHCP as part of infrastructure, and others can use it
15:16:21 <alagalah> #info Regular tenant cannot provide services to anybody else
15:16:22 <alagalah> #info Mickey asks, if looking under specific tenant, cannot resolve to shared?
15:16:24 <alagalah> #info Mike notes from context of where you are towards root of the tree
15:16:27 <alagalah> #info If cannot find it, go to common
15:16:29 <alagalah> #info Mickey notes have to jump
15:16:31 <alagalah> #info Mickey notes trying to do in one dimension rather than multiple dimensions as was done in UCSM and other older products
15:16:32 <alagalah> #info Jan asks one level of tenants?
15:16:35 <alagalah> #info Mike notes we can have more
15:16:37 <alagalah> #info Downside of having nested tenants is how do you shard in a consistent way
15:16:38 <alagalah> #info This is where implementation drives the model, icky, but that is the reality
15:16:41 <alagalah> #info Not opposed to solving the problem, as long as solve the sharding part
15:16:42 <alagalah> #info Mickey notes if shard based on tenant, we need to think about common tenant, whether that becomes a sharding problem
15:16:44 <alagalah> #info Jan notes other apps may not shard based on tenant
15:16:47 <alagalah> #info Mickey hopes all who talk to group-based policy will use asynchronous, then MD-SAL will determine how to get to the appropriate shard
15:16:48 <alagalah> #action Keith to rename Consumer "ROLE" references to "REQUIREMENTS"
15:16:51 <alagalah> #endmeeting