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
- [Idr] Early allocation for draft-ietf-idr-bgp-gr-… Jakob Heitz (jheitz)
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Job Snijders
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Susan Hares
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jakob Heitz (jheitz)
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Keyur Patel
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… John G. Scudder
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… John G. Scudder
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Job Snijders
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… John G. Scudder
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Nick Hilliard
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Job Snijders
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Job Snijders
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Susan Hares
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Susan Hares
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… John G. Scudder
- Re: [Idr] Early allocation for draft-ietf-idr-bgp… Jeffrey Haas