Subject: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

From: Deborah Brungard <[email-masked]>
Date: Tue, 20 Feb 2018 15:02:59 -0800

Deborah Brungard has entered the following ballot position for
draft-ietf-rtgwg-backoff-algo-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-backoff-algo/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

While I agree with Alvaro's concerns, my concern is the appropriateness of this document as PS.
This document should have a similar status as RFC6976 (Informational) which also provided a
mechanism that prevented transient loops saying "the mechanisms described in this
document are purely illustrative of the general approach and do not constitute a protocol
specification". Especially as this document compares itself to RFC6976, saying RFC6976 is a
"full solution".

With a change of status to Informational, this document would be better
scoped as providing guidance vs. a specification.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Feb 2018 00:52:32 +0000

Hi Deborah, 

Given that the goal of RFC 6976 was much more ambitious and the mechanisms are much more complex, I don't think this draft should be put in the same category. 

What we have done is precisely specify a standard algorithm for IGP SPF back-off. When deployed, this standard algorithm will greatly improve (but not eliminate) micro-loops in IGP routing domains currently utilizing disparate SPF back-off algorithms. The problem statement draft best articulates the impact of differing SPF back-off algorithms: https://www.ietf.org/id/draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt. Finally, there have been several prototype implementations validating the algorithm specification's completeness and clarity. 

Thanks,
Acee

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Sat, 24 Feb 2018 21:07:34 +0000

Hi Acee,

Sorry for not responding earlier, I had an unexpected disruption to my schedule these last days.

I was concerned as the document itself says "Optionally, implementations may also offer alternative algorithms." So it is not clear if it is the algorithm or the parameters which are intended PS.

And especially concerning is section 7 on partial deployment. It states the algorithm is only effective if it is deployed on all routers, and partial deployment will increase the frequency and duration of micro-loops. It does go on to say operators have progressively replaced an implementation of a given algorithm by a different one.

If this is to be PS, then you need to provide guidance on how an operator is to do the upgrade to this new algorithm on a network. I understand there are prototype implementations, but I'm concerned on field grade deployments in existing networks.

Thanks,
Deborah

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Wednesday, February 21, 2018 7:53 PM
To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

Hi Deborah, 

What we have done is precisely specify a standard algorithm for IGP SPF back-off. When deployed, this standard algorithm will greatly improve (but not eliminate) micro-loops in IGP routing domains currently utilizing disparate SPF back-off algorithms. The problem statement draft best articulates the impact of differing SPF back-off algorithms: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drtgwg-2Dspf-2Duloop-2Dpb-2Dstatement-2D06.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=Vtva23qDNV_XHrGXH4C87wmfZuLcxGEDJAXqVihSSPw&e= . Finally, there have been several prototype implementations validating the algorithm specification's completeness and clarity. 

Thanks,

Acee

    

    Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=LvqOOWwzZ-3P6mF9xQUGj2HWklodlOlWO94fprhgwc8&e= 

    

    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-mV3Tpp8iWGOSIp_fkDPkMuA&s=YnZA5VGqF0T8BAOlFKka0ckWFUhUDHd0sILBbPRRaeU&e= 

    DISCUSS:

    "full solution".

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 25 Feb 2018 01:52:45 +0000

Hi Deborah, 

On 2/24/18, 4:07 PM, "BRUNGARD, DEBORAH A" <[email-masked]> wrote:

    Hi Acee,

This is the reality that IGP implementations that have been using their proprietary SPF backoff algorithms for decades are not going to move to the standard mechanisms as their default overnight. 

