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

Jeffrey Haas <jhaas@pfrc.org> Mon, 20 March 2017 19:37 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D2D12951B; Mon, 20 Mar 2017 12:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kNm6_fS2qNO; Mon, 20 Mar 2017 12:37:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 722AF1274D2; Mon, 20 Mar 2017 12:37:54 -0700 (PDT)
Received: by slice.pfrc.org (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 <jhaas@pfrc.org>
To: Job Snijders <job@ntt.net>
Cc: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170320194414.GD26130@pfrc.org>
References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kR3An9M0CtSS0fuW9h_D68wRIfs>
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 19:37:56 -0000

Job,

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:
> https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft

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
> https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 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
consideration.

> 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