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

"Acee Lindem (acee)" <> Thu, 22 February 2018 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D41212E037; Wed, 21 Feb 2018 16:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3-JyXOdq0L_z; Wed, 21 Feb 2018 16:52:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53DC312E034; Wed, 21 Feb 2018 16:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3052; q=dns/txt; s=iport; t=1519260754; x=1520470354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K/+neYcm9DOPaSk/C51K54nU8SGpPIbh7hzy5WPTAto=; b=eD11vpYFH4P0zTNto6Yg9/ctTJtraLd5JitwmWLQyWVHTAxzchBDhMQr NhDIisXzqFKKA1Ic2Whe4taTFlGU7tyJtb7wQZV7CAsfs8qTtVEHPnaBK 69tpuL7ce0Hl8UocrX5gW/IRCFalwwxK0lY8xrt21lKz/62RyJvzp9/XJ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.47,376,1515456000"; d="scan'208";a="73567900"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 00:52:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w1M0qX06018116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Feb 2018 00:52:33 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Feb 2018 19:52:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 21 Feb 2018 19:52:32 -0500
From: "Acee Lindem (acee)" <>
To: Deborah Brungard <>, The IESG <>
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: AQHTqp72NqhoQQMJl0Ocdr+OlgE/IqOvmZcA
Date: Thu, 22 Feb 2018 00:52:32 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 22 Feb 2018 00:52:36 -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: 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.