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

From: <[email-masked]>
Date: Tue, 18 Apr 2017 14:42:36 +0000

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 18 Apr 2017 15:55:39 +0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2017 7:43 AM
> To: Les Ginsberg (ginsberg)
> Cc: RTGWG
> Subject: draft-ietf-rtgwg-spf-uloop-pb-statement
> 
>  > 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
>  >
>  >
> > > Sent: Thursday, April 13, 2017 4:09 PM  > > To: RTGWG  > > Cc: rtgwg-
> chairs  > > Subject: RTGWG minutes IETF98  > >  > > Hi,  > >  > > The minutes
> have been published at:
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.

---

From: <[email-masked]>
Date: Tue, 18 Apr 2017 16:41:02 +0000

Les,

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]  > Sent: Tuesday, April 18, 2017 5:56 PM
> 
 > Bruno -
 > 

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)

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 Apr 2017 03:05:18 +0000

Bruno -

We have no disagreement regarding the content of draft-ietf-rtgwg-backoff-algo - what I am concerned about is the intent of the draft. I see two possibilities.

1)This is an Informational draft which provides a discussion of what is needed to  achieve both fast convergence and stability - and defines an example set of configuration parameters and the method to use them in order to achieve the goal.
This is non-normative and allows that other means of achieving the same result are both possible and allowed. If that were the case I would have no further concerns.

2)This is a Standards track draft whose intent is to - over time - require all implementations to use the exact mechanisms defined in the draft.

As the draft is positioned as a Standards track document I assume your intent is the latter. In which case we have to consider the existence of multiple long-lived implementations which are using a different set of parameters/implementation (e.g. exponential backoff) to achieve the fast convergence behavior described in the paper you reference below. These implementations have been proven successful. Before we require them to be changed I think it is prudent to demonstrate empirically - not merely by analysis - that a deployment where some implementations use the mechanisms defined in the draft and some use a proven alternative will result in significantly degraded convergence in real world failure scenarios. If we do not do this then we are imposing requirements on vendors and customers alike which are not proven to yield improvement.

I therefore have suggested testing involving:

  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 Scenarios with multiple topology changes which trigger multiple SPFs in a short period of time
  o A mixture of routers with varying forwarding plane update speeds on the affected nodes in the network
  o Comparison of results using all standardized algorithm and a mixture of vendor specific algorithms and standard algorithm

This is not an argument against the content of the draft - just a request to do due diligence.

Does anyone have such data?

   Les

> From: rtgwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, April 18, 2017 9:41 AM
> Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement
> 
> Les,
> 
> >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.
> 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)
> 
> 
> 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.
> - IMHO, a reasonable paper on this would be
> https://pdfs.semanticscholar.org/0deb/57cc07a36cf1ea5ba0b3482bf14f2e8b
> b60d.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.
> 
> 
> 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.
>  >   o Comparison of results using all standardized algorithm and a mixture of
> vendor specific
>  > algorithms
>  >
> a feature but a bug?
>  > > 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.
> 
> 
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> information that may be protected by law;