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

From: Anton Smirnov <[email-masked]>
Date: Mon, 11 Apr 2011 22:54:41 +0200

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 11 Apr 2011 16:12:26 -0700

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-masked]> wrote:

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 11 Apr 2011 23:16:28 -0400

In message <BANLkTinDb-P=[email-masked]>
Greg Mirsky writes:
>  
> 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

Greg,

IPFRR does not need tasks 2 through 5 either.  OTOH, IPFRR coverage is
often less than full coverage.

In both MPLS FRR and IPFRR, if protection works it is handled entirely
by the PLR.  In IPFRR, some PLRs have no fast protection and have to
rely on flooding.  In IPFRR and MPLS FRR sometimes unexpected multiple
failures occur since a previously unknown shared resource is
discovered the hard way or an extroidinary event occurs (ie: two
fibers on same fault line, etc).  In this case even protection from
the MPLS FRR PLR doesn't work.

In MPLS if a reroute is required, the CSPF load being N^2 log N (order
N CSPF computation have to be run), the LSA flooding has no
significant impact at all.  In IPFRR where only one SPF has to be run,
flooding is still not the primary contributor to convergence time.  It
may be a combination of 4 and 5 below.

Curtis

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 11 Apr 2011 21:45:07 -0700

Hi Curtis,
thank you for the explanation on IPFRR. I know that things are sometimes are
not what we call them  but I believe that if MPLS FRR doesn't work for some
reason and LSP rerouted to restore service it's not FRR. Would IPFRR still
be considered FRR if restoration of connectivity relies on flooding  and
route convergence, not on use of pre-calculated RIB?

Regards,
Greg

On Mon, Apr 11, 2011 at 8:16 PM, Curtis Villamizar <[email-masked]> wrote:

> traditional
> FRR
> many
> to
> failure
> point of
> In

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 12 Apr 2011 10:06:24 +0200

Hi Greg,

 > Would
 > IPFRR still be considered FRR if restoration of connectivity relies on
 > flooding

I don't understand the question. Failed IPFRR is still FRR. But failed one.
    We all know that each technology has its limitations. Not full 
coverage is known limitation of IPFRR. And it is also understood that 
when IPFRR fails routers have to resort to traditional convergence. But 
this doesn't change the fact that flooding is not part of IPFRR. 
Flooding is part of traditional convergence.
    Flooding and traditional convergence are required even if IPFRR 
succeeds because router can't run forever on repair routes. So flooding 
is always part of the bigger picture, it just is not part of IPFRR 
technology itself.

Anton

On 04/12/2011 06:45 AM, Greg Mirsky wrote:
> Hi Curtis,
> thank you for the explanation on IPFRR. I know that things are sometimes
> are not what we call them  but I believe that if MPLS FRR doesn't work
> for some reason and LSP rerouted to restore service it's not FRR. Would
> IPFRR still be considered FRR if restoration of connectivity relies on
> flooding  and route convergence, not on use of pre-calculated RIB?
>
> Regards,
> Greg
>
> On Mon, Apr 11, 2011 at 8:16 PM, Curtis Villamizar <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     In message <BANLkTinDb-P=[email-masked]
>     <mailto:[email-masked]>>
>     Greg Mirsky writes:
>      >
>      > Dear Anton,
>      >
>      > On Mon, Apr 11, 2011 at 1:54 PM, Anton Smirnov
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > >   Hi all,

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 12 Apr 2011 16:18:13 -0400

In message <[email-masked]>
Greg Mirsky writes:
>  
> Hi Curtis,
>  
> thank you for the explanation on IPFRR. I know that things are
> sometimes are not what we call them but I believe that if MPLS FRR
> doesn't work for some reason and LSP rerouted to restore service it's
> not FRR. Would IPFRR still be considered FRR if restoration of
> connectivity relies on flooding and route convergence, not on use of
> pre-calculated RIB?
>  
> Regards,
> Greg

Greg,

Call it what you want.  Multiple failures where MPLS protection
doesn't work is reality and has to be dealt with.  The alternative is
transport style multiple hour outages where single fault protection is
backed up only by manual intervention (an apparent goal of TP).

Curtis