<div dir="ltr">Hi Samuel,<div><br></div><div>We talked a bit in chat about this, but I wanted to reiterate a few things here for the rest of the group.  Comments in-line:</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Apr 30, 2014 at 6:10 AM, Samuel Bercovici <span dir="ltr"><<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We have compared the API the is in the blue print to the one described in Stephen documents.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Follows the differences we have found:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">L7PolicyVipAssoc is gone, this means that L7 policy reuse is not possible. I have added use cases 42 and 43 to show where such
 reuse makes sense.</span></p></div></div></blockquote><div><br></div><div>Yep, my thoughts were that:</div><div><ul><li>The number of times L7 policies will actually get re-used is pretty minimal. And in the case of use cases 42 and 43, these can be accomplished by duplicating the L7policies and rules (with differing actions) for each type of connection.</li>
<li>Fewer new objects is usually better and less confusing for the user. Having said this, a user advanced enough to use L7 features like this at all is likely going to be able to understand what the 'association' policy does.</li>
</ul><div>The main counterpoint you shared with me was (if I remember correctly):</div></div><div><ul><li>For different load balancer vendors, it's much easier to code for the case where a specific entire feature set that isn't available (ie. L7 switching or content modification functionality) by making that entire feature set modular. A driver in this case can simply return with a "feature not supported" error if anyone tries using L7 policies at all.</li>
</ul></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>

<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There is a mix between L7 content switching and L7 content modification, the API in the blue print only addresses L7 content
 switching. I think that we should separate the APIs from each other. I think that we should review/add use cases targeting L7 content modifications to the use cases document.</span></p></div></div></blockquote><div>Fair enough. There aren't many such use cases in there yet. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<u></u><u></u></span></p>
<p style="text-indent:.5in"><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>a.<span style="font:7.0pt "Times New Roman"">                  
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You can see this in L7Policy: APPEND_HEADER, DELETE_HEADER actions<u></u><u></u></span></p>

<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The action to redirect to a URL is missing in Stephen’s document. The 'redirect' action in Stephen’s document is equivalent
 to the “pool” action in the blue print/code.</span></p></div></div></blockquote><div>Yep it is. But this is actually pretty easily added.  We would just add the 'action' of "URL_REDIRECT" and the action_argument would then be the URL to which to redirect.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p>

<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>4)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">All the objects have their parent id as an optional argument (L7Rule.l7_policy_id, L7Policy.listener_id), is this a mistake?</span></p>
</div></div></blockquote><div>That's actually not a mistake--  a user can create "orphaned" rules in this model. However, the point was raised earlier by Brandon that it may make sense for members to be child objects of a specific pool since they can't be shared. If we do this for members, it also makes sense to do it for L7Rules since they also can't be shared. At which point the API for manipulating L7Rules would shift to:</div>
<div><br></div><div>/l7_policy/{policy_uuid}/l7_rules</div><div><br></div><div>And in this case, the parent L7Policy ID would be implicit.</div><div><br></div><div>(I'm all for this change, by the way.) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>5)<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There is also the additional behavior based on L3 information (matching the client/source IP to a subnet). This is addressed
 by L7Rule.type with a value of 'CLIENT_IP' and L7Rule.compare_type with a value of 'SUBNET'. I think that using Layer 3 type information should not be part of L7 content switching as the use cases I am aware of, might require more than just selecting a different
 pool (ex: user with ip from internet browsing to an https based application, might need to be secured using 2K SSL keys while internal users could use weaker keys)</span></p></div></div></blockquote><div>While it's true that having a way to manipulate this without being part of an HTTP or unwrapped HTTPS session is also useful--  it's still useful to be able to create L7 rules which also make decisions based on subnet.  (Notice also with TLS_SNI_Policies there is a 'hostname' attribute, and also with L7 rules there is a 'hostname' type of rule? Again, useful to have in two places, eh!)</div>
<div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I would like to state that although the WIKI describes the solution from a high level it is not totally in sync with the actual code.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The key thing which is missing is that, L7 Policies in a specific listener/vip are ordered (ordered list) and are processed in order so that the 1^st
 policy that has a match will be activated and traversal of the L7 policy list is topped as the processing is final (ex: redirect, pool, reject).
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This in effect means that L7 Policy form an ‘or’ condition between them.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">L7 Policies have an ordered list of L7 Rules, L7 Rules are processed by this order and also form an ‘or’ condition.</span></p>
</div></div></blockquote><div><br></div><div>Agreed, and I think my API works the same way. I will say though:  I did remove the 'order' attribute from L7Rules because if all the conditions that make up a policy are OR'ed together, then order no longer matters.  If we want to define a more feature-rich DSL here, then rule order would matter.  (Note that the order in which entire L7Policies appear still matters. The first one to match wins in the case of a 'redirect' match, eh.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">                -Avishay, Evgeny and Sam<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><br></p></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div>