Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13
Jay Borkenhagen <jayb@braeburn.org> Thu, 18 January 2018 16:10 UTC
Return-Path: <jayb@oz.mt.att.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD0126CBF for <grow@ietfa.amsl.com>; Thu, 18 Jan 2018 08:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25] autolearn=no 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 vQQJc23xCfTa for <grow@ietfa.amsl.com>; Thu, 18 Jan 2018 08:10:47 -0800 (PST)
Received: from hrabosky.cbbtier3.att.net (hrabosky.cbbtier3.att.net [12.0.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2914B1204DA for <grow@ietf.org>; Thu, 18 Jan 2018 08:10:47 -0800 (PST)
Received: from oz.mt.att.com (zoe [12.0.1.45]) by hrabosky.cbbtier3.att.net (Postfix) with ESMTP id ADE1311447 for <grow@ietf.org>; Thu, 18 Jan 2018 16:10:46 +0000 (UTC)
Received: by oz.mt.att.com (Postfix, from userid 1000) id 95E13A41307; Thu, 18 Jan 2018 11:10:46 -0500 (EST)
X-Mailer: emacs 24.3.1 (via feedmail 11-beta-1 I); VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23136.50942.493828.893930@oz.mt.att.com>
Date: Thu, 18 Jan 2018 11:10:38 -0500
From: Jay Borkenhagen <jayb@braeburn.org>
To: bruno.decraene@orange.com, Susan Hares <shares@ndzh.com>, grow@ietf.org
In-Reply-To: <23136.45292.272358.798575@oz.mt.att.com>
References: <151626515117.10817.158961951180113598@ietfa.amsl.com> <14152_1516274355_5A6082B3_14152_10_1_53C29892C857584299CBF5D05346208A4795F049@OPEXCLILM21.corporate.adroot.infra.ftgroup> <00dd01d3904f$0025a6c0$0070f440$@ndzh.com> <837_1516279847_5A609827_837_146_1_53C29892C857584299CBF5D05346208A479602FE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <23136.45292.272358.798575@oz.mt.att.com>
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/IKFYOvu0IF8KtWGoBSuIx0iMZy4>
Subject: Re: [GROW] Opsdir last call review of draft-ietf-grow-bgp-gshut-13
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2018 16:10:49 -0000
[resend - apologies for any dupes] Distro cut *way* down. Regarding the suggestion for "logging knobs": - if it's just logging that a gshut action was taken, that's a local implementation decision -- no need to mention it in the draft. - if it's "Possibly raising alarms when something seems wrong", that would be a bad idea. There *will* be instances when traffic remains on the link even after the graceful shutdown initiator has signaled an approaching shutdown. To keep things simple and to allow the gshut draft to continue making progress, I'd prefer to leave it as-is. Thanks. Jay B. bruno.decraene@orange.com writes: OK, Thanks Susan. --Bruno -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 18, 2018 12:25 PM To: DECRAENE Bruno IMT/OLN Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org; ops-dir@ietf.org Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Bruno: I'm sorry I'm this late for the review. On the editorial nit, if you think it helps - send it to the RFC editor. On the logging knobs, you understood my point. Logs should cover what is section 4.2. However, since the document is in the RFC editor's queue - it is your choice. If you get a chance to edit it in - fine. If not, those people who implement the gshut will probably put it in. Thanks for asking, Susan Hares -----Original Message----- From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Thursday, January 18, 2018 6:19 AM To: Susan Hares Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org; ops-dir@ietf.org Subject: RE: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Hi Susan, Thanks for your time reviewing this document and you below comments. Please see my replies inline [Bruno] Note that however fast I'm answering to your review, that document is now in RFC editor queue, and hence technical changes are much more difficult. (AFAIK, would require specific approval from the responsible AD). Thanks for taking this into account. -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, January 18, 2018 9:46 AM > To: ops-dir@ietf.org Cc: grow@ietf.org; draft-ietf-grow-bgp-gshut.all@ietf.org; ietf@ietf.org > Subject: Opsdir last call review of draft-ietf-grow-bgp-gshut-13 Reviewer: Susan Hares > Review result: Has Nits Status: Nits The operational procedures described in this process for the gshut comment are accurately covered, and SHOULD work well. The Appendices A-C add to an operations document and should be retained for publication. [Bruno] ok, thanks. Technical nit: location of technical nit: (section 4.3) The document indicats that the "BGP implementers SHOULD provide configuration knobs that utilize teh GRACEFUL_SHUTDOWN community." > What the problem is: The document does not say is that their should be error reporting knobs to track the use of GRACEFUL_SHUTDOWN community. This can go in section 4.3 in one or two sentences. [Bruno] Could you please elaborate on this? What do you have in mind by "error reporting knobs"? Thinking about this, what I could think of would be logs detailing the steps in section 4.2. Possibly raising alarms when something seems wrong. (e.g. after waiting for BGP convergence, there is still some traffic sent/received over the interface(s) related to the EBGP session) Is this what you were thinking about? Editorial nit: section 3. paragraph 2, p. 3 > /This is because alternate paths can be hidden by knodes of an AS./ commment: The implied "this" is too vague for a specification. > Fix:/This lack of path occurs because alternate paths can be hidden by nodes of an AS."/ [Bruno] I agree that your proposed text makes it more explicit, which is always better in a specification (when it's not redundant). However, I would note 2 points: - section 3 is part of the introduction to the problem space. It explains the root cause of the problem. It's not part of the graceful shutdown specification. - The text you are referring to is a paragraph starting with: "First, some routers can have no path toward an affected prefix, and drop traffic destined to this prefix. This is because alternate paths can be hidden by nodes of an AS." Hence "This" refers to the short sentence which is immediately before. I don't feel that there is much ambiguity. That being said, as you classify your comment as an editorial nit, I could propose to forward it to the RFC editor, and let the RFC editor propose a resolution. Would this be ok for you? Thanks, Best regards, --Bruno _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
- [GROW] Opsdir last call review of draft-ietf-grow… Susan Hares
- Re: [GROW] Opsdir last call review of draft-ietf-… bruno.decraene
- Re: [GROW] Opsdir last call review of draft-ietf-… Susan Hares
- Re: [GROW] Opsdir last call review of draft-ietf-… bruno.decraene
- Re: [GROW] Opsdir last call review of draft-ietf-… Jay Borkenhagen
- Re: [GROW] Opsdir last call review of draft-ietf-… Jay Borkenhagen
- Re: [GROW] Opsdir last call review of draft-ietf-… heasley
- Re: [GROW] Opsdir last call review of draft-ietf-… Susan Hares