<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:824662251;
mso-list-type:hybrid;
mso-list-template-ids:-1184729880 1792017842 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:20.4pt;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ryan,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> I agree that having rules in the ACL table with actions that would steer the packets to SFC<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Processing would be a good approach.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:20.4pt;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Louis<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Moats [mailto:rmoats@us.ibm.com]
<br>
<b>Sent:</b> Tuesday, May 31, 2016 10:18 AM<br>
<b>To:</b> John McDowall<br>
<b>Cc:</b> Justin Pettit; Russell Bryant; Ben Pfaff; OpenStack Development Mailing List; discuss@openvswitch.org<br>
<b>Subject:</b> Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><tt><span style="font-size:10.0pt">John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>> wrote on 05/26/2016 11:08:43 AM:</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>> From: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt></span><br>
<tt><span style="font-size:10.0pt">> To: Ryan Moats/Omaha/IBM@IBMUS</span></tt><br>
<tt><span style="font-size:10.0pt">> Cc: Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>>, "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>"
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, Justin Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>,
</tt><br>
<tt>> "OpenStack Development Mailing List" <openstack-</tt><br>
<tt>> <a href="mailto:dev@lists.openstack.org">dev@lists.openstack.org</a>>, Russell Bryant <<a href="mailto:russell@ovn.org">russell@ovn.org</a>></tt></span><br>
<tt><span style="font-size:10.0pt">> Date: 05/26/2016 11:09 AM</span></tt><br>
<tt><span style="font-size:10.0pt">> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</span></tt><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Ryan,</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> My (incomplete) throughts about the flow-classifier are:</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> 1) ACL’s are more about denying access, while the flow classifier </tt><br>
<tt>> is more about steering selected traffic to a path, so we would need </tt><br>
<tt>> to deny-all except allowed flows.</tt></span><br>
<tt><span style="font-size:10.0pt">> 2) The networking-sfc team has done a nice job with the drivers so
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> ovn has its own flow-classifier driver which allows us to align the </tt><br>
<tt>> flow-classifier with the matches supported in ovs/ovn, which could </tt><br>
<tt>> be an advantage.</tt></span><br>
<br>
<tt><span style="font-size:10.0pt">The ACL table has a very simple flow-classifier structure and I'd</span></tt><br>
<tt><span style="font-size:10.0pt">like to see if that can be re-used for the purpose of the SFC classifier</span></tt><br>
<tt><span style="font-size:10.0pt">(read that I feel the Logical_Flow_Classifier table is too complex).</span></tt><br>
<tt><span style="font-size:10.0pt">My initial thoughts were to look at extending the action column and</span></tt><br>
<tt><span style="font-size:10.0pt">using the external-ids field to differentiate between legacy ACLs and</span></tt><br>
<tt><span style="font-size:10.0pt">those that are used to intercept traffic and route it to an SFC.</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> What were your thoughts on the schema it adds a lot of tables and a </tt><br>
<tt>> lot of commands – cannot think of anyway around it</tt></span><br>
<br>
<tt><span style="font-size:10.0pt">In this case, I think that the other tables are reasonable and I'm
</span></tt><br>
<tt><span style="font-size:10.0pt">uncomfortable trying to stretch the existing tables to cover that</span></tt><br>
<tt><span style="font-size:10.0pt">information...</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">Ryan</span></tt><br>
<br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Regards</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> John</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> From: Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>></tt><br>
<tt>> Date: Wednesday, May 25, 2016 at 9:12 PM</tt><br>
<tt>> To: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> Cc: Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>>, "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <</tt><br>
<tt>> <a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, Justin Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, OpenStack</tt><br>
<tt>> Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Russell Bryant <</tt><br>
<tt>> <a href="mailto:russell@ovn.org">russell@ovn.org</a>></tt><br>
<tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>> wrote on 05/25/2016
</tt><br>
<tt>> 07:27:46 PM:</tt><br>
<tt>> </tt><br>
<tt>> > From: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> > To: Ryan Moats/Omaha/IBM@IBMUS</tt><br>
<tt>> > Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, "OpenStack
</tt><br>
<tt>> > Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Ben
</tt><br>
<tt>> > Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>>, Justin Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, Russell Bryant</tt><br>
<tt>> > <<a href="mailto:russell@ovn.org">russell@ovn.org</a>></tt><br>
<tt>> > Date: 05/25/2016 07:28 PM</tt><br>
<tt>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> > </tt><br>
<tt>> > Ryan,</tt><br>
<tt>> > </tt><br>
<tt>> > Ok – I will let the experts weigh in on load balancing.</tt><br>
<tt>> > </tt><br>
<tt>> > In the meantime I have attached a couple of files to show where I am</tt><br>
<tt>> > going. The first is sfc_dict.py and is a representation of the dict </tt>
<br>
<tt>> > I am passing from SFC to OVN. This will then translate to the </tt><br>
<tt>> > attached ovn-nb schema file.</tt><br>
<tt>> > </tt><br>
<tt>> > One of my concerns is that SFC almost doubles the size of the ovn-nb</tt><br>
<tt>> > schema but I could not think of any other way of doing it.</tt><br>
<tt>> > </tt><br>
<tt>> > Thoughts?</tt><br>
<tt>> > </tt><br>
<tt>> > John</tt><br>
<tt>> </tt><br>
<tt>> The dictionary looks fine for a starting point, and the more I look</tt><br>
<tt>> at the classifier, the more I wonder if we can't do something with</tt><br>
<tt>> the current ACL table to avoid duplication in the NB database</tt><br>
<tt>> definition...</tt><br>
<tt>> </tt><br>
<tt>> Ryan</tt><br>
<tt>> </tt><br>
<tt>> > From: Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>></tt><br>
<tt>> > Date: Wednesday, May 25, 2016 at 7:27 AM</tt><br>
<tt>> > To: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> > Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, OpenStack
</tt><br>
<tt>> > Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Ben Pfaff <</tt><br>
<tt>> > <a href="mailto:blp@ovn.org">blp@ovn.org</a>>, Justin Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, Russell Bryant <</tt><br>
<tt>> <a href="mailto:russell@ovn.org">russell@ovn.org</a></tt><br>
<tt>> > ></tt><br>
<tt>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> > </tt><br>
<tt>> > John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>> wrote on 05/24/2016
</tt><br>
<tt>> > 06:33:05 PM:</tt><br>
<tt>> > </tt><br>
<tt>> > > From: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> > > To: Ryan Moats/Omaha/IBM@IBMUS</tt><br>
<tt>> > > Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, "OpenStack
</tt><br>
<tt>> > > Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></tt><br>
<tt>> > > Date: 05/24/2016 06:33 PM</tt><br>
<tt>> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> > > </tt><br>
<tt>> > > Ryan,</tt><br>
<tt>> > > </tt><br>
<tt>> > > Thanks for getting back to me and pointing me in a more OVS like </tt><br>
<tt>> > > direction. What you say makes sense, let me hack something together.</tt><br>
<tt>> > > I have been a little distracted getting some use cases together. The</tt><br>
<tt>> > > other area is how to better map the flow-classifier I have been </tt><br>
<tt>> > > thinking about it a little, but I will leave it till after we get </tt>
<br>
<tt>> > > the chains done.</tt><br>
<tt>> > > </tt><br>
<tt>> > > Your load-balancing comment was very interesting – I saw some </tt><br>
<tt>> > > patches for load-balancing a few months ago but nothing since. It </tt>
<br>
<tt>> > > would be great if we could align with load-balancing as that would </tt>
<br>
<tt>> > > make a really powerful solution.</tt><br>
<tt>> > > </tt><br>
<tt>> > > Regards</tt><br>
<tt>> > > </tt><br>
<tt>> > > John</tt><br>
<tt>> > </tt><br>
<tt>> > John-</tt><br>
<tt>> > </tt><br>
<tt>> > For the load balancing, I believe that you'll want to look at</tt><br>
<tt>> > openvswitch's select group, as that should let you set up multiple</tt><br>
<tt>> > buckets for each egress port in the port pairs that make up a port</tt><br>
<tt>> > group.</tt><br>
<tt>> > </tt><br>
<tt>> > As I understand it, Table 0 identifies the logical port and logical</tt><br>
<tt>> > flow. I'm worried that this means we'll end up with separate bucket</tt><br>
<tt>> > rules for each ingress port of the port pairs that make up a port</tt><br>
<tt>> > group, leading to a cardinality product in the number of rules.</tt><br>
<tt>> > I'm trying to think of a way where Table 0 could identify the packet</tt><br>
<tt>> > as being part of a particular port group, and then I'd only need one</tt><br>
<tt>> > set of bucket rules to figure out the egress side. However, the</tt><br>
<tt>> > amount of free metadata space is limited and so before we go down</tt><br>
<tt>> > this path, I'm going to pull Justin, Ben and Russell in to see if</tt><br>
<tt>> > they buy into this idea or if they can think of an alternative.</tt><br>
<tt>> > </tt><br>
<tt>> > Ryan</tt><br>
<tt>> > </tt><br>
<tt>> > > </tt><br>
<tt>> > > From: Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>></tt><br>
<tt>> > > Date: Monday, May 23, 2016 at 9:06 PM</tt><br>
<tt>> > > To: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> > > Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, OpenStack
</tt><br>
<tt>> > > Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></tt><br>
<tt>> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> > > </tt><br>
<tt>> > > John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>> wrote on 05/18/2016
</tt><br>
<tt>> > > 03:55:14 PM:</tt><br>
<tt>> > > </tt><br>
<tt>> > > > From: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> > > > To: Ryan Moats/Omaha/IBM@IBMUS</tt><br>
<tt>> > > > Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, "OpenStack
</tt><br>
<tt>> > > > Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></tt><br>
<tt>> > > > Date: 05/18/2016 03:55 PM</tt><br>
<tt>> > > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > Ryan,</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > OK all three repos and now aligned with their masters. I have done </tt>
<br>
<tt>> > > > some simple level system tests and I can steer traffic to a single </tt>
<br>
<tt>> > > > VNF. Note: some additional changes to networking-sfc to catch-up </tt>
<br>
<tt>> > > > with their changes.</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > <a href="https://github.com/doonhammer/networking-sfc">https://github.com/doonhammer/networking-sfc</a>
</tt><br>
<tt>> > > > <a href="https://github.com/doonhammer/networking-ovn">https://github.com/doonhammer/networking-ovn</a></tt><br>
<tt>> > > > <a href="https://github.com/doonhammer/ovs">https://github.com/doonhammer/ovs</a>
</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > The next tasks I see are:</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > 1. Decouple networking-sfc and networking-ovn. I am thinking that I </tt>
<br>
<tt>> > > > will pass a nested port-chain dictionary holding port-pairs/port-</tt><br>
<tt>> > > > pair-groups/flow-classifiers from networking-sfc to networking-ovn.</tt><br>
<tt>> > > > 2. Align the interface between networking-ovn and ovs/ovn to match </tt>
<br>
<tt>> > > > the nested dictionary in 1.</tt><br>
<tt>> > > > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-</tt><br>
<tt>> > chain model.</tt><br>
<tt>> > > > 4. Add ability to support chain of port-pairs</tt><br>
<tt>> > > > 5. Think about flow-classifiers and how best to map them, today I </tt>
<br>
<tt>> > > > just map the logical-port and ignore everything else.</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > Any other suggestions/feedback?</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > Regards</tt><br>
<tt>> > > > </tt><br>
<tt>> > > > John</tt><br>
<tt>> > > </tt><br>
<tt>> > > John-</tt><br>
<tt>> > > </tt><br>
<tt>> > > (Sorry for sending this twice, but I forgot that text/html is not liked</tt><br>
<tt>> > > by the mailing lists ...)</tt><br>
<tt>> > > </tt><br>
<tt>> > > My apologies for not answering this sooner - I was giving a two day</tt><br>
<tt>> > > training on Tues/Wed last week and came back to my son graduating</tt><br>
<tt>> > > from HS the next day, so things have been a bit of a whirlwind here.</tt><br>
<tt>> > > </tt><br>
<tt>> > > Looking at the github repos, I like the idea of passing a dictionary</tt><br>
<tt>> > > from networking-sfc to networking-ovn. The flow classifiers should</tt><br>
<tt>> > > be relatively straightforward to map to ovs match rules (famous last</tt><br>
<tt>> > > words)...</tt><br>
<tt>> > > </tt><br>
<tt>> > > I've probably missed an orbit here, but in the ovn-northd implementation,</tt><br>
<tt>> > > I was expecting to find service chains in the egress and router pipelines</tt><br>
<tt>> > > in addition to the ingress pipeline (see below for why I think a service</tt><br>
<tt>> > > chain stage in the egress pipeline makes sense ...)</tt><br>
<tt>> > > </tt><br>
<tt>> > > Also, in the ovn-northd implementation, I'm a little disturbed to see the</tt><br>
<tt>> > > ingress side of the service chain sending packets to output ports - I</tt><br>
<tt>> > > think that a more scalable (and more "ovs-like" approach) would be to</tt><br>
<tt>> > > match the egress side of a port pair in the chaining stage of the</tt><br>
<tt>> > > ingress pipeline, with an action that set the input port register.</tt><br>
<tt>> > > Then the egress pipeline would have a chaining stage where the output</tt><br>
<tt>> > > port register would be set based on the ingress port of the next port</tt><br>
<tt>> > > pair in the chain and the packet being punted to the proper output port</tt><br>
<tt>> > > in the last table. That should automagically build your function chain</tt><br>
<tt>> > > and provide the basis for bucketizing multiple ingress ports for the</tt><br>
<tt>> > > next port group to support hash based load balancing.</tt><br>
<tt>> > > </tt><br>
<tt>> > > Does that make sense?</tt><br>
<tt>> > > </tt><br>
<tt>> > > Ryan[attachment "ovn-nb.ovsschema.sfc" deleted by Ryan Moats/</tt><br>
<tt>> > Omaha/IBM] [attachment "sfc_dict.py" deleted by Ryan Moats/Omaha/IBM] </tt>
</span><o:p></o:p></p>
</div>
</body>
</html>