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 protected]> on behalf of [email protected] <[email protected]> Sent: Wednesday, July 23, 2014 4:00 To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] 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) [cid:_1_0A943E600A943A48000B0F5048257D1E] 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