The IETF can't just mandate that vendors implement the new standard SPF backoff algorithm, make it the default SPF Backoff, or that operators deploy it. I believe we have provided ample guidance by indicating that the full benefit is only obtained when the same algorithm is deployed over the IGP domain (or at least an area). The standardization of the SPF Backoff algorithm is the start of the journey, not the destination. 

    Thanks,
    Deborah
    
    -----Original Message-----
    From: Acee Lindem (acee) [mailto:[email-masked]] 
    Sent: Wednesday, February 21, 2018 7:53 PM
    To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
    Cc: [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
    
    Hi Deborah, 

    

    Thanks,
    
    Acee

    

    

    

    

    

    
    
        DISCUSS:

    

    

        "full solution".

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 27 Feb 2018 19:35:53 +0000

Hi Deborah, Alvaro, 

Bruno has posted -08 version addressing Alvaro's default timer value request. Can you clear your DISCUSSES? 

Thanks,
Acee 

On 2/24/18, 8:52 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

    Hi Deborah, 

        Hi Acee,

    

    

        Thanks,
        Deborah
        
        -----Original Message-----
        From: Acee Lindem (acee) [mailto:[email-masked]] 
        Sent: Wednesday, February 21, 2018 7:53 PM
        To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>
        Cc: [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
        
        Hi Deborah, 

        

        Thanks,
        
        Acee

        

        

        

        

        

        
        
            DISCUSS:

        

        

            "full solution".

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 28 Feb 2018 11:48:11 +0000

Hi Acee,

I think Alvaro is on vacation this week without email access. As I noted in my Discuss, I support Alvaro's concerns on incompleteness and vagueness. I am interested in Alvaro's response on the update if it addresses his concerns.

I don't see any changes for my noted concerns on vagueness. The confusing sentence remains in the introduction "Optionally, implementations may also offer alternative algorithms." And later in section 5 saying it "describes the abstract finite state machine".

So to me, it still is not clear if this document is a PS for the algorithm or for the parameters e.g. any SPF delay algorithm that supports the IETF parameters can be used so long as it derives the same results of the "abstract" state machine. Especially considering the deployment concerns for a new algorithm. As other ADs agree with me, this type of document is typically informational. Maybe with Alvaro's clarifications, it will not be so abstract.

The naming of the algorithm is also vague.

There are only two uses of "backoff", in the title and in the abstract. The document uses "SPF delay algorithm".
Looking at the ospf-yang document, it doesn't reference this document or use the feature name "backoff algorithm". It refers to an "SPF delay algorithm" and lists the parameters. Either "backoff" or "SPF delay" naming should be used consistently if it is the titled algorithm which is PS.

Thanks,
Deborah

-----Original Message-----
From: iesg [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, February 27, 2018 2:36 PM
To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]
Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

Hi Deborah, Alvaro, 

https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=EanJBdMh8ViXUpOAcuGDU3_m4REU12AjmiAeQh4TZ5o&s=nNjJEE9Ft49chxnM3q347Q6JACjZaUR3XaoDmZkyXJA&e= 

Thanks,

Acee 

    Hi Deborah, 

        Hi Acee,

        

        Thanks,

        Deborah

        -----Original Message-----

        Hi Deborah, 

        

        

        Thanks,

        Acee

            

            

            

            

            

            DISCUSS:

            

            "full solution".

---

From: <[email-masked]>
Date: Wed, 28 Feb 2018 15:44:54 +0000

Hi Deborah,

Please see inline

 > From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
 > Sent: Wednesday, February 28, 2018 12:48 PM
>
 > 
 > Hi Acee,
 > 
 > I think Alvaro is on vacation this week without email access. As I noted in my Discuss, I support
 > Alvaro's concerns on incompleteness and vagueness. I am interested in Alvaro's response on the
 > update if it addresses his concerns.

1) Regarding Alvaro's DISCUSS,
We have engaged the discussion on his points. Thanks for the info that he is on vacation this week. No problem, we'll obviously wait for this return.

2) Regarding your DISCUSS,
Can we work on resolving your point and hopefully your DISCUSS even in the absence of Alvaro?

As a reminder, your DISCUSS is the following:

"While I agree with Alvaro's concerns, my concern is the appropriateness of this document as PS.
This document should have a similar status as RFC6976 (Informational) which also provided a
mechanism that prevented transient loops saying "the mechanisms described in this
document are purely illustrative of the general approach and do not constitute a protocol

With a change of status to Informational, this document would be better scoped as providing guidance vs. a specification."

So in summary your DISCUSS is about the status of this document: STD track vs informational.

Acee has replied on this point in the following thread, and ultimately you did not follow up. So I though the point was closed.
https://mailarchive.ietf.org/arch/msg/rtgwg/pqGrmtI7MYVqU8tSNwId-QEROYs
So could you please follow up on this thread so that we can advance on this point?
I'll also contribute below in this email in reply to your specific comments.

Regarding STD status, a distributed Link State IGP, requires, in order to produce consistent routing table across the network, to perfom the same computation (SPF), using the same info/database, at the same time.
Given that all implementations use SPF back off delay algorithms (by default), in order to fulfill this routing consistency across the network, one STD SPF back off delay algo needs to be specific. By doing so, this document helps addressing the above two latest points (same time, same LSDB).

Also, in case you missed it as the email was in a different thread, Alia has also stated that this needs to be standard track.
https://mailarchive.ietf.org/arch/msg/rtgwg/EDpT9lvKVDaBjI8g_QHznZMdTNI

3) Regarding your new additional comments below

It's not clear to me whether they are additional points in your DISCUSS or just regular comments.
Reading the discuss criteria, they really likes non-blocking comments to me.
https://www.ietf.org/iesg/statement/discuss-criteria.html

