I think Pavel is speaking of the case where the PLR is more than one hop from the ingress node. It is very topology dependent but you can end up with bypasses or detours taking a different path than the IGP especially when its a few hops from the ingress node. Also ring topologies introduce wrapping which can add congestion in the opposite direction. Partial mesh alleviates some of that but most networks have some kind of ring element somewhere.
Phil On Jan 26, 2012, at 4:01 PM, Keegan Holley <keegan.hol...@sungard.com> wrote: > 2012/1/26 Pavel Lunin <plu...@senetsy.ru>: >> >> >>> >>> 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 juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
