Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Paul Carver]

On 10/28/2015 04:14, Giuseppe (Pino) de Candia wrote:

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant > wrote:

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html







We have similarly been experimenting with a MidoNet implementation of
the SFC API.



Russell, Giuseppe,

Have you looked any further at OVN/MidoNet implementations of the SFC API?

It's been a long road to get the initial OvS implementation done and 
there are still some pieces that haven't been merged yet but we'd be 
very interested in feedback on the pluggable driver model.


The intent has always been to create a common SFC API with an 
ML2-inspired separation of the API from the backend so that service 
chains can be created using the same API calls across multiple SDN 
controller backends.


I'd like to capture feedback on the driver model and whether we've got 
the right bits in place to allow for hooking in various SDN controllers.



__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Pino,

Please see inline.

Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Monday, November 02, 2015 10:22 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:


From: Giuseppe (Pino) de Candia 
[mailto:gdecan...@midokura.com<mailto:gdecan...@midokura.com>]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.
I don't think that works. For L3 services, the packet's destination MAC must be 
set equal to the service port's MAC. That means that all the original 
destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF instance 
is shared across multiple tenants with overlapping IPs. Therefore, I use the 
MAC to identify the service chain instance and get a packet back on its 
original network path.

Cathy> Not sure why you use MAC to identify the service chain instance? It is 
better to use a separate chain ID for this purpose.

So, I won't modify the packet at all. Can you suggest another solution? And why 
so much resistance to adding a flag when we can actually show use-cases? Note 
that this is already actually running code today, using MidoNet's service 
chaining API.

Cathy> If you use a separate chainID, then you will not need a flag to handle 
the use cases. If you really need a flag, one way is to extend the SF parameter 
to specify a L2/L3 type.

thanks,
Pino


Thanks,

Cathy

__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang <cathy.h.zh...@huawei.com>
wrote:

>
>
>
>
> *From:* Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
> *Sent:* Saturday, October 31, 2015 10:08 PM
> *To:* Cathy Zhang
> *Cc:* Henry Fourie; OpenStack Development Mailing List (not for usage
> questions); Irena Berezovsky
> *Subject:* RE: [openstack-dev] [neutron][networking-sfc] API
> clarification questions
>
> >
> > Cathy> No restriction as long as the ports are routable. Originally we
> think we need to specify L2 and L3 service type. But later we found out it
> is not needed if we program the switch to set the next hop destination to
> the service function’s MAC. This way no matter whether it is L2 or L3, it
> always works.
> >
>
> Hi Cathy, my understanding is that:
> -for an L2 service, don't modify the packet (ignoring possible
> encapsulation to signal policy )
> -for an L3 service, set the dst MAC in the packet equal to the the service
> port's MAC
>
> How can the SDN implementation know which kind of service it's dealing
> with to decide whether to modify the MAC?
>
> Cathy> You can always modify the MAC which will work for both L2 and L3
> service.
>
I don't think that works. For L3 services, the packet's destination MAC
must be set equal to the service port's MAC. That means that all the
original destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF
instance is shared across multiple tenants with overlapping IPs. Therefore,
I use the MAC to identify the service chain instance and get a packet back
on its original network path.

So, I won't modify the packet at all. Can you suggest another solution? And
why so much resistance to adding a flag when we can actually show
use-cases? Note that this is already actually running code today, using
MidoNet's service chaining API.

thanks,
Pino


> Thanks,
>
> Cathy
>
__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.

Thanks,

Cathy
__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Oct 28, 2015 19:17, "Russell Bryant"  wrote:
>
> On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> > On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  > > wrote:
> >
> > I read through the proposed SFC API here:
> >
> > http://docs.openstack.org/developer/networking-sfc/api.html
> >
> > I'm looking at implementing what would be required to support this
API
> > in OVN.  I have a prototype, but I had to make some pretty big
> > assumptions, so I wanted to clarify the intent of the API.
> >
> > First, does it assume that all of the neutron ports in a chain are
on
> > the same Neutron network?  That keeps things simple.  If its
intended to
> > allow a chain of ports on different networks, is it just required
that
> > you pick ports that all have addresses routable from one port to the
> > next in the chain?  An arbitrary set of ports can't always work, so
> > there has to be some bounds around what set of ports are valid to
be in
> > a chain.
> >
> >
> > Hi Russell,
> >
> > We have similarly been experimenting with a MidoNet implementation of
> > the SFC API.
>
> Great!  It's nice to have multiple people looking at this with different
> implementations in mind.  That should help us shake out these sorts of
> issues before the API is too locked down.  Thanks for jumping in.  :-)
>
> > I hope there's no restriction on the location of the Neutron ports in a
> > chain.
>
> Yes, that makes sense.  Cathy's response seems to support that there
> isn't a limitation.  We do need to clearly define it in the API
> reference though.  Maybe something like ...
>
>   All ports must:
>   * be owned by the tenant.
>   * have IP addresses such that the address of port N+1 in the chain
> is routable from port N in the chain.