So you could please clarify the status of those comments?

More below.

 > 
 > I don't see any changes for my noted concerns on vagueness.

Acee replied to your email and you did not reply.
As previously noted, I'll also reply on your points in this email, below.

 > The confusing sentence remains in
 > the introduction "Optionally, implementations may also offer alternative algorithms." 

- I'm personally not sure to see what is confusing in this sentence.
- As Acee replied, this is just a statement about the reality of existing implementations and deployments.
- That being said, that sentence does not really add anything to the specification. Hence if this is a blocking point to you, I've just removed it. Problem solved.

  >And later in
 > section 5 saying it "describes the abstract finite state machine".

I'm not sure to see the issue but changed to

OLD: This section describes the abstract finite state machine (FSM)
NEW: This section specifies the finite state machine (FSM)

Also changed (*3):
OLD: FSM abstract timer
NEW: FSM timer

 > So to me, it still is not clear if this document is a PS for the algorithm or for the parameters

The document is a PS for the algorithm.
We have initiated a discussion with Alvaro regarding the additional specification of default parameters for the specific cases where they are useful.

 > e.g. any
 > SPF delay algorithm that supports the IETF parameters can be used so long as it derives the same
 > results of the "abstract" state machine.

I'm not sure how this question is specific to this document.
Personally, I'd tend to generally reply "yes". i.e., considering the node as a black box, if it's behavior conforms to the behavior defined in the IETF document, I'd say that the node is compliant with the IETF document.
e.g., if the IETF document defines a timer of 3 seconds, it looks ok for me if an implementation waits for 3 consecutive 1 second timers. 
But any general answer from the IETF works for me. It seemed to me that the IETF does not give position regarding conformance.

 > Especially considering the deployment concerns for a new algorithm.

I think that you are missing that the current situation is worse: if you have a multi-vendor networks, you already have inconsistent algorithms forever hence you (may) have inconsistent timers values forever.
If/When you transition to this new algorithm, you also have inconsistent algorithms during the transition (*), but after the transition, the problem is solved. 
(*) whether the situation is worse during the transition or not, is very dependent on the pre-existing algo.

Also, this inconsistency is essentially the same than the transition of parameters values. And this already happen today, including in a mono-vendor network. e.g.,   https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-and-IS-IS-SPF-and.html
Please note that deployment section from the above document says essentially the same:

"When you deploy routers with newer Cisco IOS software that have the new default values, it is recommended to ensure that all routers have the same default values for the timers. This reduces the risk for possible routing loops. 

If you have routers that run the old default values and you upgrade the routers to the newer Cisco IOS software, it is likely that you have a migration time where some routers run an older Cisco IOS software with the old default values and some routers that run newer IOS software with the new default values. This is not recommended."

Bottom line: blocking this document does not avoid a possible transition issue, but avoids solving the existing forever issue in multi-vendor network.

 > As other ADs agree with me, this type of document is typically informational. Maybe with
 > Alvaro's clarifications, it will not be so abstract.
 
We are indeed working on Alvaro's comment.

 > The naming of the algorithm is also vague.
 
I guess that the discussion on the name is not a DISCUSS/blocking-issue. Is this?

 > There are only two uses of "backoff", in the title and in the abstract. The document uses "SPF

The document defines a "backoff" procedure for the IGP SPF, by introducing a delay and a delay which is increasing as the IGP keeps computing SPFs.
This document defines the algorithm/procedure computing this delay.

 > Looking at the ospf-yang document, it doesn't reference this document or use the feature name
 > "backoff algorithm". It refers to an "SPF delay algorithm" and lists the parameters. Either "backoff"
 > or "SPF delay" naming should be used consistently if it is the titled algorithm which is PS.

Good comments. But those are for the YANG documents. Not this one.

