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