Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS and COMMENT)

From: Alia Atlas <[email-masked]>
Date: Mon, 12 Mar 2018 16:04:34 -0400

Hi Alvaro, Deborah & Bruno,

Does the most recent version (draft-ietf-rtgwg-backoff-algo-09) resolve the
concerns?
It would be excellent to have this approved before Weds at IETF 101.

I am happy to approve an updated draft being submitted, if necessary,
before IETF starts.

Thanks,
Alia

On Wed, Feb 28, 2018 at 1:36 PM, <[email-masked]> wrote:

> Alvaro,
>
> Please find below a follow up on one point
>
> > From: DECRAENE Bruno IMT/OLN
>  > Sent: Tuesday, February 27, 2018 11:44 AM
>
>  [...]
>
> >  > -----Original Message-----
>  >  > From: Alvaro Retana [mailto:[email-masked]]
>  >  > Sent: Tuesday, February 20, 2018 7:03 AM
>
> [...]
>
> >  > ------------------------------------------------------------
> ----------
>  >  > COMMENT:
>  >  > ------------------------------------------------------------
> ----------
>
> [...]
>
> >
>  >  > (2.3) For completeness, the HOLDDOWN_TIMER expiration events (5 and
> 6) should
>  >  > include resetting all the timers, just in case...and to be
> consistent with the
>  >  > initialization description.
>  >
>  > [Bruno] Good point a priori. However, I don't think anything needs to
> be changed because:
>  > - SPF_TIMER must not be reset as it can still run (if LONG_SPF_DELAY >
>  > HOLDDOWN_INTERVAL)
>  > - HOLDDOWN_TIMER has already expired by hypothesis
>  > - For transition 5 (from LONG_WAIT state), LEARN_TIMER has already
> expired by hypothesis.
>  > - For transition 6 (from SHORT_WAIT state) LEARN_TIMER has already
> expired because of the
>  > following constraint: " The
>  >    HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than
> the
>  > TIME_TO_LEARN_INTERVAL."
>
> Thinking more about this,
> Given that transition 6 should not be used if the constraint is enforced
> on the timers, but transition 6 is still documented for completeness and
> robustness, I think it makes sense to talk about the LEARN_TIMER during
> this transition 6.
> But actually, this is already in the draft:
>
>    Transition 6: HOLDDOWN_TIMER expiration, while in SHORT_WAIT.
>
>    Actions on event 6:
>    o  Deactivate LEARN_TIMER.
>    o  Transition to QUIET state.
>
> https://tools.ietf.org/html/draft-ietf-rtgwg-backoff-algo-08#section-5.1
>
> Thanks
> --Bruno
>
> ____________________________________________________________
> _____________________________________________________________
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: <[email-masked]>
Date: Tue, 13 Mar 2018 08:33:18 +0000

Hi Alia,

On my side, I’m waiting for Alvaro’s answers on our reply and propositions https://mailarchive.ietf.org/arch/msg/rtgwg/RcOpRdFVQUrwUS9NZxUdH8VmJo4

> It would be excellent to have this approved before Weds at IETF 101.
+1

> I am happy to approve an updated draft being submitted, if necessary, before IETF starts.
Thank you.
As of today, I think I can find some time this week to update the document as/if needed.

Thanks
--Bruno

From: Alia Atlas [mailto:[email-masked]]

Does the most recent version (draft-ietf-rtgwg-backoff-algo-09) resolve the concerns?
It would be excellent to have this approved before Weds at IETF 101.

I am happy to approve an updated draft being submitted, if necessary, before IETF starts.

Thanks,
Alia

On Wed, Feb 28, 2018 at 1:36 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Alvaro,

 [...]

 >  > From: Alvaro Retana [mailto:[email-masked]<mailto:[email-masked]>]

[...]

>  > ----------------------------------------------------------------------
 >  > COMMENT:
 >  > ----------------------------------------------------------------------

[...]

>
 >  > (2.3) For completeness, the HOLDDOWN_TIMER expiration events (5 and 6) should
 >  > include resetting all the timers, just in case...and to be consistent with the
 > [Bruno] Good point a priori. However, I don't think anything needs to be changed because:
 > - For transition 5 (from LONG_WAIT state), LEARN_TIMER has already expired by hypothesis.
 > - For transition 6 (from SHORT_WAIT state) LEARN_TIMER has already expired because of the
 >    HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the
 > TIME_TO_LEARN_INTERVAL."

Thinking more about this,
Given that transition 6 should not be used if the constraint is enforced on the timers, but transition 6 is still documented for completeness and robustness, I think it makes sense to talk about the LEARN_TIMER during this transition 6.
But actually, this is already in the draft:

   Actions on event 6:

Thanks
--Bruno