I guess you're just brainstorming... But I hope we don't adopt the second
restriction.

>
> > In terms of addresses, I believe the API is lacking (or we use a
> > chain_parameter?) a way to indicate the service insertion model:
> > - L2 - The service can accept packets sent from any MAC (service NIC in
> > promiscuous mode). The MAC address may be used to identify where the
> > packet came from before it entered the chain.
>
> If the ports in the chain don't have to all be on the same L2 network,
> then it doesn't seem like you could use the source MAC address to know
> where the packet came from before it entered the chain.
>
> > - L3 -  The service expects packets to be routed to it. So the
> > destination MAC of the packet must be set to the service's NIC's MAC.
>
> This seems to make more sense to me.  You've got the "coorelation chain
> parameter" to know what chain the packet is in, and you use the source
> IP address to know where the packet came from originally before it
> entered the chain.
>
> >
> >
> >
> > Second, where is it expected that the match is applied?  The API for
> > creating a port chain doesn't associate the chain with a network,
but
> > just matching "globally" doesn't make any sense.  If all ports are
> > expected to be on the same network, is the match applied for any
traffic
> > entering that network from any port?
> >
> >
> > Here's what we were thinking for MidoNet:
> >
> > use the logical_source_port in the flow classifier: when we render the
> > SFC API in MidoNet's models we will associate the chain with the source
> > port.
> >
> > Our packet pipeline (for packets egressing the VM) is:
> >
> >  1. Port Mirroring
> >  2. Service Chaining
> >  3. Filtering (Port Security, anti-spoofing, Security Groups)
>
> OK, so it sounds like you're applying the "flow classifier" to packets
> as the come from a neutron port and enter a neutron network.  That makes
> sense.
>
> Which ports' traffic do you apply the flow classifier to?  That's the
> key piece I'm missing.
>
> If the flow classifier includes a logical-source-port match, then it's
> easy.  You only check traffic from a specific Neutron port.  The same
> seems to apply if you only specified a logical-destination port, since
> in that case you'd be matching on traffic ingressing the VM.
>
> If tenant A creates the port chain and both logical-source-port and
> logical-destination-port are not specified, then what packets do you
> apply the flow classifier to?
>
> >
> >
> > Do you think we can standardise on a single order in all
> > implementations? We'd be happy to change the order if it makes sense.
>
> I think we do need to standardize where we can, yes.  We want the
> resulting network behavior from the end user perspective to be as close
> as possible to the same thing regardless of backend.
>
> > I'm in Tokyo this week, so if the group working on this would like
to
> > talk in person, that would be great too.
> >
> >
> > I'd love to be included.
>
> OK, it's probably best that we try to keep it on the mailing list as
> much as possible.  I really don't want to 

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Oct 29, 2015 08:37, "Cathy Zhang" <cathy.h.zh...@huawei.com> wrote:
>
> Hi Giuseppe,
>
>
>
> Please see inline,
>
>
>
> Regards,
>
> Cathy
>
>
>
> From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
> Sent: Wednesday, October 28, 2015 5:15 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky
> Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification
questions
>
>
>
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com>
wrote:
>
> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
>
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
>
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
>
>
>
> Hi Russell,
>
>
>
> We have similarly been experimenting with a MidoNet implementation of the
SFC API.
>
>
>
> I hope there's no restriction on the location of the Neutron ports in a
chain.
>
>
>
> In terms of addresses, I believe the API is lacking (or we use a
chain_parameter?) a way to indicate the service insertion model:
>
> - L2 - The service can accept packets sent from any MAC (service NIC in
promiscuous mode). The MAC address may be used to identify where the packet
came from before it entered the chain.
>
> - L3 -  The service expects packets to be routed to it. So the
destination MAC of the packet must be set to the service's NIC's MAC.
>
>
>
> Any thoughts on this?
>
>
>
> Cathy> No restriction as long as the ports are routable. Originally we
think we need to specify L2 and L3 service type. But later we found out it
is not needed if we program the switch to set the next hop destination to
the service function’s MAC. This way no matter whether it is L2 or L3, it
always works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible
encapsulation to signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service
port's MAC

