In message <7c362eef9c7896468b36c9b79200d8350cfcf67...@inbansxchmbsa1.in.alcatel-lucent.com> "Bhatia, Manav (Manav)" writes: > > > > There is no question that you *can* design and/or code things badly. > > There was work done by Packet Designs and Qwest a while back and > > reported in NANOG. After this work, a major router vendor's > > implementation was optimized and a lot of delays were removed. A big > > mistake they were making is SPF and route install first and then > > reflood. It is better to get the word out that there is a problem. > > I believe RFC 2328 is quite clear that LSAs should be flooded before > "recalculating the routing table structure", so I am quite surprised > that there were implementations that were doing otherwise. Thus I > don't think anybody on this list seriously believes that this is an > issue that folks are trying to solve. I believe the idea is quite > simple - Flooding a changed LSA in HW (data plane) is faster than > doing it in SW (not matter how optimized the latter is) or your > control plane. > > Lets at least look at the proposed solution and see if its worth > considering. Who knows the discussion might lead us to something > better that we may want to use. > > Also note that I am not the author or in any way related to the draft! > :) > > Cheers, Manav
We have plenty of junk internet-drafts in IETF. One or two less would be better. If it is not solving a real world problem then we should get rid of it. First we have to agree that there is a requirement. draft-kini-ospf-fast-notification-01.txt calls for multicast, and cites draft-lu-fast-notification-framework-00.txt for "transporting the message encoding", but the latter makes no mention of multicast. If multicast is used, a multicast routing protocol is needed. A multicast tree can have transient loops. The last thing we need to add to OSPF is a new control plane transient loop creation capability. At least flooding is guarenteed to never loop. When a fault occurs in a multicast tree, the tree must converge before any other fault is reliably reported using multicast. Multiple faults are common. Most are covered in protocols such as RSVP-TE that support SRLG (but many are not even covered by SRLG). This work is half thought out and it doesn't address a real problem so I support telling the authors that it has no place in the OSPF WG. Curtis _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