_________________________________________________________________________________________________________________________

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-masked]<mailto:[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: Alvaro Retana <[email-masked]>
Date: Sun, 18 Mar 2018 09:56:30 -0400

On February 27, 2018 at 10:43:42 AM, [email-masked] (
[email-masked]) wrote:

Bruno:

Hi!

You and I have a significant difference in opinion related to what can be
expected of a typical network operator.  In short, I don’t think that we
can expect the same from that typical operator as we can from someone like
you.  [To avoid confusion: this is a compliment! :-) ]

I will reply on the Responsible AD for any changes that may be needed from
my comments.

I will clear my DISCUSS if the text you proposed below is included in the
draft.

Thanks!

Alvaro.

...

> Back to the point of this DISCUSS, the importance of consistent values is
> clear! Based on the experience of existing implementations, please specify

> "safe" default values.

[Bruno] Ok.
First of all, I do think that the "best" default are likely to change over
time (as both CPU power and customer requirements increase). Over the last
15+ years, this has already happened on some implementations
https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-and-IS-IS-SPF-and.html
 Also for the BGP protocol, this also happened for BGP Route Flap dampening
parameters (cf RFC 2439 & 7196). They are also likely to be dependent of
the segment market (e.g. backbone vs backhaul vs "pre-aggregation").

I would propose the following addition:
NEW:
If this SPF backoff algorithm is enabled by default, then in order to have
consistent SPF delays between implementations with default configuration,
the following default values SHOULD be implemented:
INITIAL_SPF_DELAY 50 ms, SHORT_SPF_DELAY 200ms, LONG_SPF_DELAY: 5 000ms,
TIME_TO_LEARN_INTERVAL 500ms, HOLDDOWN_INTERVAL 10 000ms.

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 13:38:34 +0000

Alvaro,

Thanks.

-10 has just been uploaded.

2 changes, applying text we discussed in email:

- default timers values are added

- slightly reworded definition of “Routing table computation”

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-backoff-algo
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-backoff-algo-10

Thanks for your review
--Bruno

From: Alvaro Retana [mailto:[email-masked]]
Sent: Sunday, March 18, 2018 2:56 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]; Uma Chunduri
Subject: RE: Alvaro Retana's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS and COMMENT)

On February 27, 2018 at 10:43:42 AM, [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) wrote:

Bruno:

Hi!

You and I have a significant difference in opinion related to what can be expected of a typical network operator.  In short, I don’t think that we can expect the same from that typical operator as we can from someone like you.  [To avoid confusion: this is a compliment! :-) ]

I will reply on the Responsible AD for any changes that may be needed from my comments.

I will clear my DISCUSS if the text you proposed below is included in the draft.

Thanks!

Alvaro.

...
> clear! Based on the experience of existing implementations, please specify

[Bruno] Ok.
First of all, I do think that the "best" default are likely to change over time (as both CPU power and customer requirements increase). Over the last 15+ years, this has already happened on some implementations https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-and-IS-IS-SPF-and.html Also for the BGP protocol, this also happened for BGP Route Flap dampening parameters (cf RFC 2439 & 7196). They are also likely to be dependent of the segment market (e.g. backbone vs backhaul vs "pre-aggregation").

I would propose the following addition:
NEW:
If this SPF backoff algorithm is enabled by default, then in order to have consistent SPF delays between implementations with default configuration, the following default values SHOULD be implemented:
INITIAL_SPF_DELAY 50 ms, SHORT_SPF_DELAY 200ms, LONG_SPF_DELAY: 5 000ms, TIME_TO_LEARN_INTERVAL 500ms, HOLDDOWN_INTERVAL 10 000ms.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Mar 2018 15:05:40 +0000

For what it's worth ...

> - default timers values are added
I balloted No-Objection, supporting Alvaro's Discuss. It's appropriate that
I also say explicitly that I support the resolution you worked out.

That way, your AD doesn't have to be curious about what Spencer is thinking.

About this, anyway.

Spencer

> *From:* Alvaro Retana [mailto:[email-masked]]
> *Sent:* Sunday, March 18, 2018 2:56 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* [email-masked]; [email-masked]; The IESG;
> [email-masked]; Uma Chunduri
> *Subject:* RE: Alvaro Retana's Discuss on draft-ietf-rtgwg-backoff-algo-07:
> (with DISCUSS and COMMENT)
>
>
>
> 15+ years, this has already happened on some implementations https://www.
> cisco.com/c/en/us/support/docs/ip/ip-routing/211432-
> Change-of-Default-OSPF-and-IS-IS-SPF-and.html Also for the BGP protocol,
> this also happened for BGP Route Flap dampening parameters (cf RFC 2439 &
> 7196). They are also likely to be dependent of the segment market (e.g.
> backbone vs backhaul vs "pre-aggregation").
>