==================================== #opendaylight-group-policy: gbp_arch ==================================== Meeting started by tbachman at 17:04:41 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-group-policy/2014/gbp_arch/opendaylight-group-policy-gbp_arch.2014-09-05-17.04.log.html . Meeting summary --------------- * agenda (tbachman, 17:04:47) * SFC Discussion (tbachman, 17:05:08) * intent of meeting is to walk through SFC model (tbachman, 17:06:10) * That will help us deciding what to do in GBP (tbachman, 17:06:31) * The main model is he service-function.yang (tbachman, 17:08:07) * There’s a container for all service functions in the network (tbachman, 17:08:18) * and a list that holds all the service functions, keyed by service function anme (tbachman, 17:08:30) * there’s also operational data that the service function code populates based on input from other services (topology, openflow, etc.) (tbachman, 17:08:55) * There are also RPCs, which are there mostly for completeness (tbachman, 17:09:10) * as most people use internal APIs or REST interfaces (tbachman, 17:09:20) * A service function has a name, type (FW, NAT, etc.), management IP address as per IETF, a leaf for NSH-aware capability (tbachman, 17:09:57) * The service function also has a list of data plane locators (tbachman, 17:10:15) * This is for how packets can reach the service function (e.g. VLAN ID) (tbachman, 17:10:32) * mickey_spiegel asks when you have many locators, is it possible that they’re bound in different ways (e.g. in and out), or are they all treated the same (tbachman, 17:11:14) * rpenno says they don’t make such distinctions. (tbachman, 17:11:31) * this is how a service function forwarder sends to a function — you send to one of these locators (tbachman, 17:11:46) * paulq says that once you break from topology, the concept of in/out (service model perspective) goes away (tbachman, 17:12:37) * The semantic of in/out can be assigned by the policy layer, if desired (tbachman, 17:13:06) * and it doesn’t matter from a service chaining perspective (tbachman, 17:13:20) * in/out is used for policy constructs in the firewall, so as long as it can distinguish that packets are coming in and going out it’s fine (tbachman, 17:13:46) * In other words, you don’t care about the context of the incoming interface (or other distinguisher) isn’t relavent (tbachman, 17:14:21) * The sf-data-plane-locator is specific to the service function (tbachman, 17:15:10) * The philosophy behind the model is that they’re very service function chaining specific (tbachman, 17:15:52) * It presumes there can be more than one administrative domain (tbachman, 17:16:09) * The service function chain is an ordered list of service function types (tbachman, 17:16:35) * A type can be a firewall, NAT, proxy, etc. (tbachman, 17:16:45) * There’s no standardized list for types (tbachman, 17:16:55) * And users can create their own identities for their own deployment (tbachman, 17:17:07) * The types can be linked under a service function chain (tbachman, 17:17:19) * There is also a symmetric property, and ordered-by property (tbachman, 17:17:59) * The service function chain doesn’t decide which element is going to provide a function (e.g. FW) (tbachman, 17:18:45) * refer to the recording to see a demonstration of the UI showing the chains (tbachman, 17:19:33) * The service function forwarder is a switch, router, bridge, etc. (tbachman, 17:19:47) * The service function forwarder is responsible for sending packets to the service function and getting them back from it (tbachman, 17:20:06) * It handles the data plane activities (tbachman, 17:20:15) * There is a list of service function forwarders, keyed by its name (tbachman, 17:21:20) * There is a classifier attached to the service function forwarder (tbachman, 17:21:41) * sanjay asks whether a service function forwarder is in every service node (tbachman, 17:21:57) * rpenno says the service node might not be there in the future (tbachman, 17:22:16) * paulq says that the service function forwarder is something a user would never see (tbachman, 17:22:30) * it allows the service chain to occur (tbachman, 17:22:37) * to build it’s own service function chain topology (tbachman, 17:22:47) * without the service functions to have to be routers (tbachman, 17:22:59) * it provides a logical forwarding on behalf of the service function (tbachman, 17:23:14) * sanjay asks if there’s one forwarder for every service function? (tbachman, 17:23:32) * paulq says the service function forwarder is logical — it *could* be the service function (tbachman, 17:24:16) * can a service function be attached to more than one forwarder? (tbachman, 17:24:31) * yes it can (tbachman, 17:24:34) * paulq says that in the context of GBP, GBP would control the classifier (tbachman, 17:26:17) * mickey_spiegel asks if the classifier is at both the head end and the back if you fork (tbachman, 17:26:40) * paulq says ues (tbachman, 17:26:44) * The classifier is a service function construct — it’s not like a networking classifier (tbachman, 17:28:00) * Each service function forwarder has a set of data plane locators (tbachman, 17:28:32) * This is how service function forwarders can reach each other, and how overlays are constructed (tbachman, 17:28:45) * They can be GRE data plane locators, VxLAN data plane locators, etc. (tbachman, 17:29:00) * Sanjay asks if in a path there will be a single data plane locator for the next hop? (tbachman, 17:29:27) * rpenno says yes (tbachman, 17:29:35) * but if there are forks, then you can have multiple data plane locators (tbachman, 17:29:46) * each service function forwarder has a dictionary, which is the list of all service functions it can reach (tbachman, 17:30:08) * The data plane locators provide this dictionary (tbachman, 17:30:36) * There is a fail mode — what a forwarder should do if it can’t reach a service function (bypass, drop) (tbachman, 17:31:51) * There is also work for support for features like HA (tbachman, 17:32:11) * The service function forwarder is very generic (tbachman, 17:32:20) * and can apply to anything (vSwitch, router, etc.) (tbachman, 17:32:40) * The service function forwarder should be augmented for specific use cases (e.g. OVS with OpenStack) (tbachman, 17:33:04) * This is demonstrated in service-funciton-forwarder-ovs.yang (tbachman, 17:33:23) * The service function path is the actual places that a packet will visit (tbachman, 17:34:33) * as it traverses the overlay (tbachman, 17:34:42) * There is a list of service function paths (tbachman, 17:34:49) * A service function path is composed of service path hops (tbachman, 17:35:00) * where each hop is collection of a service function forwarder and service function name (tbachman, 17:35:16) * The hop counter is incremented on every service function forwarder (tbachman, 17:35:43) * This is distinct from the service function index, which is incremented on each service function (tbachman, 17:36:09) * The hop counter is there to deal with scenarios where you have forwarders with out functions (tbachman, 17:36:24) * most users won’t have to deal with it (tbachman, 17:36:36) * The starting index is important for systems that don’t want to compute the starting index (tbachman, 17:37:33) * there’s also a path ID (tbachman, 17:37:38) * In order to create a path, in the simplest case, you need to give it a name and the name of the chain that it should be instantiated (tbachman, 17:39:09) * mickey_spiegel asks if you’re creating service function instances for each hop on the chain (tbachman, 17:39:48) * rpenno says you need to create the catalog of service functions ahead of time (tbachman, 17:40:04) * mickey_spiegel asks if you allocate individual service functions for each hop along the path (tbachman, 17:40:22) * rpenno says yes — it will select the most suitable one for that path (tbachman, 17:40:40) * where suitable could be as simple as picking the first one that it finds (tbachman, 17:41:01) * rpenno says there is a language for describing this (tbachman, 17:41:14) * but it hasn’t been committed upstream yet (tbachman, 17:41:27) * It’s a metadata model for service function characteristics (tbachman, 17:41:41) * You want the path to be constructed with certain constraints. Today the constraints are based on use cases (tbachman, 17:42:02) * For example, geographic location, or more sophisticated things like number of connections on a Firewall (tbachman, 17:42:20) * The model will be a container-based yang model with a list (tbachman, 17:42:36) * so that the list can be updated when needed (tbachman, 17:42:45) * mickey_spiegel asks whether you can reuse a service function that’s already been allocated (tbachman, 17:45:52) * rpenno says you can (tbachman, 17:45:56) * rpenno says there’s no tenancy here, and that would have to be an augmentation for the service model (tbachman, 17:47:03) * and tenancy could be used as a constraint, if desired (tbachman, 17:47:21) * when a service function path is created, it goes to the service function and checks the operational state (tbachman, 17:48:39) * and checks to see if the service function is in use by this path (tbachman, 17:49:03) * so, you could put the name of the tenant in the operational state (tbachman, 17:49:14) * new service types can be added by creating new identities in the yang model (tbachman, 17:51:14) * The data plane locators for service function and service function forwarder have a structure that’s imported from another SFC model (tbachman, 17:51:36) * This is done so that you can enhance it as much as you want without touching the service function and service function forwarder (tbachman, 17:51:53) * rpenno prefers to use groups and uses over leafrefs (tbachman, 17:54:47) * b/c the java code that’s generated from leafrefs has additional considerations that he prefers to avoid (tbachman, 17:55:10) * sanjay asks if there are authorization domains — like who can see what? (tbachman, 17:56:41) * rpenno says that there are, but that will be post-helium (tbachman, 17:56:51) * There’s still a question as to whether SFC or GBP renders that front-end classifier (tbachman, 18:00:02) Meeting ended at 18:05:19 UTC. People present (lines said) --------------------------- * tbachman (111) * odl_meetbot (3) * alagalah_ (1) * uchau1 (1) Generated by `MeetBot`_ 0.1.4