PfR goes beyond congestion.<div><br></div><div><div>QoS configs are static and they denpend on the path chosen by the routing protocol. If the path has a considereable delay, as long as adjacencies are not affected, no routing protocol will reroute part of traffic (eg VoIP traffic) to a different path automagically.</div>
<div><br></div><div>PfR offers the abillity to pick a diferent path to diferent traffic/traffics if the one chosen by the routing protocol goes out of the policy.</div><div><br></div><div>I'm no Cisco pimp, in fact, I've been working with Foundry/Brocade products for quite a time but I must recognize that they don't have this kind of inovation. </div>
<div><br></div><div>When it comes about features and inovation Cisco, is centuries ahead.</div><div><br></div><div><br><div class="gmail_quote">2012/2/4 George B. <span dir="ltr"><<a href="mailto:georgeb@gmail.com">georgeb@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":15l">My personal feeling is that if you are resorting to such gymnastics to avoid congestion, then there might be problems at layer 8 in the organization and you are really just routing around that.<br>
</div></blockquote></div><br></div></div>