Margaret <margaret_fran...@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
__________________________________________________________________________
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