How can the SDN implementation know which kind of service it's dealing with
to decide whether to modify the MAC?

Thanks,
Pino

>
>>
>>
>> Second, where is it expected that the match is applied?  The API for
>> creating a port chain doesn't associate the chain with a network, but
>> just matching "globally" doesn't make any sense.  If all ports are
>> expected to be on the same network, is the match applied for any traffic
>> entering that network from any port?
>
>
>
> Here's what we were thinking for MidoNet:
>
>
>
> use the logical_source_port in the flow classifier: when we render the
SFC API in MidoNet's models we will associate the chain with the source
port.
>
>
>
> Cathy> Yes, that is the way to specify the flow classifier. Note that one
or more flow classifiers can be associated with the same chain.
>
>
>
> Our packet pipeline (for packets egressing the VM) is:
>
> Port Mirroring
> Service Chaining
> Filtering (Port Security, anti-spoofing, Security Groups)
>
>
>
> Do you think we can standardise on a single order in all implementations?
We'd be happy to change the order if it makes sense.
>
>
>
>
>>
>>
>> I'm in Tokyo this week, so if the group working on this would like to
>> talk in person, that would be great too.
>
>
>
> I'd love to be included.
>
>
>
> Great topic, thanks!
>
>
>
> Cathy> I discussed briefly with Russell in yesterday’s Neutron design
session. If needed, we can meet in today’s Neutron NFV session.
>
>
>
> Thanks,
>
> Cathy
>
>
>
>
>
> Pino
>
>
>>
>>
>> --
>> Russell Bryant
>>
>>
__
>> 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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

Hi Gal,

Sorry for the slow reply.

Actually, thinking about it now, I'm not sure.

First, I assume that the pipeline must be in reverse order for
ingress/egress. Do you agree?

For a generic VM, it might be best to have chaining between the network and
the port-level FW. This would allow a security appliance to see and log a
port scan.

But if the VM is a VPN appliance, the port scan could come from either side
of the port. So perhaps we need the possibility to specify a chain's
position relative to security?

-Pino
On Oct 28, 2015 18:16, "Gal Sagie"  wrote:

> Hi Pino,
>
> Just one note on the order of the pipeline, shouldnt the security part be
> before the service chaining (and also after)?
> (Unless you only meant egress security and you still do the ingress before)
>
> Gal.
>
> On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
> gdecan...@midokura.com> wrote:
>
>> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
>> wrote:
>>
>>> I read through the proposed SFC API here:
>>>
>>> http://docs.openstack.org/developer/networking-sfc/api.html
>>>
>>> I'm looking at implementing what would be required to support this API
>>> in OVN.  I have a prototype, but I had to make some pretty big
>>> assumptions, so I wanted to clarify the intent of the API.
>>>
>>> First, does it assume that all of the neutron ports in a chain are on
>>> the same Neutron network?  That keeps things simple.  If its intended to
>>> allow a chain of ports on different networks, is it just required that
>>> you pick ports that all have addresses routable from one port to the
>>> next in the chain?  An arbitrary set of ports can't always work, so
>>> there has to be some bounds around what set of ports are valid to be in
>>> a chain.
>>>
>>
>> Hi Russell,
>>
>> We have similarly been experimenting with a MidoNet implementation of the
>> SFC API.
>>
>> I hope there's no restriction on the location of the Neutron ports in a
>> chain.
>>
>> In terms of addresses, I believe the API is lacking (or we use a
>> chain_parameter?) a way to indicate the service insertion model:
>> - L2 - The service can accept packets sent from any MAC (service NIC in
>> promiscuous mode). The MAC address may be used to identify where the packet
>> came from before it entered the chain.
>> - L3 -  The service expects packets to be routed to it. So the
>> destination MAC of the packet must be set to the service's NIC's MAC.
>>
>> Any thoughts on this?
>>
>>
>>>
>>> Second, where is it expected that the match is applied?  The API for
>>> creating a port chain doesn't associate the chain with a network, but
>>> just matching "globally" doesn't make any sense.  If all ports are
>>> expected to be on the same network, is the match applied for any traffic
>>> entering that network from any port?
>>>
>>
>> Here's what we were thinking for MidoNet:
>>
>> use the logical_source_port in the flow classifier: when we render the
>> SFC API in MidoNet's models we will associate the chain with the source
>> port.
>>
>> Our packet pipeline (for packets egressing the VM) is:
>>
>>1. Port Mirroring
>>2. Service Chaining
>>3. Filtering (Port Security, anti-spoofing, Security Groups)
>>
>>
>> Do you think we can standardise on a single order in all implementations?
>> We'd be happy to change the order if it makes sense.
>>
>>
>>
>>>
>>> I'm in Tokyo this week, so if the group working on this would like to
>>> talk in person, that would be great too.
>>>
>>
>> I'd love to be included.
>>
>> Great topic, thanks!
>>
>> Pino
>>
>>
>>>
>>> --
>>> Russell Bryant
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> 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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Russell,

