Dear Anton, I believe that MPLS-TE FRR does not address tasks 2 through 5 in the same sense as it is required in IPFRR. Certainly, protecting LSP has to be calculated by SPF, signaled and RIB/FIB/HW properly updated. But these actions all done prior to when an MPLS-TE deemed protected. Upon Fault detection the only action required is on the PLR.
Regards, Greg On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov <[email protected]> wrote: > Hi all, > even though I put OSPF-FN draft in the subject it is the framework > approach FN-FRWK which draws more questions. At the very first line it > reads: > > This document describes an architectural work that competes with the >> IP Fast Re-Route (IPFRR) solution >> > > Lets compare speed of traffic restoration between the two. So, traditional > OSPF convergence time consists of the sum of: > > 1. Failure detection > 2. LSA origination > 3. Per-hop flooding > 4. SPF (delay and calculation itself) > 5. RIB/FIB/hardware update > > 3, 4 and 5 all can be significant depending on network size, number of > routes etc. > > FRR (both MPLS TE FRR and IPFRR) address 2-5. With good implementation FRR > should be by order of magnitude as fast as 1. > > FN addresses only 3. It doesn't address 4 and 5. As I wrote above in many > networks they are at least as significant as 3. > > So, by the speed of convergence FN doesn't look to come anywhere close to > FRR. > > > Now, lets look at FN from another perspective. Router announcing failure > doesn't benefit from FN. Its immediate neighbors do not benefit from FN > either - 1 hop traditional flooding should be as fast as 1 hop FN flooding. > It is only distant routers who benefit from the FN - and the farther is > router from the failure the bigger is gain. > On the other hand, if there exists path alternative to the failed one > then _typically_ it is not too far (in terms of hops) from the failing one. > I.e. from point of view of router which is 15 hops away from the point of > failure it is less likely that routes will change. BTW, ordered FIB approach > builds on concept that 'old' routes on remote routers do not cause traffic > blackholing or loops. > > The big problem with FN approach is that routers remote from the point of > failure benefit most - but at the same time their convergence is the least > important for end-to-end traffic restoration. > The worst case network for FN is fully meshed area. Since each router is > 1 hop away from every other one FN will give no benefits. > The best case network for FN is an area consisting of one big ring. In > this case alternative path is on diametrically opposite end of the network > and convergence of remote routers is crucial. > > So yeah, FN will help remote routers to converge faster. But how much > this will improve end-to-end traffic restoration in real networks? I suspect > not much. Some degree of meshiness in network topology is the norm. > > FN is an interesting proposal but it is very far from being convincing. > Pitching FN against FRR is a mistake. > > -- > Anton > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