Thanks
--Bruno

 > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-
 > 2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=EanJBdMh8ViXUpOAcuGDU3_m4R
 > EU12AjmiAeQh4TZ5o&s=nNjJEE9Ft49chxnM3q347Q6JACjZaUR3XaoDmZkyXJA&e=
 > 
 > 
 > 
 > Thanks,
 > 
 > Acee
 > 
 > 
 > 
 >         I was concerned as the document itself says "Optionally, implementations may also offer
 > alternative algorithms." So it is not clear if it is the algorithm or the parameters which are intended
 > PS.
 > 
 > 
 > 
 >     This is the reality that IGP implementations that have been using their proprietary SPF backoff
 > algorithms for decades are not going to move to the standard mechanisms as their default
 > overnight.
 > 
 > 
 > 
 >         And especially concerning is section 7 on partial deployment. It states the algorithm is only
 > effective if it is deployed on all routers, and partial deployment will increase the frequency and
 > duration of micro-loops. It does go on to say operators have progressively replaced an
 > implementation of a given algorithm by a different one.
 > 
 > 
 > 
 >         If this is to be PS, then you need to provide guidance on how an operator is to do the upgrade
 > to this new algorithm on a network. I understand there are prototype implementations, but I'm
 > concerned on field grade deployments in existing networks.
 > 
 > 
 > 
 >     The IETF can't just mandate that vendors implement the new standard SPF backoff algorithm,
 > make it the default SPF Backoff, or that operators deploy it. I believe we have provided ample
 > guidance by indicating that the full benefit is only obtained when the same algorithm is deployed
 > over the IGP domain (or at least an area). The standardization of the SPF Backoff algorithm is the
 > start of the journey, not the destination.
 > 
 > 
 > 
 > 
 > 
 >         Thanks,
 > 
 >         Deborah
 > 
 > 
 > 
 >         Given that the goal of RFC 6976 was much more ambitious and the mechanisms are much
 > more complex, I don't think this draft should be put in the same category.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >         What we have done is precisely specify a standard algorithm for IGP SPF back-off. When
 > deployed, this standard algorithm will greatly improve (but not eliminate) micro-loops in IGP routing
 > domains currently utilizing disparate SPF back-off algorithms. The problem statement draft best
 > articulates the impact of differing SPF back-off algorithms:
 > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drtgwg-2Dspf-
 > 2Duloop-2Dpb-2Dstatement-2D06.txt&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-
 > mV3Tpp8iWGOSIp_fkDPkMuA&s=Vtva23qDNV_XHrGXH4C87wmfZuLcxGEDJAXqVihSSPw&
 > e= . Finally, there have been several prototype implementations validating the algorithm
 > specification's completeness and clarity.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >         Thanks,
 > 
 > 
 > 
 >         Acee
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 >             Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
 > 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-
 > mV3Tpp8iWGOSIp_fkDPkMuA&s=LvqOOWwzZ-3P6mF9xQUGj2HWklodlOlWO94fprhgwc8&e=
 > 
 > 
 > 
 >             https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-
 > 2Drtgwg-2Dbackoff-2Dalgo_&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lB8O9Nd8E9rpRoJj0YX-
 > mV3Tpp8iWGOSIp_fkDPkMuA&s=YnZA5VGqF0T8BAOlFKka0ckWFUhUDHd0sILBbPRRaeU&
 > e=
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 

_________________________________________________________________________________________________________________________

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: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 28 Feb 2018 10:17:53 -0600

Just to chime in ...

I was a No-Objection for this document supporting Deborah's Discuss,
Alvaro's Discuss, and maybe both, and the reason I was vague about that,
was that those Discusses seemed to be headed in opposite directions -
either the document needed to be more abstract, or it needed to be more
precise (with recommended timer values, etc.). I could have believed either
assertion, but wanted to see which way the document headed before saying
more myself.

I see that the conversation continues, and will continue a bit more when
Alvaro surfaces, but I wanted to say that I appreciate the exchange(s) so
far, and especially Bruno's most recent post, clarifying the transition
story.

Thank you all for that. I'm still reading ballot threads as they develop,
of course.

Spencer

On Wed, Feb 28, 2018 at 9:44 AM, <[email-masked]> wrote:

