Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

Jeffrey Haas <> Mon, 20 March 2017 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29D2D12951B; Mon, 20 Mar 2017 12:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5kNm6_fS2qNO; Mon, 20 Mar 2017 12:37:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 722AF1274D2; Mon, 20 Mar 2017 12:37:54 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 8F6ED1E33F; Mon, 20 Mar 2017 15:44:14 -0400 (EDT)
Date: Mon, 20 Mar 2017 15:44:14 -0400
From: Jeffrey Haas <>
To: Job Snijders <>
Cc: "Jakob Heitz (jheitz)" <>, "" <>, "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 19:37:56 -0000


On Sat, Mar 18, 2017 at 10:53:53AM +0000, Job Snijders wrote:
> Given the 50+ years of combined IETF experience the authors of this draft
> possess, I'm somewhat surprised to see a suggested value in the IANA
> considerations instead of "TBD". See the last major bullet point here:

Unfortunately it's not an uncommon practice, and one we're moving out of
thankfully.  If you look around other working groups, even other BGP working
groups like bess, it's not uncommon.

> Furthermore, shouldn't the "Hard Reset" be called "Really Really Really
> Reset"? I am skeptical whether the principles of graceful restart should be
> applied to the notification mechanism. In
> we are
> describing a procedure that strongly relies on the currently understood
> semantics of expiration of BGP Hold Timers and the Administrative Shutdown:
> "STOP sending traffic".

I haven't yet read this draft, so take my further comments with that under

> I find it hard to reconcile how we can have both "My control-plane
> temporarily going away, but keep sending traffic" and "data-plane is
> broken, bgp subsequently dies, don't send traffic". The exact failure
> scenario which triggers the expiration of the BGP Hold Timers cannot be
> known at OPEN when the capabilities are exchanged. The GR NOTIFICATION
> seems to distort the congruency between data-plane and control-plane.
> Perhaps there should be an implementation guideline which encourages
> vendors to by default, disable this mechanism on non-RFC3021/RFC6164 links?
> Has draft-idr-bgp-gr-notification been vetted in the wild? What were the
> results and under which circumstances is the mechanism useful? Am I missing
> something?

The non-obvious connection is it's a requirement of
draft-uttaro-idr-bgp-persistence (long-lived graceful restart).  There's
code shipping for this feature.  I *believe* that it's another vendor as
well, but can't confirm from memory.  

There has been some discussion that LLGR needs to be resurrected from zombie
draft state.

-- Jeff