Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification
Job Snijders <job@ntt.net> Mon, 20 March 2017 20:15 UTC
Return-Path: <job@instituut.net>
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 938681276AF for <idr@ietfa.amsl.com>; Mon, 20 Mar 2017 13:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level:
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=unavailable 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 IQ6zIFN8DeKp for <idr@ietfa.amsl.com>; Mon, 20 Mar 2017 13:15:06 -0700 (PDT)
Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9760129506 for <idr@ietf.org>; Mon, 20 Mar 2017 13:15:03 -0700 (PDT)
Received: by mail-pf0-f177.google.com with SMTP id p189so47254997pfp.1 for <idr@ietf.org>; Mon, 20 Mar 2017 13:15:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ybwuQ7JkUAQV6yttoB45QrHB5p+/gwL1BsJEyL9EISw=; b=TXmVJtli7PuHhCSUyFM2xqjLkV3rhkXysi0b0XvH6Az0Y6x/R6mw11qwMlr+rOITp/ JXfmYjfchWFvUKLStx0e470/xE6iepuypaNxtKF0XAhSig875upmqyXYHz34hEaIB0Qz R5SmkiO9FldgucVBTunXCy0DP3+JMEWERDRL4FUlsH9Q9ue5ESXC2sivw5fJ2t/Vgb8O GuOsBoH9oMntL7Qm6vJkep58TtSXGjqSozyMuerPA8mTDKFGjnGgXJgkHhozbU0KTU7K 9ziQ6k0fz5K8NEFOoTihCsiEHdmOMbtutK5pFmy7Y8prwUFBmybRuTiLB1pDY+yeqNVM tGyw==
X-Gm-Message-State: AFeK/H3QuARZ04iTVjpccfTZ0QN3fmjVSA0PYQYVo9/YAQ3QQOa7mh6ojx2m03hHnj8Wkg==
X-Received: by 10.98.160.193 with SMTP id p62mr35365962pfl.67.1490040903267; Mon, 20 Mar 2017 13:15:03 -0700 (PDT)
Received: from localhost ([192.147.168.22]) by smtp.gmail.com with ESMTPSA id l1sm15761027pfk.8.2017.03.20.13.15.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 13:15:02 -0700 (PDT)
Date: Mon, 20 Mar 2017 21:14:55 +0100
From: Job Snijders <job@ntt.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170320201455.micjs4yvzvyoycw6@Vurt.local>
References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com> <20170320194414.GD26130@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170320194414.GD26130@pfrc.org>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ye3e4V-epVttjnKQu9kH6pIdWUc>
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 20:15:09 -0000
Hi Jeff, On Mon, Mar 20, 2017 at 03:44:14PM -0400, Jeffrey Haas wrote: > > 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. ack. Please read the draft. We may have a fundamental problem on our hands here. > > 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. 1/ To emphasize the congruency issue here: BGP Hold Timer expiration often (from the Operator's perspective) an unplanned event. BGP Hold Timers usually expire because there is an issue with the lower layer network. If there is an issue with the lower layer network, we should not continue to forward traffic over that path. If I understand draft-ietf-idr-bgp-gr-notification correctly, that is what would happen if both sides through capabilities negotation understand they both support draft-ietf-idr-bgp-gr-notification. "make before break" or "ignore this break" are doable when events are planned, but this draft touches upon scenarios which happen without planning from the operator's side, where we should be careful with our assumptions about why a Hold Timer expired. > > 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. 2/ So draft-uttaro-idr-bgp-persistence is zombie from IETF perspective, but there is shipping code, so in order to resurrect draft-uttaro-idr-bgp-persistence properly (and finish the project?), draft-ietf-idr-bgp-gr-notification needs to move forward, is that the chain of events? 3/ If I may ask, why isn't BGP Cease NOTIFICATION message subcode 4 "Administrative Reset" used to perform the 'hard reset' function, and isn't subcode 9 (the suggested value) requested as a new feature called 'soft reset'? This way we don't break people's preconceptions about what it means to type in "clear neighbor 1.2.3.4".. By declaring "subcode 9" to be a hard clear, it appears to me the meaning of 'Administrative Reset (subcode 4)' is redefined, and redefining existing constructs might not be an easy task. Kind regards, Job
- [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