Bruno - The discussion here is a pragmatic one.
As draft-ietf-rtgwg-backoff-algo is a Standards track document the implication of it becoming an RFC is that everyone SHOULD/MUST implement it. Given that today vendors have implemented their own variations of SPF backoff, in order to justify requiring the use of a standardized algorithm it MUST be demonstrated that it makes a significant difference when used in real world deployments with timer values that are consistent with existing deployments. I think we agree on the following: 1)For a single topology change only the initial delay comes into play, so no benefits are expected from having a standardized algorithm 2)For multiple topology changes in a short period of time (i.e. within SHORT_SPF_DELAY as defined in the draft) the benefits of syncing the start of a second SPF in the control plane may be dwarfed by the time it takes to update the forwarding. In all the studies I am familiar with, the contribution of control plane work (routing update processing, SPF, RIB update) is under 30% of the total time required for convergence. The remainder is the time it takes to actually update the forwarding plane. So, what I am asking is that BEFORE the draft becomes an RFC that real world data be gathered demonstrating the benefits of the standardized algorithm in the cases where it might matter. I think the right set of test cases would include: o Timers in the range recommended by the draft - but also consistent with fast convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 100 ms or less) o Multiple topology changes which trigger multiple SPFs o A mixture of forwarding plane updates speeds in the affected nodes in the network o Comparison of results using all standardized algorithm and a mixture of vendor specific algorithms Based on these results we can then determine whether it is beneficial to progress the draft. Les > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, April 18, 2017 7:43 AM > To: Les Ginsberg (ginsberg) > Cc: RTGWG > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement > > Changing the subject of the thread. > > Hi Les, > > As a follow up on the discussion > > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb- > statement" I am > quoted as saying: > > > > " Les: most of the analysis that I am aware of - > the largest > contributor is > the control plane." > > > > In actuality what I said (or at least intended to say :-) ) was that the > largest > contributor is the > data plane (NOT the control plane). > > > > The point of the exchange between Bruno and myself was to emphaisze > the point that > demonstrating the real world benefits of the standardized > backoff algorithm should include > cases where forwarding plane update > speeds are different on different nodes in the > topology. It is possible > that > better synchronization of the control plane execution times > (which is what > use of a consistent backoff algorithm is likely to provide) may not mean much > > in cases where forwarding plane update speeds are significantly different > on different > nodes and/or when forwarding plane update speeds > consume much more time than the > control plane SPF/RIB updates. The > latter case is quite common. > > A few points/comments, > > - IMHO, your request seems more related to the problem statement draft. > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If > you could comment the draft in order to improve it, this would probably > speed up the discussion. > - You are right that the IGP fast convergence, following a single failure, is > mostly due to the time needed to update the FIB on line cards. However, as > the SPF back-off algo kicks in, this is changing, and differences in spf delay > algo brings a significant delta. cf slide 6 of the slides presented in IETF 90 > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may > also review the whole presentation; not because you would learn anything, > but may be to ease the identification of the parts where we may have a > different opinion. (at this point, I'm not seeing real disagreement). > - Do we agree that having different SPF delay algo across one network, is not > a feature but a bug? IOW, there is value in standardizing one. > > Regards, > --Bruno > > > > Les > > > > > > > -----Original Message----- > > > From: rtgwg [mailto:[email protected]] On Behalf Of Jeff Tantsura > > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtgwg- > chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The minutes > have been published at: > > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > > Please provide your comments. > > > > > > Thanks! > > > Jeff & Chris > > > > > > > > > > > > _______________________________________________ > > > rtgwg mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > > rtgwg mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg > > __________________________________________________________ > __________________________________________________________ > _____ > > 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
