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

"BRUNGARD, DEBORAH A" <> Wed, 28 February 2018 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A05D812785F; Wed, 28 Feb 2018 03:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Y56rVgmwW8e; Wed, 28 Feb 2018 03:48:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E559126BF6; Wed, 28 Feb 2018 03:48:24 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id w1SBZfXH035316; Wed, 28 Feb 2018 06:48:19 -0500
Received: from ( []) by with ESMTP id 2gdn7e5037-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Feb 2018 06:48:19 -0500
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id w1SBmIbg019885; Wed, 28 Feb 2018 06:48:18 -0500
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w1SBmCOv019796; Wed, 28 Feb 2018 06:48:12 -0500
Received: from ( []) by (Service) with ESMTP id 8C9CB40006B6; Wed, 28 Feb 2018 11:48:12 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id 7310140006B4; Wed, 28 Feb 2018 11:48:12 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0361.001; Wed, 28 Feb 2018 06:48:12 -0500
To: "Acee Lindem (acee)" <>, The IESG <>, "Alvaro Retana" <>
CC: "" <>, "" <>, Uma Chunduri <>, "" <>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
Thread-Topic: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)
Thread-Index: AQHTqp74EopTMk21x0ub2Sen+/QcaqOv7WsAgAQY88CAAK7egIAETbOAgACnItA=
Date: Wed, 28 Feb 2018 11:48:11 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-28_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802280141
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Feb 2018 11:48:27 -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.


-----Original Message-----
From: iesg [] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, February 27, 2018 2:36 PM
To: BRUNGARD, DEBORAH A <>om>; The IESG <>rg>; Alvaro Retana <>
Cc:;; Uma Chunduri <>om>;
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? 



On 2/24/18, 8:52 PM, "Acee Lindem (acee)" <> wrote:

    Hi Deborah, 


    On 2/24/18, 4:07 PM, "BRUNGARD, DEBORAH A" <> wrote:


        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.


    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. 






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

        From: Acee Lindem (acee) [] 

        Sent: Wednesday, February 21, 2018 7:53 PM

        To: BRUNGARD, DEBORAH A <>om>; The IESG <>

        Cc:; Uma Chunduri <>om>;;

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


        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: . Finally, there have been several prototype implementations validating the algorithm specification's completeness and clarity. 










            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 


            for more information about IESG DISCUSS and COMMENT positions.






            The document, along with other ballot positions, can be found here:


















            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.