> this is not going to be worth than today with very different SPF delay algo.
:s/ worth/worse. Sorry for the spam (I'd like to blame the spell checker L ) From: rtgwg [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, March 07, 2016 11:04 AM To: Chris Bowers; [email protected] Subject: RE: progressing draft-ietf-rtgwg-backoff-algo Hi Chris, all That's a good and reasonable question. Please find below my personal feedback. I think we can identify 3 parts in the draft: a) A SPF delay b) A uniform SPF delay within an AS/area c) A specific math formula to determine the delay a) A SPF delay Adding a SPF delay, dependent on the IGP stability, is already in all implementations I'm aware off, massively deployed (by default), with many years of experience (>15). This is more than enough for a standard track document. As a matter of fact, this would probably even qualify for the Internet Standard maturity level. b) A uniform SPF delay within an AS/area IMHO, draft-ietf-rtgwg-spf-uloop-pb-statement<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-spf-uloop-pb-statement/> and draft-ietf-rtgwg-backoff-algo<http://tools.ietf.org/wg/rtgwg/draft-ietf-rtgwg-backoff-algo/> have made the case that the use of a uniform SPF delay strategy within an AS/area is beneficial from a micro-loop point of view. (Even if this were not the case, this is not something that 2 existing implementation would improve) c) A specific math formula to determine the delay That part is a new specification. IMHO, the proposed change is limited. Roughly the math formula determining the delay (e.g. On Quagga ht = ospf6->spf_holdtime * ospf6->spf_hold_multiplier; ) , although there is additional code to define when to restart to initial value and when to bound the delay. You are welcomed to check in your own code. I would expect that this is a small enough change to have it specified correctly, especially after a WG & IESG review. In summary, I think this draft should be published as a STD track document because - this draft propose a reasonably small change to a behavior which is widely implemented with very large deployment experience, this draft builds on this large experience. - I agree that having N implementations would be safer, but it would also be more process and more time. I don't feel that this should stop this document from being published as a STD track RFC. And if we have time, I would personally be more interested in having simulation results on extensive real data from multiple ASes, rather than having prototype implementations. - in the worst case, if the draft is not clear enough to have all implementation behave exactly the same way, this is not going to be worth than today with very different SPF delay algo. So IMO, publishing it even without implementation, is better than not publishing it, or publishing it as experimental. Lastly, speaking for myself, if the requirement for 2 implementations gets to a blocking point, we have the option to have this draft document an already implemented and deployed SPF algo; presumably the most deployed one (read the Cisco one). IMHO, this would not be a success for the IETF to prefer a "closed" algo compared to an openly discussed one, but that would fulfil my priority 1 which is to have a way to have a uniform SPF delay across all routers of an AS/area, so I could live with that. Thanks, Regards, Bruno From: rtgwg [mailto:[email protected]] On Behalf Of Chris Bowers Sent: Wednesday, March 02, 2016 12:34 AM To: [email protected]<mailto:[email protected]> Subject: progressing draft-ietf-rtgwg-backoff-algo RTGWG, Jeff and I wanted to get a sense of how the working group would like to proceed regarding draft-ietf-rtgwg-backoff-algo. The basic question for the working group is: Should we proceed towards publication of the draft more or less as is, or should we wait to incorporate feedback from one or more implementations of the SPF back-off algorithm? As far as we know, there haven't been any implementations of the proposed SPF back-off algorithm. It would be good to get an understanding if any implementations are in progress or planned. The common SPF back-off algorithm proposed in the document seems quite reasonable. However, it is also quite possible that a single implementation would uncover some unforeseen issues or suggest improvements for the functioning of the algorithm in a single vendor network. Testing with two or more implementations may provide feedback to improve the algorithm with respect to the goal of having common SPF delays in a multi-vendor network. But we won't know until that work is done. If there are implementations in progress or planned, then we think it would be worth waiting to incorporate feedback from those implementations before publishing. Instead, if there are no implementations planned, we have several options. We can proceed towards publication more or less as is, with WG last call in the near future. Or we can explicitly decide to wait to publish the document, leaving it either as an active WG document or as a parked WG document, and wait for one or more implementations. With the last option, we could leave open the option of publishing at some point in the future, even if no implementations appear. Personally, I am quite hopeful that there will be at least prototype implementations in the not too distant future. While it is very unlikely that a vendor would change their default SPF back-off algorithm to this new algorithm, it can easily be implemented with a knob to activate this algorithm. This gives a simple way to try out the new algorithm incrementally, lowering the bar significantly for at least a prototype implementation. We look forward to hearing feedback from the WG on how to proceed with the draft. Thanks, Chris _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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
