Hannes, all > From: Hannes Gredler [mailto:[email protected]] > Sent: Monday, July 28, > 2014 5:07 PM
[...] > trying to synchronize RIB/FIB update across different CPUs/routing- > stacks/vendors/load conditions is a battle that can never be won. The thread has somewhat diverge. For the record, this is not what draft-decraene-rtgwg-backoff-algo is about. So the comment does not apply to this draft. The draft is about not arbitrarily introducing a delay between SPF computations runs on different routers/implementations. Such delay is bug, not a feature. Let's correct it. We can either correct it via an IETF standard that we can all discuss and improve together, or by declaring that the Cisco choice is the de facto standard. My preference is the first option since I believe in standard. I guess that this is also your preference. > as soon as you have the perfect-storm, you will have micro loops (and all the > pain you try to protect yourself) - therefore i'd be much more in favour of > 'something else' which gets us to zero uloops, and for that i am afraid we > need to have the notions of independent forwarding planes (ala make before > break) As stated in the draft and the slides, we have never claimed that the proposition remove all micro-loops. It removes/reduces some. There is a trade-off between the effectiveness of the solution and its cost. Over the last 8 years, the wg has worked on micro-loops avoidance, proposing different solutions. The problem still exists. So may be a simple small proposition may bring some benefits (at least more than a complete non deployed/implemented one). BTW, most solutions have considered the simple case of a single event IGP. I'd be curious to have the analysis of how they behave in case of multiple events when different routers compute their SPF at different times on different LSDB hence with more than 2 forwarding states in the network. Independent forwarding planes may require multiple (N) forwarding planes (and without knowing how routers delay/group their SPF that may be not that simple. I would assume that draft-decraene-rtgwg-backoff-algo would be beneficial)). oFIB does not apply. Bruno > /hannes > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
