<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Ryan,</div>
<div><br>
</div>
<div>Hopefully – just wanted to make sure it was there.</div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, May 31, 2016 at 10:02 AM<br>
<span style="font-weight:bold">To: </span>John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>><br>
<span style="font-weight:bold">Cc: </span>Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>>, "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, Justin Pettit
<<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Russell Bryant <<a href="mailto:russell@ovn.org">russell@ovn.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>
</div>
<div><br>
</div>
<div>
<div>
<p><tt>John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>> wrote on 05/26/2016 10:59:48 AM:<br>
<br>
> From: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>></tt><br>
<tt>> To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</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>>, Justin
<br>
> Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, OpenStack Development Mailing List
<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Russell Bryant <<a href="mailto:russell@ovn.org">russell@ovn.org</a>></tt><br>
<tt>> Date: 05/26/2016 11:00 AM</tt><br>
<tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> <br>
> Ryan,</tt><br>
<tt>> <br>
> Agree with your description of the problem. The only thing I would <br>
> add is that in the case of bi-directional chains the return flows <br>
> need to go through the same VNF(Port-pair).</tt><br>
<br>
<tt>I'm pretty sure that is caught automagically, isn't it?</tt><br>
<br>
<tt>Ryan</tt><br>
<br>
<tt>> <br>
> Regards</tt><br>
<tt>> <br>
> John</tt><br>
<tt>> <br>
> From: Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>><br>
> Date: Wednesday, May 25, 2016 at 9:29 PM<br>
> To: Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>><br>
> Cc: "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, John McDowall <<br>
> <a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>>, Justin Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>,
<br>
> OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> >, Russell Bryant <<a href="mailto:russell@ovn.org">russell@ovn.org</a>><br>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br>
<tt>> <br>
> Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>> wrote on 05/25/2016 07:44:43 PM:<br>
> <br>
> > From: Ben Pfaff <<a href="mailto:blp@ovn.org">blp@ovn.org</a>><br>
> > To: Ryan Moats/Omaha/IBM@IBMUS<br>
> > Cc: John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>>,
<br>
> > "<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>" <<a href="mailto:discuss@openvswitch.org">discuss@openvswitch.org</a>>, OpenStack
<br>
> > Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Justin<br>
> > Pettit <<a href="mailto:jpettit@ovn.org">jpettit@ovn.org</a>>, Russell Bryant <<a href="mailto:russell@ovn.org">russell@ovn.org</a>><br>
> > Date: 05/25/2016 07:44 PM<br>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>
> > <br>
> > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote:<br>
> > > As I understand it, Table 0 identifies the logical port and logical<br>
> > > flow. I'm worried that this means we'll end up with separate bucket<br>
> > > rules for each ingress port of the port pairs that make up a port<br>
> > > group, leading to a cardinality product in the number of rules.<br>
> > > I'm trying to think of a way where Table 0 could identify the packet<br>
> > > as being part of a particular port group, and then I'd only need one<br>
> > > set of bucket rules to figure out the egress side. However, the<br>
> > > amount of free metadata space is limited and so before we go down<br>
> > > this path, I'm going to pull Justin, Ben and Russell in to see if<br>
> > > they buy into this idea or if they can think of an alternative.<br>
> > <br>
> > I've barely been following the discussion, so a recap of the question<br>
> > here would help a lot.<br>
> > <br>
> <br>
> Sure (and John gets to correct me where I'm wrong) - the SFC proposal<br>
> is to carry a chain as a ordered set of port groups, where each group <br>
> consists of multiple port pairs. Each port pair consists of an ingress<br>
> port and an egress port, so that traffic is load balanced between<br>
> the ingress ports of a group. Traffic from the egress port of a group <br>
> is sent to the ingress port of the next group (ingress and egress here<br>
> are from the point of view of the thing getting the traffic).<br>
> <br>
> I was suggesting to John that from the view of the switch, this would<br>
> be reversed in the openvswitch rules - the proposed CHAINING stage<br>
> in the ingress pipeline would apply the classifier for traffic entering<br>
> a chain and identify traffic coming from an egress SFC port in the<br>
> midst of a chain. The egress pipeline would identify the next ingress SFC<br>
> port that gets the traffic or the final destination for traffic exiting<br>
> the chain.<br>
> <br>
> Further, I pointed him at the select group for how traffic could be<br>
> load balanced between the different ports that are contained in a port<br>
> group, but that I was worried that I'd need a cartesian product of rules<br>
> in the egress chain stage. Having thought about this some more, I'm<br>
> realizing that I'm confused and the number of rules should not be that<br>
> bad:<br>
> <br>
> - Table 0 will identify the logical port the traffic comes from<br>
> - The CHAINING stage of the ingress pipeline can map that logical<br>
> port information to the port group the port is part of.<br>
> - The CHAINING stage of the egress pipeline would use that port<br>
> group information to select the next logical port via a select group.<br>
> <br>
> I believe this requires a total number of rules in the CHAINING stages<br>
> of the order of the number of ports in the service chain.<br>
> <br>
> The above is predicated on carrying the port group information from<br>
> the ingress pipeline to the egress pipeline in metadata, so I would<br>
> be looking to you for ideas on where this data could be carried, since<br>
> I know that we don't have infinite space for said metadata...<br>
> <br>
> Ryan<br>
</tt><br>
</p>
</div>
</div>
</span>
</body>
</html>