Please see my replies inline.

Thanks,
Cathy

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, October 28, 2015 4:21 PM
To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie
Subject: [neutron][networking-sfc] API clarification questions

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API in OVN.  
I have a prototype, but I had to make some pretty big assumptions, so I wanted 
to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on the same 
Neutron network?  That keeps things simple.  If its intended to allow a chain 
of ports on different networks, is it just required that you pick ports that 
all have addresses routable from one port to the next in the chain? 

Cathy> It can allow a chain of ports on different networks as along it belongs 
to the same tenant. Yes, it is required that you pick ports that all have 
addresses routable from one port to the next in the chain. 



An arbitrary set of ports can't always work, so there has to be some bounds 
around what set of ports are valid to be in a chain.

Second, where is it expected that the match is applied?  The API for creating a 
port chain doesn't associate the chain with a network, but just matching 
"globally" doesn't make any sense.  If all ports are expected to be on the same 
network, is the match applied for any traffic entering that network from any 
port?

Cathy> As long as the ports are routable, they do not need to associated with 
the same network. 

I'm in Tokyo this week, so if the group working on this would like to talk in 
person, that would be great too.

Cathy> Sure. I am going to the "Neutron: Extensibility mechanisms: Plugin and 
Agent" session. If you also plan to go, we can meet there. Or we can meet at 
tomorrow afternoon's "Neutron: NFV foundation elements" 
session (Crown room at 4:30pm). 

--
Russell Bryant
__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Russell Bryant]

- Original Message -
> Hi Russell,
> 
> Please see my replies inline.
> 
> Thanks,
> Cathy
> 
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Wednesday, October 28, 2015 4:21 PM
> To: OpenStack Development Mailing List; Cathy Zhang; Henry Fourie
> Subject: [neutron][networking-sfc] API clarification questions
> 
> I read through the proposed SFC API here:
> 
> http://docs.openstack.org/developer/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API in
> OVN.  I have a prototype, but I had to make some pretty big assumptions, so
> I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on the
> same Neutron network?  That keeps things simple.  If its intended to allow a
> chain of ports on different networks, is it just required that you pick
> ports that all have addresses routable from one port to the next in the
> chain?
> 
> Cathy> It can allow a chain of ports on different networks as along it
> belongs to the same tenant. Yes, it is required that you pick ports that all
> have addresses routable from one port to the next in the chain.

Thanks.  I think it would be good to clarify this in the API doc, so it's clear 
what makes a valid set of ports in a chain.

> An arbitrary set of ports can't always work, so there has to be some bounds
> around what set of ports are valid to be in a chain.
> 
> Second, where is it expected that the match is applied?  The API for creating
> a port chain doesn't associate the chain with a network, but just matching
> "globally" doesn't make any sense.  If all ports are expected to be on the
> same network, is the match applied for any traffic entering that network
> from any port?
> 
> Cathy> As long as the ports are routable, they do not need to associated with
> the same network.

Let me rephrase the question ... where is the flow classifier applied?  What 
traffic exactly?  "All traffic on all networks accessible to the tenant who 
created the port chain" doesn't seem right to me, but the API doesn't seem to 
specify it.


