20:08:06 <tbachman> #startmeeting group-policy-requirements
20:08:06 <odl_meetbot> Meeting started Mon Jun 16 20:08:06 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:08:06 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:08:06 <odl_meetbot> The meeting name has been set to 'group_policy_requirements'
20:08:15 <tbachman> chair alagalah
20:08:19 <tbachman> #chair alagalah
20:08:19 <odl_meetbot> Current chairs: alagalah tbachman
20:08:51 <tbachman> Are you guys talking?
20:10:03 <tbachman> #topic model presentation by Dvorkin
20:10:23 <tbachman> #info model is presented as a CLI-like concept
20:10:45 <tbachman> #info model is less verbose, and aims for improved clarity from yang model
20:13:44 <tbachman> #info contracts can be provided or consumed by name
20:14:30 <tbachman> #info Additional “mutual” concept is for intra-EPG contracts
20:15:28 <tbachman> #info groups can have requirements (optional), capabilities (optional), and conditions (optional)
20:15:59 <tbachman> #info “mutual” is what we had previously called “peer” contracts
20:16:20 <tbachman> #info contracts can also be provided/consumed using expressions
20:16:35 <tbachman> #info expressions can use AND/OR/XOR/NOT-like expressions
20:17:51 <tbachman> #info need to specify how the group relates to a network domain. Can be subnet-domain, flood-domain, bridge-domain
20:19:10 <tbachman> #info l3-subnet-domain has an address-range (e.g. IPv4/v6 ranges), and can be part of a network domain or default L3 domain
20:20:13 <tbachman> #info contracts can be selected by one of two means: by name, or by identifier
20:22:54 <tbachman> #info Walking through example
20:23:13 <tbachman> #info using tenant dave, with EPG deveness
20:24:26 <tbachman> #info The default behavior is that two endpoints within the same EPG can communicate w/o a contract
20:24:40 <tbachman> #info tenant dave also has another EPG awesomeness
20:25:02 <tbachman> #info tenant dave also has a contract pingability
20:25:15 <tbachman> The pingability contract has a subject, with a classifier called reflexive icmp
20:25:27 <tbachman> #info The pingability contract has a subject, with a classifier called reflexive icmp
20:26:05 <tbachman> #info clauses are implied in this case
20:26:56 <tbachman> #info mickey_spiegel says that you don’t have to provide and consume to make it bi-directional
20:28:51 <tbachman> #info dvorkinista says that we can add a “peer” contract to both provide and consume
20:29:16 <tbachman> #info mickey_spiegel says that classifier and action have in/out/bi- in the UML model
20:30:45 <tbachman> #info to continue this example, something needs to assign and endpoint to group daveness, and a second endpoint to group awesomeness, and then the two endpoints can communicate with the pingability
20:30:51 <tbachman> #info contract
20:32:02 <tbachman> #info lenrow asks what we mean by tenant
20:32:13 <tbachman> #info dvorkinista says that it can be thought of as just a container
20:32:23 <tbachman> #info lenrow asks if it can have more than one L2 context
20:32:34 <tbachman> #info dvorkinista says yes
20:32:55 <tbachman> #info to extend the model, an l2-bridge-domain named foo is added, which has part-of-domain mystuff
20:33:05 <tbachman> #info and an l3-domain mystuff is definied
20:33:30 <tbachman> and the part-of-domain foo is added to the daveness and awesomeness groups
20:33:48 <tbachman> #info and the part-of-domain foo is added to the daveness and awesomeness groups
20:34:19 <tbachman> #info The model is extended further by adding another tenant
20:34:41 <tbachman> #info Another tenant called common is created
20:35:08 <tbachman> #info The pingability contract is moved to the common tenant (i.e. instead of being part of the dave tenant)
20:35:20 <tbachman> #info where the “common” tenant name is a special name
20:35:53 <tbachman> #info This allows multiple tenants to share the tenant common items
20:36:08 <tbachman> #info extending further, a new tenant named keith is added
20:36:35 <tbachman> #info keith also has a group that references the pingability contract defined in teh common tenant
20:37:50 <tbachman> #info question about AAA was raised
20:38:01 <tbachman> #info that needs to be defined in ODL first
20:38:18 <tbachman> #info And then it can be used for GBP
20:48:11 <tbachman> #info mickey_spiegel asks if there are multiple groups in scope, are we using longest-match prefix?
20:48:19 <tbachman> #info dvorkinista that can be one way
20:49:09 <tbachman> #info longest-prefix match
20:50:19 <tbachman> #info question asked for when policy is definied, is that applicable to a specific topology that’s been reported?
20:50:43 <tbachman> #info this is high-level intent — a policy model
20:50:58 <tbachman> #info as an example, a high-level intent for network virtualization
20:51:59 <tbachman> #info provides a mean of specifiying things like access-control, without having to worry about what’s underneath, which makes it more portable
20:52:25 <tbachman> #info The point is that the southbounds have high-variability, so portability is important
20:53:23 <tbachman> #info question is asked what marries this policy to low level things
20:53:34 <tbachman> #info the renderers provide this mapping
20:58:43 <tbachman> #info Question was asked if the peer contract pingability was needed in teh amazingness and awesomeness groups, given that both groups had part-of-domain greatstuff
20:59:02 <tbachman> #info the answer is that the l3-domain greatstuff is addressability, but not reachability
20:59:09 <tbachman> #info so, the contract is needed for reachability
21:03:23 <tbachman> #topic what to do with the model presented by Dvorkin
21:03:39 <tbachman> #info Dvorkin just saw this as an instrument to better explain how this works
21:05:35 <tbachman> #info mickey_spiegel notes that we can do the same thing in yang that was done with this CLI-type model
21:08:43 <tbachman> #info readams notes that things like provide/consume type relationships in yang is a bit tricky, as extraneous information isn’t magically filtered out
21:10:16 <tbachman> #info mickey_spiegel asks if it makes sense to demonstrate this with restconf
21:10:32 <tbachman> #info readams notes that you can do the same in JSON
21:22:55 <tbachman> #info lenrow would like to see a user interface that is easier to pick up and understand that what’s done in JSON
21:23:39 <tbachman> #info readams notes that there would be some binding on top of this to make it easier to use (e.g. python bindings)
21:23:54 <tbachman> #info lenrow says that people care about the APIs, not the bindings
21:24:38 <tbachman> #info readams notes that a new encoding could be added to the northbound, if that’s found to be easier.
21:34:24 <tbachman> #info yang does have some constructs it can’t support, which causes some of the constructs seen in the yang model
21:38:01 <tbachman> #action lenrow to provide a link for a document of the UC&C use case
21:39:45 <tbachman> #info propose using Thurday status meeting for continuation
21:39:57 <tbachman> #topic update on steering/redirection
21:40:15 <tbachman> #info seeking more input from IETF SFC team
21:40:32 <tbachman> #info need to propose way to integrate the rendering needs of SFC into the GBP project
21:40:55 <tbachman> #info developing intro presentation for conversation with IETF SF
21:40:59 <tbachman> #info SFC
21:43:45 <tbachman> #info UCIF requirements
21:43:47 <tbachman> #topic UCIF requirements
21:44:01 <tbachman> #info UCIF QoS: A proposal for marking flows
21:44:09 <tbachman> #info described in terms fo DSCP markings
21:44:19 <tbachman> #info Need to propose intent expressions instead
21:44:35 <tbachman> #info DSCP marking would be a rendering technique for particular SB
21:45:06 <tbachman> #info http://www.ucif.org/Portals/0/documents/2014_02_27_Use_case.pdf
21:45:13 <tbachman> #info UCIF Automated TE
21:45:25 <tbachman> #info Allows asynch updates to change marking for specific flows
21:45:42 <tbachman> #info Allow explicit reallocation of bandwidth pool between classes of service
21:45:48 <tbachman> #info Working on permission required to share in ODL
21:56:51 <tbachman> #info discussion on need for realizing more use cases
21:57:06 <tbachman> #info in order to uncover any possible corner cases or issues
22:00:24 <tbachman> #action lenrow to propose continuing this discussion on Thursday’s status meeting
22:00:31 <tbachman> #endmeeting