Re: [OSPF] draft-kini-ospf-fast-notification-01

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>