-- 
Russell

__
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-dev] [neutron][networking-sfc] API clarification questions

[Russell Bryant]

I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API
in OVN.  I have a prototype, but I had to make some pretty big
assumptions, so I wanted to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on
the same Neutron network?  That keeps things simple.  If its intended to
allow a chain of ports on different networks, is it just required that
you pick ports that all have addresses routable from one port to the
next in the chain?  An arbitrary set of ports can't always work, so
there has to be some bounds around what set of ports are valid to be in
a chain.

Second, where is it expected that the match is applied?  The API for
creating a port chain doesn't associate the chain with a network, but
just matching "globally" doesn't make any sense.  If all ports are
expected to be on the same network, is the match applied for any traffic
entering that network from any port?

I'm in Tokyo this week, so if the group working on this would like to
talk in person, that would be great too.

-- 
Russell Bryant

__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Giuseppe (Pino) de Candia]

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  wrote:

> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
>
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
>
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
>

Hi Russell,

We have similarly been experimenting with a MidoNet implementation of the
SFC API.

I hope there's no restriction on the location of the Neutron ports in a
chain.

In terms of addresses, I believe the API is lacking (or we use a
chain_parameter?) a way to indicate the service insertion model:
- L2 - The service can accept packets sent from any MAC (service NIC in
promiscuous mode). The MAC address may be used to identify where the packet
came from before it entered the chain.
- L3 -  The service expects packets to be routed to it. So the destination
MAC of the packet must be set to the service's NIC's MAC.

Any thoughts on this?


>
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "globally" doesn't make any sense.  If all ports are
> expected to be on the same network, is the match applied for any traffic
> entering that network from any port?
>

Here's what we were thinking for MidoNet:

use the logical_source_port in the flow classifier: when we render the SFC
API in MidoNet's models we will associate the chain with the source port.

Our packet pipeline (for packets egressing the VM) is:

   1. Port Mirroring
   2. Service Chaining
   3. Filtering (Port Security, anti-spoofing, Security Groups)


Do you think we can standardise on a single order in all implementations?
We'd be happy to change the order if it makes sense.



>
> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
>

I'd love to be included.

Great topic, thanks!

Pino


>
> --
> Russell Bryant
>
> __
> 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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Russell Bryant]

On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant  > wrote:
> 
> I read through the proposed SFC API here:
> 
> http://docs.openstack.org/developer/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
> 
> 
> Hi Russell,
> 
> We have similarly been experimenting with a MidoNet implementation of
> the SFC API.

Great!  It's nice to have multiple people looking at this with different
implementations in mind.  That should help us shake out these sorts of
issues before the API is too locked down.  Thanks for jumping in.  :-)

> I hope there's no restriction on the location of the Neutron ports in a
> chain. 

Yes, that makes sense.  Cathy's response seems to support that there
isn't a limitation.  We do need to clearly define it in the API
reference though.  Maybe something like ...

  All ports must:
  * be owned by the tenant.
  * have IP addresses such that the address of port N+1 in the chain
is routable from port N in the chain.

> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the
> packet came from before it entered the chain.

If the ports in the chain don't have to all be on the same L2 network,
then it doesn't seem like you could use the source MAC address to know
where the packet came from before it entered the chain.

> - L3 -  The service expects packets to be routed to it. So the
> destination MAC of the packet must be set to the service's NIC's MAC.

This seems to make more sense to me.  You've got the "coorelation chain
parameter" to know what chain the packet is in, and you use the source
IP address to know where the packet came from originally before it
entered the chain.

>  
> 
> 
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "globally" doesn't make any sense.  If all ports are
> expected to be on the same network, is the match applied for any traffic
> entering that network from any port?
> 
> 
> Here's what we were thinking for MidoNet:
> 
> use the logical_source_port in the flow classifier: when we render the
> SFC API in MidoNet's models we will associate the chain with the source
> port.
> 
> Our packet pipeline (for packets egressing the VM) is:
> 
>  1. Port Mirroring
>  2. Service Chaining
>  3. Filtering (Port Security, anti-spoofing, Security Groups)

OK, so it sounds like you're applying the "flow classifier" to packets
as the come from a neutron port and enter a neutron network.  That makes
sense.

