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:rtgwg-bounces@ietf.org] 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
 > > rtgwg@ietf.org
 > > https://www.ietf.org/mailman/listinfo/rtgwg
 > 
 > _______________________________________________
 > rtgwg mailing list
 > rtgwg@ietf.org
 > 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.