Subject: Re: Reply to comments -- Comparison between FAR and OSPF - FRR

From: [email-masked]
Date: Wed, 23 Jul 2014 10:00:47 +0800

Hello Curtis,

Thank you for your comments.
But from what did you get conclusion of 'research projects'? We not only 
have a deployment experience but also strict large-scale system data 
analysis.

Following is my reply:
'No SPF is required for FRR to provide protection, restoring traffic flow 
though sometimes on a suboptimal path.'
--Is FRR only used within domain? If so, it can be counted as a drawback. 
And LDP FRR cannot guarantee that the calculated path is the optimal path, 
leading to the emergence of new link congestion. But FAT TREE architecture 
network is a non-blocking network.

'One commercial CSPF measured about a decade ago completed in 30-40msec on 
a test topology of 450.  That was on a 300 MHz or less PPC or Pentium-2.
Todays processors are an order of magnitude faster, so we could expect 
(with order NlogN scaling of SPF) to get about the same SPF time on a 
topology of 4K or more nodes with no improvements in software.'
--As seen from the above CSPF business application data, there is a linear 
correlation between the convergence time and the number of topologies, 
while it is not sensitive to the FAR. 
To compare the FRR and FRR, the working process of the LDP FRR technology 
is described as follows:
1) Running LDP protocol in the network, it works as DU (downstream 
independent) label distribution + orderly label control + free label 
retention. (Disadvantage :additional protocol overhead)

In the above case, there are two paths from R1 to R5, R5 initiates 
multi-label mapping message to the upstream. Eventually, R2 and R3 
respectively assign labels to R1 for reaching R5, among which, the label 
distributed by R2 is the primary label, the label distributed by R3 can be 
used as a backup. (Disadvantage: the irregular topology leads to complex 
routing and prone to cause more serious link block)

2) Specify one equipment port of the LSR as the backup of another 
equipment port.

3) Equipment maintenance label forwarding table: As the port backup has 
not been implemented, one label forwarding table has only one next hop and 
label, and the label is distributed for FEC by the LDP peer connected to 
the next hop of the routing of FEC. After the port backup is implemented, 
if the next hop of a label forwarding table is the protected port, add a 
next hop and label for the entry, and the label is distributed for FEC by 
the LDP peer connected to the backup next hop. (Disadvantage: large 
protocol database overhead and processing overhead)

4) Equipment maintenance of the working status of each port 
(normal/failure).

5) Packets reach the next hop, and are forwarded to the destination 
according to the corresponding label forwarding table. 

It can be seen from the above FRR processing that FRR has the following 
disadvantages compared to FAR:

1) Additional protocol overhead: For the protection of links, nodes and 
paths, it is necessary to set up a backup LSP respectively, which causes 
unnecessary overhead and complex protocol processing; (there is no such 
protocol overhead for FAR, and because FAR is based on regular topology, 
path protection and switching process are simple.)

2) Backup LSP failures may exist. As there is no protection mechanism, it 
cannot fast reroute when it fails; (FatTree network architecture has 
multiple natural selection.) 

3) There is a linear correlation between the convergence time and the 
number of topologies, while it is not sensitive to the FAR.

4) LDP FRR cannot guarantee that the calculated path is the optimal path, 
leading to the emergence of new link congestion. But FAT TREE architecture 
network is a non-blocking network.

Best.

Richard

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 24 Jul 2014 12:29:46 +0000

hi liu,

some comments on your slides showed in rtgwg.

http://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-5.pptx

slide6:

- there are exisiting productional networks of OSPF, BGP which are

operated with packet loss no longer than app 30ms (link/node failure), irrespective of FIB size.

- if your OSPF code is 500K lines of code, you must have a lot of comments and ascii art in that code ;-) - usually a link state protocol has a code complexity of 50-90K LoC, same goes for BGP.

slide 7:

i fail to see why SPF calculation times is a problem.

today state of the art is to calculate a 1000 node topology in 1ms

on a 2Ghz x86 processor.

slide 9:

LSA refreshes do not trigger SPF, so the complexity on precessing a LSA