Which ports' traffic do you apply the flow classifier to?  That's the
key piece I'm missing.

If the flow classifier includes a logical-source-port match, then it's
easy.  You only check traffic from a specific Neutron port.  The same
seems to apply if you only specified a logical-destination port, since
in that case you'd be matching on traffic ingressing the VM.

If tenant A creates the port chain and both logical-source-port and
logical-destination-port are not specified, then what packets do you
apply the flow classifier to?

> 
> 
> Do you think we can standardise on a single order in all
> implementations? We'd be happy to change the order if it makes sense. 

I think we do need to standardize where we can, yes.  We want the
resulting network behavior from the end user perspective to be as close
as possible to the same thing regardless of backend.

> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
> 
> 
> I'd love to be included.

OK, it's probably best that we try to keep it on the mailing list as
much as possible.  I really don't want to exclude anyone, and it's
important that this stuff is written down anyway.

There is an "NFV foundation elements" design summit session where I
think networking-sfc is going to be discussed, but unfortunately I have
a regular conference talk at the same time.

> Great topic, thanks!

Thanks for jumping in!

-- 
Russell Bryant

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Giuseppe,

Please see inline,

Regards,
Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Wednesday, October 28, 2015 5:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Henry Fourie; Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
<rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote:
I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API
in OVN.  I have a prototype, but I had to make some pretty big
assumptions, so I wanted to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on
the same Neutron network?  That keeps things simple.  If its intended to
allow a chain of ports on different networks, is it just required that
you pick ports that all have addresses routable from one port to the
next in the chain?  An arbitrary set of ports can't always work, so
there has to be some bounds around what set of ports are valid to be in
a chain.

Hi Russell,

We have similarly been experimenting with a MidoNet implementation of the SFC 
API.

I hope there's no restriction on the location of the Neutron ports in a chain.

In terms of addresses, I believe the API is lacking (or we use a 
chain_parameter?) a way to indicate the service insertion model:
- L2 - The service can accept packets sent from any MAC (service NIC in 
promiscuous mode). The MAC address may be used to identify where the packet 
came from before it entered the chain.
- L3 -  The service expects packets to be routed to it. So the destination MAC 
of the packet must be set to the service's NIC's MAC.

Any thoughts on this?

Cathy> No restriction as long as the ports are routable. Originally we think we 
need to specify L2 and L3 service type. But later we found out it is not needed 
if we program the switch to set the next hop destination to the service 
function’s MAC. This way no matter whether it is L2 or L3, it always works.


Second, where is it expected that the match is applied?  The API for
creating a port chain doesn't associate the chain with a network, but
just matching "globally" doesn't make any sense.  If all ports are
expected to be on the same network, is the match applied for any traffic
entering that network from any port?

Here's what we were thinking for MidoNet:

use the logical_source_port in the flow classifier: when we render the SFC API 
in MidoNet's models we will associate the chain with the source port.

Cathy> Yes, that is the way to specify the flow classifier. Note that one or 
more flow classifiers can be associated with the same chain.

Our packet pipeline (for packets egressing the VM) is:

  1.  Port Mirroring
  2.  Service Chaining
  3.  Filtering (Port Security, anti-spoofing, Security Groups)

Do you think we can standardise on a single order in all implementations? We'd 
be happy to change the order if it makes sense.



I'm in Tokyo this week, so if the group working on this would like to
talk in person, that would be great too.

I'd love to be included.

Great topic, thanks!

Cathy> I discussed briefly with Russell in yesterday’s Neutron design session. 
If needed, we can meet in today’s Neutron NFV session.

Thanks,
Cathy


Pino


--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Russell,

Please see inline.

Regards,
Cathy

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, October 28, 2015 5:27 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List; Henry Fourie
Subject: Re: [neutron][networking-sfc] API clarification questions
> 
> First, does it assume that all of the neutron ports in a chain are on 
> the same Neutron network?  That keeps things simple.  If its intended 
> to allow a chain of ports on different networks, is it just required 
> that you pick ports that all have addresses routable from one port to 
> the next in the chain?
> 
> Cathy> It can allow a chain of ports on different networks as along it
> belongs to the same tenant. Yes, it is required that you pick ports 
> that all have addresses routable from one port to the next in the chain.

Thanks.  I think it would be good to clarify this in the API doc, so it's clear 
what makes a valid set of ports in a chain.

