On Wed, Nov 2, 2016 at 11:29 AM, Flavio Fernandes <[email protected]> wrote:
> > > On Nov 1, 2016, at 1:30 PM, Flaviof <[email protected]> wrote: > > > > > > > > On Tue, Nov 1, 2016 at 1:05 PM, John McDowall < > [email protected]>wrote: > > So we would have something like: > > > > > > > > $ ovn-nbctl acl-add sw0 to-lport 1003 'outport == "sw0-port1" && ip' > sfc-action sfc-stage external_ids:lsp_chain_id=”chain-id” > > > > > > > > The chain-id would be passed as metadata with the packet to the > ls_in_chain stage where it would be processed according to the current > state of its in/out ports in the chain. > > > > > > > > Where sfc is the stage and the action – would the SFC ACL Table have any > other action other than SFC? It seems a little redundant – not sure if > there is a better way though. > > > > > > > > > > Right. If I understood correctly, the sfc-stage is optional and may be > something we > > may add later on to ACLs. For now, having it all in a sigle stage will > not invalidate > > that effort. > > > > Using the example comand, my main 'focus' is actually in regards to what > else goes as > > external_ids. I can see that besides 'lsp_chain_id', we will need > 'last_hop_port', and > > possibly 'bidirectional'. Sounds right? > > > > I will send an email with a proposed schema+xml on this shortly. > > It's a pretty simple change [1], as expected. :) Does that jive well with > the changes > you had in mind? A small caveat here is in regards to additional attributes > the chain needs in order to create the end to end rules. That includes > 'chain_uuid', > 'last_hop_port' at a minimum. Other than using 'external_ids', I cannot > see where else > to provide them. Any better ideas? > Well defined options that OVN will interpret usually go into a column called "options", so I would add that instead of using external_ids. -- Russell Bryant
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
