RE: draft-ietf-rtgwg-spf-uloop-pb-statement

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: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
> 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: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.