Open Stack

Margaret <Margaret_Frances at cable.comcast.com> wrote:

> Hello Ihar,
>
> I have some comments and questions about your proposal.  My apologies if
> any of what I say here results from misunderstandings on my part.

Thanks a lot for the reply. I will try to clear up below.

>
> 1. I believe there are two sorts of redirection at play here.  The first
> involves inter-table traversal while the second allows a frame to exit the
> OF pipeline either by being sent to a different port or by being dropped.
> Some of what I say next makes use of this distinction.
>

I am not sure I understand what is inter-table traversal. My assumption was  
that extension tables defined for modification actions don’t redirect  
anywhere except back into table0 (using default flow rules we add to each  
table on its bootstrapping).

> 2. OpenFlow¹s Goto instruction directs a frame from one table to the next.
>  A redirection in this sense must be to a higher-numbered table, which is
> to say that OF pipeline processing can only go forward (see p.18, para.2
> of the 1.4.1 spec
> <https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
> specifications/openflow/openflow-switch-v1.4.1.pdf>).  However, OvS (at
> least v2.0.2) implements a resubmit action, which re-searches another
> table‹higher-, lower-, or even same-numbered‹and executes any actions
> found there in addition to any subsequent actions in the current flow
> entry.  It is by using resubmit that the proposed design could work, as
> shown in the ovs-ofctl command posted here
> <https://review.openstack.org/#/c/251738/1/neutron/agent/common/ovs_lib.py>
> .  (Maybe there are other ways, too.)  The resubmit action is a Nicira
> vendor extension that at least at one point, and maybe still, was known to
> be implemented only by OvS.  I mention this because I wonder if the
> proposed design (and my sample command) calls for flow traversal in a
> manner not explicitly supported by OpenFlow and so may not work in future
> versions of OvS.
>

Thanks for directions to specific OF features we can utilize! I believe we  
may assume some implementation of resubmit can be safely expected to be  
present in the OVS. We may refine API we rely on later if we see it  
deprecated.

> 3. Regarding the idea of sorting feature flows by kind: I believe that
> what is meant by a 'redirection flow table' is a table that could possibly
> remove the frame from OF pipeline processing‹i.e., by forwarding or
> dropping it.  Can you correct/confirm?
>

Yes, that’s the intent. I feel I need to dig OF documentation a bit so that  
I make myself more in line with terminology used there. Sorry for  
misunderstandings occurring due to vague terms used.

> 4. Even though the design promotes playing nice by means of feature flow
> kinds, I think that features might nevertheless still step on each others¹
> toes due to assumptions made about field content.  I¹m thinking, for
> instance, of two features whose in-place frame modifications should be
> done in a particular order.  Because of this, I¹m not sure that the
> granularity of the proposed design can guarantee feature cooperation.
> Maybe it would help to prioritize feature flows as ingress-processing
> (that is, the flow should be exercised as early as possible in the
> pipeline) versus egress-processing (the opposite) in addition to kind‹or
> maybe that is just what  the notion of feature flow kind calls for, at
> least in part.  Tied (tangential?) to this is the distinction that
> OpenFlow makes between an action list and an action set: the former is a
> series of actions that is applied to the frame immediately and in the
> order specified in the flow entry; the latter is a proper set of actions
> that is applied to the frame only upon its exit from the OF pipeline and
> in an order specified by protocol.  (Action set content is modified as the
> frame traverses the OF pipeline.)  Should action sets be disallowed?

I learned a bit more from you, again. :) Thanks!

I am not sure I completely follow the suggestion with prioritizing as  
ingress-processing. Can you elaborate?

I hope that we can leave unraveling corner case ordering issues for the 2nd  
phase of the feature and see how pressing it is once we start using the  
framework.

Based on what you wrote, probably action sets should then be discouraged.  
That said, I am not sure we should have control on what is used in  
extension tables. I envisioned we pass tables to extensions and allow them  
to manage them. If they break the flow, it’s sad but not strictly limiting  
types of flows that can be used by extensions seems to me a freedom to  
retain. What do you think?

>
> 5. Is it a correct rephrasing of the third bullet of the high-level design
> to say: each feature-specific flow entry in table 0 would be triggered
> only if the frame's relevant OF metadata has not already been updated as a
> result of the frame's previous traversal of the feature table.  I
> apologize if I¹m suggesting something here that you didn¹t mean.

That’s exactly what I meant. Thanks for proper reformulation of my vague  
thoughts!

> Hope this is helpful.

It is!

Ihar