Cathy> Sure, will do. 

> An arbitrary set of ports can't always work, so there has to be some 
> bounds around what set of ports are valid to be in a chain.
> 
> Second, where is it expected that the match is applied?  The API for 
> creating a port chain doesn't associate the chain with a network, but 
> just matching "globally" doesn't make any sense.  If all ports are 
> expected to be on the same network, is the match applied for any 
> traffic entering that network from any port?
> 
> Cathy> As long as the ports are routable, they do not need to 
> Cathy> associated with
> the same network.

Let me rephrase the question ... where is the flow classifier applied?  What 
traffic exactly?  "All traffic on all networks accessible to the tenant who 
created the port chain" doesn't seem right to me, but the API doesn't seem to 
specify it.

Cathy> What traffic will go through the chain is specified in the flow 
classifier API. As I presented in the Neutron SFC session of the Summit, there 
are two ways to specify the type of flows. One is through specification of the 
source neutron port that a tenant's flow will originate and/or the destination 
neutron port that a tenant's flow will exit which means all traffic that 
originates from that port and/or terminates at that port needs to go through 
the chain. The other is through specification of the n-tuple of a tenant's 
flow. If it is the first specification, the flow classifier will locate at the 
host of the neutron port and the flow classifier can either run on the host or 
the vSwitch or a VM depending on implementation. If it is the second 
specification, then if the flow's IP or mac is specified, we can locate the 
host and program the host to do the flow classification, but if there is no 
information available to locate the host, then all hosts that could originate 
traffic 
 into the network will be programmed for classification of the flow. So to have 
better performance, we recommend the first way of specification. 

Thanks,
Cathy 



--
Russell
__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Gal Sagie]

Hi Pino,

Just one note on the order of the pipeline, shouldnt the security part be
before the service chaining (and also after)?
(Unless you only meant egress security and you still do the ingress before)

Gal.

On Wed, Oct 28, 2015 at 10:14 AM, Giuseppe (Pino) de Candia <
gdecan...@midokura.com> wrote:

> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant 
> wrote:
>
>> I read through the proposed SFC API here:
>>
>> http://docs.openstack.org/developer/networking-sfc/api.html
>>
>> I'm looking at implementing what would be required to support this API
>> in OVN.  I have a prototype, but I had to make some pretty big
>> assumptions, so I wanted to clarify the intent of the API.
>>
>> First, does it assume that all of the neutron ports in a chain are on
>> the same Neutron network?  That keeps things simple.  If its intended to
>> allow a chain of ports on different networks, is it just required that
>> you pick ports that all have addresses routable from one port to the
>> next in the chain?  An arbitrary set of ports can't always work, so
>> there has to be some bounds around what set of ports are valid to be in
>> a chain.
>>
>
> Hi Russell,
>
> We have similarly been experimenting with a MidoNet implementation of the
> SFC API.
>
> I hope there's no restriction on the location of the Neutron ports in a
> chain.
>
> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the packet
> came from before it entered the chain.
> - L3 -  The service expects packets to be routed to it. So the destination
> MAC of the packet must be set to the service's NIC's MAC.
>
> Any thoughts on this?
>
>
>>
>> Second, where is it expected that the match is applied?  The API for
>> creating a port chain doesn't associate the chain with a network, but
>> just matching "globally" doesn't make any sense.  If all ports are
>> expected to be on the same network, is the match applied for any traffic
>> entering that network from any port?
>>
>
> Here's what we were thinking for MidoNet:
>
> use the logical_source_port in the flow classifier: when we render the SFC
> API in MidoNet's models we will associate the chain with the source port.
>
> Our packet pipeline (for packets egressing the VM) is:
>
>1. Port Mirroring
>2. Service Chaining
>3. Filtering (Port Security, anti-spoofing, Security Groups)
>
>
> Do you think we can standardise on a single order in all implementations?
> We'd be happy to change the order if it makes sense.
>
>
>
>>
>> I'm in Tokyo this week, so if the group working on this would like to
>> talk in person, that would be great too.
>>
>
> I'd love to be included.
>
> Great topic, thanks!
>
> Pino
>
>
>>
>> --
>> Russell Bryant
>>
>> __
>> 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
>
>


-- 
Best Regards ,

The G.
__
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