Open Stack

Hello Ihar,

On 12/17/15, 11:00 AM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:

>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).

OpenFlow’s Goto instruction and OvS’ resubmit action both result in
inter-table traversal in the sense I meant above.  This is as opposed to
what you've called a 'redirection flow table,' which sends the packet out
of the pipeline altogether.  I wanted to distinguish these two things in
part because the proposal describes table 0 flow entries ‘redirecting'
frames to another OF table and vice versa.

>
>>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/on
>>f-
>>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.p
>>y>
>>.  (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?

You and Rosella have had a subsequent conversation that I think addresses
my concerns.  But to continue my earlier thought: if multiple extensions
actually might modify the same frame elements, and in a way that would
change behavior based on ordering: I was thinking that within the category
of frame-modifying flows, for example, feature flows could be prioritized
in part on the basis of whether they should occur earlier or later in
pipeline processing.

The example that prompted my thoughts here, by the way, was MAC learning,
which of course isn’t either frame-modifying or “redirection” (aka
pipeline exiting).  So maybe this could be another table-type:
flow-entry-modifying.

>
>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?

I think things about extension freedom and feature segregation that are at
tension with each other and with my earlier question.  Re table 0: I think
that every flow entry in table 0 (putting aside the table-miss entry)
should be maximally filtered: the extension designers should be
encouraged--or required, if that is a coherent possibility--to filter to
the greatest degree possible.  This enhances feature segregation and
performance, and I can’t see that it has any affect on extension freedom
(does it?).  Re the feature tables themselves: beyond the broadest scope,
I can’t see policing things—or wanting to, or, if we did want to, of being
remotely successful at it—in order to prevent or even minimize their
possible interactions with other extensions’ concerns.  The broad scope I
just mentioned includes the two default actions you described.  I don’t
know enough about the circumstances under which actions sets would be used
in order to know if even discouraging them also falls under this scope.
(Maybe action sets are another feature-flow type?)  A possibly related
topic: preventing/discouraging/doing nothing about a feature table's
sending a frame to a table other than table 0.

>
>>
>>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
>
>__________________________________________________________________________
>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
>
>