refresh is figuring out if there was a change or not. if there was no

topological change the refreshed LSA gets installed in the LSDB and

move ahead, no SPF, no RIB/FIB update.

slide10:

we can deploy OSPF and IS-IS in single areas today with thousands of nodes.

if we want to go beyond that we have to perhaps adjust some of the backoff and pacing  timers (some of them are unchanged since 15 years) and would benefit from lowering for faster initial LSDB sync etc.

slide18:

the test results do not reflect what the state of the art of the industry is

and as such misleading.

additional comments see inline

/hannes

________________________________
From: rtgwg <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, July 23, 2014 4:00
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Reply to comments -- Comparison between FAR and OSPF - FRR

Hello Curtis,

Thank you for your comments.
But from what did you get conclusion of 'research projects'? We not only have a deployment experience but also strict large-scale system data analysis.

Following is my reply:

'No SPF is required for FRR to provide protection, restoring traffic flow though sometimes on a suboptimal path.'
--Is FRR only used within domain? If so, it can be counted as a drawback. And LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.

'One commercial CSPF measured about a decade ago completed in 30-40msec on a test topology of 450.  That was on a 300 MHz or less PPC or Pentium-2.
Todays processors are an order of magnitude faster, so we could expect (with order NlogN scaling of SPF) to get about the same SPF time on a topology of 4K or more nodes with no improvements in software.'
--As seen from the above CSPF business application data, there is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.

well the question is: does it matter ? - we can crunch a single SPF graph consisting
of app 1000 nodes in 1ms. i haven't seen concerns from any of my customers
about that figure.

To compare the FRR and FRR, the working process of the LDP FRR technology is described as follows:
1) Running LDP protocol in the network, it works as DU (downstream independent) label distribution + orderly label control + free label retention. (Disadvantage :additional protocol overhead)
In the above case, there are two paths from R1 to R5, R5 initiates multi-label mapping message to the upstream. Eventually, R2 and R3 respectively assign labels to R1 for reaching R5, among which, the label distributed by R2 is the primary label, the label distributed by R3 can be used as a backup. (Disadvantage: the irregular topology leads to complex routing and prone to cause more serious link block)

modern implementation of LFA, R-LFA also have got
support for policy control, such that backup-paths
which may be congested are avoided.

2) Specify one equipment port of the LSR as the backup of another equipment port.

usually the backup decision is done on a per route-bases rather than on a per backup basis so your above assumption is not correct.

3) Equipment maintenance label forwarding table: As the port backup has not been implemented, one label forwarding table has only one next hop and label, and the label is distributed for FEC by the LDP peer connected to the next hop of the routing of FEC. After the port backup is implemented, if the next hop of a label forwarding table is the protected port, add a next hop and label for the entry, and the label is distributed for FEC by the LDP peer connected to the backup next hop. (Disadvantage: large protocol database overhead and processing overhead)

if you are concerned about one vs. two protocols (not that i am)
have a look at the recent work on segment routing - it allows
to construct SPT paths and label state programming using one
IGP protocol.

4) Equipment maintenance of the working status of each port (normal/failure).

5) Packets reach the next hop, and are forwarded to the destination according to the corresponding label forwarding table.

It can be seen from the above FRR processing that FRR has the following disadvantages compared to FAR:

1) Additional protocol overhead: For the protection of links, nodes and paths, it is necessary to set up a backup LSP respectively, which causes unnecessary overhead and complex protocol processing; (there is no such protocol overhead for FAR, and because FAR is based on regular topology, path protection and switching process are simple.)

LFA, R-LFA are very conservative with regard to additional forwarding
state generation. most often just exisiting forwarding state is re-used.

2) Backup LSP failures may exist. As there is no protection mechanism, it cannot fast reroute when it fails; (FatTree network architecture has multiple natural selection.)

3) There is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.

that is entirely dependent on how FRR is implemented in your dataplane.
i may have to add that there are vendors how have chipsets which can
do FRR switchover in constant time.

4) LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.

Best.

Richard