> We have engaged the discussion on his points. Thanks for the info that he
> is on vacation this week. No problem, we'll obviously wait for this return.
>
> scoped as providing guidance vs. a specification."
>
>
>
>
> Acee has replied on this point in the following thread, and ultimately you
> did not follow up. So I though the point was closed.
> Regarding STD status, a distributed Link State IGP, requires, in order to
> produce consistent routing table across the network, to perfom the same
> computation (SPF), using the same info/database, at the same time.
> Given that all implementations use SPF back off delay algorithms (by
> default), in order to fulfill this routing consistency across the network,
> one STD SPF back off delay algo needs to be specific. By doing so, this
> document helps addressing the above two latest points (same time, same
> LSDB).
>
> Also, in case you missed it as the email was in a different thread, Alia
> has also stated that this needs to be standard track.
> - That being said, that sentence does not really add anything to the
> specification. Hence if this is a blocking point to you, I've just removed
> it. Problem solved.
>
>   >And later in
> We have initiated a discussion with Alvaro regarding the additional
> specification of default parameters for the specific cases where they are
> useful.
>
>  > e.g. any
> Personally, I'd tend to generally reply "yes". i.e., considering the node
> as a black box, if it's behavior conforms to the behavior defined in the
> IETF document, I'd say that the node is compliant with the IETF document.
> e.g., if the IETF document defines a timer of 3 seconds, it looks ok for
> me if an implementation waits for 3 consecutive 1 second timers.
> But any general answer from the IETF works for me. It seemed to me that
> the IETF does not give position regarding conformance.
>
> I think that you are missing that the current situation is worse: if you
> have a multi-vendor networks, you already have inconsistent algorithms
> forever hence you (may) have inconsistent timers values forever.
> If/When you transition to this new algorithm, you also have inconsistent
> algorithms during the transition (*), but after the transition, the problem
> is solved.
> Also, this inconsistency is essentially the same than the transition of
> parameters values. And this already happen today, including in a
> mono-vendor network. e.g.,   https://www.cisco.com/c/en/us/
> support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-
> and-IS-IS-SPF-and.html
> "When you deploy routers with newer Cisco IOS software that have the new
> default values, it is recommended to ensure that all routers have the same
> default values for the timers. This reduces the risk for possible routing
> loops.
>
> If you have routers that run the old default values and you upgrade the
> routers to the newer Cisco IOS software, it is likely that you have a
> migration time where some routers run an older Cisco IOS software with the
> old default values and some routers that run newer IOS software with the
> new default values. This is not recommended."
>
>
> Bottom line: blocking this document does not avoid a possible transition
> issue, but avoids solving the existing forever issue in multi-vendor
> network.
>
>
>  > There are only two uses of "backoff", in the title and in the abstract.
> The document uses "SPF
>  > delay algorithm".
>
> The document defines a "backoff" procedure for the IGP SPF, by introducing
> a delay and a delay which is increasing as the IGP keeps computing SPFs.
>  > To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>;
> Alvaro Retana
>  > <[email-masked]>
>  > Cc: [email-masked]; [email-masked]; Uma Chunduri <
> [email-masked]>; draft-
>  > [email-masked]
>  > Subject: Re: Deborah Brungard's Discuss on
> draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
>  >
>  > Hi Deborah, Alvaro,
>  >
>  >
>  >
>  > Bruno has posted -08 version addressing Alvaro's default timer value
> request. Can you clear your
>  > DISCUSSES?
>  >
>  >
>  >
>  >         Sorry for not responding earlier, I had an unexpected
> disruption to my schedule these last
>  > days.
>  >
>  >
>  >
>  >         Cc: [email-masked]; Uma Chunduri <
> [email-masked]>;
>  > [email-masked]; [email-masked]
>  >
>  >         Subject: Re: Deborah Brungard's Discuss on
> draft-ietf-rtgwg-backoff-algo-07: (with
>  > DISCUSS)
>  >
>  >
>  >
>  >         Hi Deborah,
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >             While I agree with Alvaro's concerns, my concern is the
> appropriateness of this document
>  > as PS.
>  >
>  >
>  >
>  >             This document should have a similar status as RFC6976
> (Informational) which also
>  > provided a
>  >
>  >
>  >
>  >             specification". Especially as this document compares itself
> to RFC6976, saying RFC6976 is
>  > a
>  >
>  >
>  >
>  >             "full solution".
>  >
>  >
>  >
>  >
>  >
>  >
>  >
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Feb 2018 16:36:04 +0000

Hi Spencer, 

We are begrudgingly discussing the inclusion of "default" values as opposed to "example" delay values and are willing to make this concession to resolve the issue. A couple things to note:

   1. Even the OSPF Hello and Dead intervals (which are necessary to form an OSPF adjacency) are provided as "example" values in RFC 2328. 
   2. Given the initial discussions of this RTGWG draft, it is interesting that standard defaults have not been requested until the IESG review. 

Thanks, 
Acee 

On 2/28/18, 11:18 AM, "Spencer Dawkins at IETF" <[email-masked]> wrote:

    Just to chime in ...

    
    
    Spencer
    
    On Wed, Feb 28, 2018 at 9:44 AM, <[email-masked]> wrote:
    
    >  > There are only two uses of "backoff", in the title and in the abstract

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 28 Feb 2018 10:39:29 -0600

Hi, Acee,

On Feb 28, 2018 10:36, "Acee Lindem (acee)" <[email-masked]> wrote:

Hi Spencer,

We are begrudgingly discussing the inclusion of "default" values as opposed
to "example" delay values and are willing to make this concession to
resolve the issue. A couple things to note:

   1. Even the OSPF Hello and Dead intervals (which are necessary to form
an OSPF adjacency) are provided as "example" values in RFC 2328.
   2. Given the initial discussions of this RTGWG draft, it is interesting
that standard defaults have not been requested until the IESG review.

