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

Jeffrey Haas <jhaas@pfrc.org> Mon, 20 March 2017 20:35 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 639C3126C0F; Mon, 20 Mar 2017 13:35:07 -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 TMHzHLnp7yoZ; Mon, 20 Mar 2017 13:35:05 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 85FD0127342; Mon, 20 Mar 2017 13:35:05 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D3A481E33F; Mon, 20 Mar 2017 16:41:25 -0400 (EDT)
Date: Mon, 20 Mar 2017 16:41:25 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Job Snijders <job@ntt.net>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20170320204125.GH28021@pfrc.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170320201455.micjs4yvzvyoycw6@Vurt.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Kk5XzooyMwXx_AMm4HoKYP_mn-U>
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:35:07 -0000

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. :-)

> 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.

I suspect the point you've overlooked is the N-bit is intended to indicate
support for this on a per AFI-SAFI basis.  This is something you have to
explicitly ask for.  It also isn't something that makes sense in many
scenarios, especially Internet.

> 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?

It's a dependency, yes.

> 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"..

It will depend on whether you want to trigger this behavior or not.  The
semantics change from simply "I typed clear bgp" to "this session must not
go through this mechanism if you've configured it".

> 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.

Naming things is one of the two traditionally hard problems of computer
science. 

-- Jeff