Open Stack

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 <ivarlazzaro at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150323/9e859182/attachment.html>