Thanks for added context. And I'm still reading ;-)

Spencer

Thanks,
Acee

On 2/28/18, 11:18 AM, "Spencer Dawkins at IETF" <
[email-masked]> wrote:

    Just to chime in ...

    precise (with recommended timer values, etc.). I could have believed
either

    I see that the conversation continues, and will continue a bit more when
    Alvaro surfaces, but I wanted to say that I appreciate the exchange(s)
so
    far, and especially Bruno's most recent post, clarifying the transition
    story.

    Thank you all for that. I'm still reading ballot threads as they
develop,
    of course.

    Spencer

    On Wed, Feb 28, 2018 at 9:44 AM, <[email-masked]> wrote:

    >  > Alvaro's concerns on incompleteness and vagueness. I am interested
in
    > Alvaro's response on the
    > Can we work on resolving your point and hopefully your DISCUSS even
in the
    > absence of Alvaro?
    > "While I agree with Alvaro's concerns, my concern is the
appropriateness
    > of this document as PS.
    > mechanism that prevented transient loops saying "the mechanisms
described
    > in this
    > specification". Especially as this document compares itself to
RFC6976,
    > saying RFC6976 is a
    > So in summary your DISCUSS is about the status of this document: STD
track
    > vs informational.
    > It's not clear to me whether they are additional points in your
DISCUSS or
    > just regular comments.
    > Reading the discuss criteria, they really likes non-blocking comments
to
    > me.
    > - As Acee replied, this is just a statement about the reality of
existing
    > implementations and deployments.
    >  > SPF delay algorithm that supports the IETF parameters can be used
so
    > long as it derives the same
    > (*) whether the situation is worse during the transition or not, is
very
    > dependent on the pre-existing algo.
    >
    > I guess that the discussion on the name is not a
DISCUSS/blocking-issue.
    > Is this?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Feb 2018 16:45:55 +0000

Hi Deborah, 

I'll reiterate that even though this is a standards track document, our intent is not to propose an SPF algorithm that is not backward compatible with the existing OSPF and IS-IS specifications. The existing specifications do not specify the SPF delay algorithm and the SPF delay algorithm varies by implementation. While not within the scope of this specification, these implementation specific algorithms will continue to be supported even after this document is published and deployed. I believe the RTG WG and LSR WG are clear on this point and there is no vagueness with the statement regarding other algorithms. Hopefully, it assuages your concern as well. 

Thanks,
Acee 

On 2/28/18, 10:45 AM, "[email-masked]" <[email-masked]> wrote:

    Hi Deborah,
    
    Please see inline

    

    

    

    

    

    
    More below.

    

    
    
    Also changed (*3):
    OLD: FSM abstract timer
    NEW: FSM timer

    

    

    

     

    

    
    Thanks
    --Bruno

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 28 Feb 2018 17:23:15 +0000

Hi Bruno,

Inline-

Quick summary - thanks for the proposed changes. You do need to pick "one" algorithm name for this document. I will wait to clear once Alvaro's concerns are addressed.

Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 28, 2018 10:45 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

Hi Deborah,

Please see inline

This document should have a similar status as RFC6976 (Informational) which also provided a mechanism that prevented transient loops saying "the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification". Especially as this document compares itself to RFC6976, saying RFC6976 is a "full solution".

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_rtgwg_pqGrmtI7MYVqU8tSNwId-2DQEROYs&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJasSzHeKs92fsD8Y&s=lSwLlzGBRCELFV0V0oBnY2bQ-A4OuduzADebFkfZG0A&e= 

[deborah] Considering Acee's reply, I was hoping the updated draft would take into consideration my concerns. 

https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_rtgwg_EDpT9lvKVDaBjI8g-5FQHznZMdTNI&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJasSzHeKs92fsD8Y&s=0D6i-TImKbNbK7b5xVr2UMjpZxd_fof-ni909q3UpYA&e= 

[deborah] Several ADs supported my concern on the status of this document. I noted Alia supports PS. Your suggestions below do help with some of the vagueness. Before clearing my Discuss, I would like to see how Alvaro's concerns are addressed.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJasSzHeKs92fsD8Y&s=pfjoFgZh4KBKpX7h8rBXNvSDwNhHAjoRrBE_LB231To&e= 

[deborah] 
My mail below (and to Acee) was identifying specific sentences in the document which I interpreted as illustrative of a general approach vs. a specific solution (my Discuss). On the Discuss criteria, refer to  point 10, "Standards Track document that contains only informational guidance". Plus, I endorsed Alvaro's (point 1, 2, 3).

[deborah] Good.

[deborah] Good.

Also changed (*3):

OLD: FSM abstract timer

