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

"Susan Hares" <shares@ndzh.com> Tue, 21 March 2017 17:14 UTC

Return-Path: <shares@ndzh.com>
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 64572129C37; Tue, 21 Mar 2017 10:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 Eg8f2WO5SqOi; Tue, 21 Mar 2017 10:14:30 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 0F132129C31; Tue, 21 Mar 2017 10:14:26 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.19.173;
From: "Susan Hares" <shares@ndzh.com>
To: "'John G. Scudder'" <jgs@juniper.net>, "'Jeffrey Haas'" <jhaas@pfrc.org>, "'Job Snijders'" <job@ntt.net>
Cc: <idr-chairs@ietf.org>, <idr@ietf.org>
References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com> <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com> <20170320194414.GD26130@pfrc.org> <20170320201455.micjs4yvzvyoycw6@Vurt.local> <20170320204125.GH28021@pfrc.org> <D637725D-1469-437D-AACB-E4BDB69EB07F@juniper.net>
In-Reply-To: <D637725D-1469-437D-AACB-E4BDB69EB07F@juniper.net>
Date: Tue, 21 Mar 2017 13:09:21 -0400
Message-ID: <038301d2a265$e2a73050$a7f590f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJNtEkTgzlTKZaIcQptCFnf9VYXegKMmzFfARE8EXkBphrc1ADa2DYnAZHOVWaga93+4A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JQ4YUK2YGZcMM_PDmYLzKPISUD4>
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: Tue, 21 Mar 2017 17:14:31 -0000

John, Jeff, Keyur and Job: 

It sounds like these two drafts are protocol and grow operational notes.
Is this correct? 

Sue 

-----Original Message-----
From: John G. Scudder [mailto:jgs@juniper.net] 
Sent: Monday, March 20, 2017 5:50 PM
To: Jeffrey Haas; Job Snijders
Cc: idr-chairs@ietf.org; idr@ietf.org
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

On Mar 20, 2017, at 4:41 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Mon, Mar 20, 2017 at 09:14:55PM +0100, Job Snijders wrote:
> [session culling]
>>> 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 read it. It's a weird hack, but it works. :-)

With respect to what "culling" calls "Voluntary BGP Session Teardown",
there's no problem. A pair of implementations that implement gr-notification
would already be expected to do the right thing when the session was
administratively shut down, by sending a hard reset.

With respect to what "culling" calls "Involuntary BGP Session Teardown",
there is potentially a problem, but I think it's not insurmountable. The
problem, to the extent it exists, is that "culling" suggests the IX switch
fabric should be configured to block BGP traffic, causing the hold time to
expire. gr-notification interferes by putting the session into GR mode:

   When a BGP speaker resets its session due to a HOLDTIME expiry, it
   should generate the relevant BGP NOTIFICATION message as mentioned in
   [RFC4271], but subsequently it MUST follow the rules for the
   Receiving Speaker mentioned in Section 4.1.

At first this might seem alarming, but my observation is that the weird hack
already relies on waiting several minutes for the hold time to expire. So,
it doesn't seem terrible to add a few more minutes to wait for the stale
route timeout as well. Although "culling" doesn't discuss how to determine
the maintenance can proceed, it would seem both prudent and straightforward
to do so by monitoring the traffic level between the affected peers, since
presumably the IX operator doesn't have a priori knowledge of the hold time
in use. Once routing has converged away from the path, the traffic level
will drop, and the maintenance can proceed, regardless of what perversions
are in use in the control plane. 

--John

P.S.: I take no position, in this note, as to whether the suggestion in
"culling" to filter BGP control traffic as an IX management practice is a
good one.