> My original thought was a new table of chains. Each chain has a list of
> service endpoints (originally i had this as logical ports, but it'd need
> to be IP or MAC addresses, I guess). A chain would also have a match
> defined in the same syntax used by ACLs. I imagined the implementation
> in a separate logical flow table.
Would the IP or MAC addresses be on same logical network or outside it?
> I wonder how much of this OPNFV has specified? This seems like the
> perfect sort of thing OPNFV can help specify and work with upstream
> projects to get implemented.
>> Yes, I think so too.
Will be at OPNFV summit to get clarity on SFC requirements.
Thanks,
Vikram
________________________________________
From: Ben Pfaff [b...@nicira.com]
Sent: Tuesday, November 03, 2015 1:29 PM
To: Russell Bryant
Cc: Thomas Graf; Dham, V; Justin Pettit; discuss@openvswitch.org
Subject: Re: [ovs-discuss] SFC using OVN
On Tue, Nov 03, 2015 at 04:15:40PM -0500, Russell Bryant wrote:
> On 11/03/2015 04:01 PM, Ben Pfaff wrote:
> > On Tue, Nov 03, 2015 at 03:45:45PM -0500, Russell Bryant wrote:
> >> In the meantime, we can be working on how to model this properly in
> >> OVN_Northbound, as well as trying to work out a reasonable
> >> implementation based on Geneve. The modeling in my prototype isn't
> >> expressive enough.
> >
> > The model that I proposed in Tokyo was to make redirection through a
> > chain one of the possible actions for ACLs in the OVN_Northbound
> > database. (I'm not claiming this is original or inspired; maybe you had
> > the same idea.)
>
> And have the chain be a list of parameters to the action?
Yes. That could be some kind of inline set of parameters in the ACL
table, or a reference to some new table.
> My original thought was a new table of chains. Each chain has a list of
> service endpoints (originally i had this as logical ports, but it'd need
> to be IP or MAC addresses, I guess). A chain would also have a match
> defined in the same syntax used by ACLs. I imagined the implementation
> in a separate logical flow table.
>
> I guess both sound like the same thing, really. It's just a matter of
> how strictly the data gets structured in OVN_Northbound. Doing it in
> ACLs sounds pretty convenient and actually makes good sense when
> thinking about where this fits into the logical flow stages.
Some differences:
* If chains are a separate table then one must define whether
ACLs are applied before or after service chains. If chains
are part of the ACL table then some ACLs could have higher
priority than chaining, which could be a useful way to drop
some packets without bothering to process them through chains.
* Only a single ACL can apply to a packet (on ingress or egress)
so using ACLs for chains would prevent doing connection
tracking ACLs for packets that pass through chains. I don't
know whether users would want to combine them but if so then
this would be a problem.
I guess another way to handle it would be to add a new chains table as
you suggest, and then add another ACL direction, so that you'd have
from-lport-pre-chains, from-lport-post-chains, and to-lport directions.
Sort of like prerouting, postrouting, etc. in iptables. At that point
I'm not sure that "direction" is the right vocabulary word but we can
paint that bikeshed when we get there.
> I wonder how much of this OPNFV has specified? This seems like the
> perfect sort of thing OPNFV can help specify and work with upstream
> projects to get implemented.
Yes, I think so too.
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