NEW: FSM timer

[deborah] Good.

[deborah] So as not to go backwards on the discussion, I'll accept this document is for this specific algorithm (PS) vs. guidance for any algorithm (Info). Let's focus on making this PS quality.

[deborah] <cut text - no questions>

[deborah] It is if the PS uses two different names in the document itself for the algorithm being proposed as PS.

 > There are only two uses of "backoff", in the title and in the abstract. The document uses "SPF

[deborah] Several words were cut in your response, I commented this document (not the YANG document) uses two names for the algorithm: "backoff algorithm" and "SPF delay algorithm". Pick one.

Thanks

--Bruno

 > To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>; Alvaro Retana

 > Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>; draft-

 > Bruno has posted -08 version addressing Alvaro's default timer value request. Can you clear your

 >         Sorry for not responding earlier, I had an unexpected disruption to my schedule these last

 >         Cc: [email-masked]; Uma Chunduri <[email-masked]>;

 >         Subject: Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with

 >             While I agree with Alvaro's concerns, my concern is the appropriateness of this document

 >             This document should have a similar status as RFC6976 (Informational) which also

 >             specification". Especially as this document compares itself to RFC6976, saying RFC6976 is

---

From: <[email-masked]>
Date: Wed, 28 Feb 2018 18:42:26 +0000

Hi Deborah,

 > Sent: Wednesday, February 28, 2018 6:23 PM
> Hi Bruno,
 > 
 > Inline-
 > 
 > Quick summary - thanks for the proposed changes. You do need to pick "one" algorithm name for
 > this document. I will wait to clear once Alvaro's concerns are addressed.

OK.
Name uniformly changed to "SPF Back-off Delay algorithm". (note that we are open to a different name if needed)

I've uploaded a new version so that you can check and that we can close this thread

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

Thanks
--Bruno

 > [email-masked]; Acee Lindem (acee) <[email-masked]>; The IESG
 > <[email-masked]>; Alvaro Retana <[email-masked]>
 > We have engaged the discussion on his points. Thanks for the info that he is on vacation this week.
 > No problem, we'll obviously wait for this return.
 > 
 > mechanism that prevented transient loops saying "the mechanisms described in this document are
 > purely illustrative of the general approach and do not constitute a protocol specification". Especially
 > as this document compares itself to RFC6976, saying RFC6976 is a "full solution".
 > 
 > https://urldefense.proofpoint.com/v2/url?u=https-
 > 3A__mailarchive.ietf.org_arch_msg_rtgwg_pqGrmtI7MYVqU8tSNwId-
 > 2DQEROYs&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJ
 > asSzHeKs92fsD8Y&s=lSwLlzGBRCELFV0V0oBnY2bQ-A4OuduzADebFkfZG0A&e=
 > 
 > Regarding STD status, a distributed Link State IGP, requires, in order to produce consistent routing
 > table across the network, to perfom the same computation (SPF), using the same info/database, at
 > the same time.
 > 
 > Given that all implementations use SPF back off delay algorithms (by default), in order to fulfill this
 > routing consistency across the network, one STD SPF back off delay algo needs to be specific. By
 > doing so, this document helps addressing the above two latest points (same time, same LSDB).
 > 
 > https://urldefense.proofpoint.com/v2/url?u=https-
 > 3A__mailarchive.ietf.org_arch_msg_rtgwg_EDpT9lvKVDaBjI8g-
 > 5FQHznZMdTNI&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJ
 > asSzHeKs92fsD8Y&s=0D6i-TImKbNbK7b5xVr2UMjpZxd_fof-ni909q3UpYA&e=
 > 
 > [deborah] Several ADs supported my concern on the status of this document. I noted Alia supports
 > PS. Your suggestions below do help with some of the vagueness. Before clearing my Discuss, I
 > would like to see how Alvaro's concerns are addressed.
 > 
 > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-
 > 2Dcriteria.html&d=DwIGaQ&c=LFYZ-
 > o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=A2tvhbHEsp1wnyVMHQNQQZif9dyJ
 > asSzHeKs92fsD8Y&s=pfjoFgZh4KBKpX7h8rBXNvSDwNhHAjoRrBE_LB231To&e=
 > 
 > My mail below (and to Acee) was identifying specific sentences in the document which I
 > interpreted as illustrative of a general approach vs. a specific solution (my Discuss). On the
 > Discuss criteria, refer to  point 10, "Standards Track document that contains only informational
 > guidance". Plus, I endorsed Alvaro's (point 1, 2, 3).
 > 
 >  >
 > 
 > - That being said, that sentence does not really add anything to the specification. Hence if this is a
 > blocking point to you, I've just removed it. Problem solved.
 > 
 > [deborah] Good.
 > 
 >   >And later in
 > 
 > We have initiated a discussion with Alvaro regarding the additional specification of default
 > parameters for the specific cases where they are useful.
 > 
 >  > e.g. any
 > 
 > Personally, I'd tend to generally reply "yes". i.e., considering the node as a black box, if it's behavior
 > conforms to the behavior defined in the IETF document, I'd say that the node is compliant with the
 > IETF document.
 > 
 > [deborah] So as not to go backwards on the discussion, I'll accept this document is for this specific
 > algorithm (PS) vs. guidance for any algorithm (Info). Let's focus on making this PS quality.
 > 
 > The document defines a "backoff" procedure for the IGP SPF, by introducing a delay and a delay
 > which is increasing as the IGP keeps computing SPFs.
 > 
 > [deborah] Several words were cut in your response, I commented this document (not the YANG
 > document) uses two names for the algorithm: "backoff algorithm" and "SPF delay algorithm". Pick
 > one.
 > 
 > Thanks
 > 
 > --Bruno
 >  >
 > 
 >  > Thanks,
 > 
 >  > Deborah
 > 
 >  >
 > 
 >  >
 > 
 > ________________________________________________________________________________
 > _________________________________________
 >

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 28 Feb 2018 20:45:34 +0000

