On Jan 26, 2012, at 4:01 PM, Keegan Holley <[email protected]> wrote:
> 2012/1/26 Pavel Lunin <[email protected]>: >> >> >>> >>> why would FRR LSP's take a route different than what the IGP would >>> converge to. >> >> >> Because FRR uses a path from a different entry (PLP) to probably a different >> exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) >> is a path from head-end to tail-end. Whether this happens often or rare, the >> need to care how your detours are calculated is itself a big enough >> headache. > > That's not how FRR works at least for RSVP. It pretty much just > re-runs cspf with something removed. So it's the same route your IGP > would choose if said "thing" went dark. I don't have many obscure > paths where I wouldn't want traffic to go so I can't really comment on > your earlier idea. That being said I've never seen FRR choose a path > worse than the path the IGP would choose. It's just preselects that > path and pre-signals it. I'm sure there are failure scenarios though. > > >> >>>> What the VRF-based Internet users will definitely notice is (looks like >>>> RAS >>>> is tired of telling this story) is ICMP tunneling and consequent hard to >>>> interpret delay values. People are very suspicious to the numbers. This >>>> is >>>> almost impossible to explain, that the numbers, traceroute shows, have >>>> nothing to do with their kitty-photos-not-loading problem. >>> >>> Hey kitty photos are serious business especially if you are facebook >>> stalking the aforementioned kitty. >> >> >> Absolutely. This is why in case of issues you should not waste time for >> explaining why your core router is 200ms away from the previous hop. >> > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
