[c-nsp] PfR

[Wes Smith]

There are two distinctly different PFR features. 
Pfr2. Circa 2010-present used automate IPsla probes and attempted to control protect and load balance traffic by adjusting route costs.  It could also route  specific traffic classes over different paths.  

Pfr3 is a much much different animal.  This is built into the border router input forwarding path.  Uses the perfmon features of the routers to track latency loss drop jitter etc. 

We are rolling this out this year. 
First for brownout detection. Then to  shift some traffic off mpls and onto Internet. 

Pfr3 is very dmvpn oriented.   Doesn't 'need' dmvpn, but it's clear that's where the focus is.  Dmvpn allows a common overlay on mpls and Internet and pfr does the smart quality aware routing. 
This is Ciscos new iwan architecture. Lots of focus. 

What we have found. ....
Only one wan facing link/tunnelper router/ per vrf.  This is a real pita for me, but probably not for service providers as each client would likely be vrf'd. 


Watch Jean Marc latest Berlin Cisco live pitches.  Always good.  
Lots of other iwan info there as well. 


Sent from my iPhone

> On Mar 24, 2016, at 1:09 PM, Arie Vayner <ariev at vayner.net> wrote:
> 
> Cisco has put a lot of effort into this functionality in the last 2 years.
> I would suggest looking at IWAN:
> http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Jan2015/CVD-IWANDesignGuide-JAN15.pdf
> 
> Arie
> 
>> On Thu, Mar 24, 2016 at 9:57 AM Saku Ytti <saku at ytti.fi> wrote:
>> 
>>> On 24 March 2016 at 18:34, Joel M Snyder <Joel.Snyder at opus1.com> wrote:
>>> I designed it into a network of about 90 sites (global, not US) and it
>> was
>>> not a resounding success.  The management was ugly, but more importantly
>> it
>>> just didn't play well with others and at some clear points wasn't
>> working at
>>> all.  It was pulled out in favor of a WAN opt solution (Cisco WaaS
>> appliance
>>> in that case).  I reviewed it again and did some testing for a larger
>>> network of 400+ sites recently, but the feature set wasn't measuring up
>> to
>>> the requirements and the customer stuck Riverbeds ahead of the IOS boxes
>> and
>>> is quite happy with the results.
>> 
>> Looks like PfR is lot more than just IP SLA udp jitter/icmp probe +
>> tracking. My comments were strictly on that, I've not done the
>> controller based PfR.
>> 
>> --
>>  ++ytti
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/