Ok for me - if Alvaro's comments are resolved-
Thanks-
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 28, 2018 1:42 PM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>; The IESG <[email-masked]>; Alvaro Retana <[email-masked]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

Hi Deborah,

OK.

Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo-2D09&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=o-3Cw0NaTHiAwueJLvH42YSvIvCS5ykWzfDqg0e0bq4&s=b7qB1gMCWU-sOTiC3fxI0QFjNp1bkvJmJ7yKs2Z8o2c&e= 

Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Drtgwg-2Dbackoff-2Dalgo-2D09&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=o-3Cw0NaTHiAwueJLvH42YSvIvCS5ykWzfDqg0e0bq4&s=elXNFgvb4fTgqLv83tf2MQ7UesF0BMoirNRe4vdWSuE&e= 

Thanks

--Bruno

 >  > Alvaro's concerns on incompleteness and vagueness. I am interested in Alvaro's response on

 > the

 > With a change of status to Informational, this document would be better scoped as providing

 > guidance vs. a specification."

 > Acee has replied on this point in the following thread, and ultimately you did not follow up. So I

 > though the point was closed.

 > [deborah] Considering Acee's reply, I was hoping the updated draft would take into consideration

 > my concerns.

 > Also, in case you missed it as the email was in a different thread, Alia has also stated that this

 > needs to be standard track.

 > - As Acee replied, this is just a statement about the reality of existing implementations and

 > deployments.

 >  > SPF delay algorithm that supports the IETF parameters can be used so long as it derives the

 > same

 > e.g., if the IETF document defines a timer of 3 seconds, it looks ok for me if an implementation

 > waits for 3 consecutive 1 second timers.

 > But any general answer from the IETF works for me. It seemed to me that the IETF does not give

 > position regarding conformance.

 > [deborah] It is if the PS uses two different names in the document itself for the algorithm being

 > proposed as PS.

 >  > "backoff algorithm". It refers to an "SPF delay algorithm" and lists the parameters. Either

 > "backoff"

 >  > To: BRUNGARD, DEBORAH A <[email-masked]>; The IESG <[email-masked]>; Alvaro

 > Retana

 >  > Bruno has posted -08 version addressing Alvaro's default timer value request. Can you clear

 > your

 >  > alternative algorithms." So it is not clear if it is the algorithm or the parameters which are

 > intended

 >  >         If this is to be PS, then you need to provide guidance on how an operator is to do the

 > upgrade

 >  >     The IETF can't just mandate that vendors implement the new standard SPF backoff

 > algorithm,

 >  > over the IGP domain (or at least an area). The standardization of the SPF Backoff algorithm is

 > the

 >  > deployed, this standard algorithm will greatly improve (but not eliminate) micro-loops in IGP

 > routing

 >  > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drtgwg-

 > 2Dspf-

 >  > mV3Tpp8iWGOSIp_fkDPkMuA&s=LvqOOWwzZ-

 > 3P6mF9xQUGj2HWklodlOlWO94fprhgwc8&e=

 >  >             https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-

 > 2Dietf-

 >  >             While I agree with Alvaro's concerns, my concern is the appropriateness of this

 > document

 >  >             specification". Especially as this document compares itself to RFC6976, saying

 > RFC6976 is

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

 > This message and its attachments may contain confidential or privileged information that may be

 > protected by law;

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