Ivar, With the currently supported set of services I also agree, but as more services get supported in the future, or we hand out that choice to tenants' VMs, it starts to justify a generic model that does not restrict whether EPs should provide service chains.
That said, I do not yet totally understand the fundamental difference between having providers/consumers or just changing policy classifiers' directions. For instance, I could have a provider PTG and a consumer EP with the traffic headed towards PTG redirecting to some chain. Likewise, PTG could be the consumer and EP the provider and still have traffic headed towards the PTG redirecting to some chain. About this I would very much appreciate a simple clarification. For the use cases, and now looking at providers/consumers as more than traffic directionality, an EP could be created as an external source of video which would then pass through a video transcoding service function (eventually deployed as a Nova instance) before reaching the consuming PTGs (that could aggregate users of a telecommunications service provider, per home, region, subscription type, etc., in the context of NFV). It's just an example from the tip of my head. Cheers, On Thu, Mar 19, 2015 at 10:28 PM Ivar Lazzaro <ivarlazz...@gmail.com> wrote: > Hello, > > As a follow up on [0] I have a question for the community. > There are multiple use cases for a PTG *providing* a ServiceChain which is > *consumed* by an External Policy (think about LB/FW/IDS and so forth). > However, given the current set of services we support, I don't see any use > case for having the External Policy as the provider on a PRS with a chain. > > Am I missing something? And if not, how should we manage a REDIRECT action > provided by an External Policy? We could either ignore, validate or treat > that particular action just like a normal ALLOW. > > Thanks for your feedbacks, > Ivar. > > [0] https://bugs.launchpad.net/group-based-policy/+bug/1432779 > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev