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

[<[e-mail]>]

Les,

> From: Les Ginsberg (ginsberg) [mailto:[e-mail]]  > Sent: Tuesday, April 18, 2017 5:56 PM
> 
 > Bruno -
 > 
 > The discussion here is a pragmatic one.

That would be good indeed.

 
 > 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.

No.
I'm not aware that everyone SHOULD/MUST implement all IETF standard track RFC.

 
 > 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.

You are mixing implementation consideration with IETF considerations.
>From an IETF standpoint, in order to maximize the chance to have all (link state) IGP node to compute their SPF at the same time and using the same LSDB, we need nodes to have a consistent SPF delay algo.
>From an implementation standpoint, we this draft has 3 implementations.

> 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
 
I agree for a single link failure.
I disagree for other single failure, e.g. node failures and SRLG failures where multiple link state messages are involved from multiple nodes. Depending on differences in detection time, distance from the failure, flooding implementations long the way, SPF delay timers (..) multiple SPF may be involved for a single topological change.

(by "topology change" I assume that you mean the real/physical topology of the network, note the possibly N topological change that the IGP can see, depending on the configured SPF delays)

 
 > 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.
 
As already stated, I agree for some specific cases (e.g. first SPF) but not in the general case:

1) FIB update time
IMHO, the reference person for IGP Fast Convergence in the industry would be Clarence Filsfils. As a matter of luck for this discussion, both of you are in same organization and working on the same plateform, so this would ease similar point of view.
- BTW, you can note that he co-auteurs this draft.
- IMHO, a reasonable paper on this would be https://pdfs.semanticscholar.org/0deb/57cc07a36cf1ea5ba0b3482bf14f2e8bb60d.pdf (also from Clarence).

Note also that the paper is a bit old, and in the meantime both hardware and software have improved. But even at this time, FIB update time for 1000 IGP prefixes is/was around 300 ms (pecentil 90).
Note that what matter are the "important" IGP prefixes which attract the customer's traffic. In short, this means the loopback of the router (used as BGP Next-Hop). So here, I'm taking the example of a IGP with 1000 nodes, which is a significant scaling.

2) SPF delay
A presented in slide 6 of the slides presented in IETF 90 (https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf ) SPF delay can easily be higher than 300ms.

 
 > 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'm not aware that RTGWG WG requires deployment data are a prerequisite for RFC publication. Even implementations is not a pre-requisite (this has been discussed by the chairs a few month ago), but here, we do have 3 implementations.
That being said, IMHO the above data is real.

> 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.

Let me restate a question that you have not answered so far:
- Do we agree that having different SPF delay algo across one network, is not a feature but a bug?

--Bruno

 > 
 >    Les
 > 
 > 
 > > -----Original Message-----
 > > From: [e-mail] [mailto:[e-mail]]
 > > 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:[e-mail]] 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
 > >  > > [e-mail]
 > >  > > https://www.ietf.org/mailman/listinfo/rtgwg
 > >  >
 > >  > _______________________________________________
 > >  > rtgwg mailing list
 > >  > [e-mail]
 > >  > 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.


_________________________________________________________________________________________________________________________

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.