Re: [Idr] new thread regarding capabilities handling

Jeffrey Haas <jhaas@pfrc.org> Thu, 27 April 2017 20:13 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 E1BEC129543 for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 13:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CB9LEbgWZGvJ for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 13:13:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B83471286B1 for <idr@ietf.org>; Thu, 27 Apr 2017 13:10:14 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 0F81D1E377; Thu, 27 Apr 2017 16:17:37 -0400 (EDT)
Date: Thu, 27 Apr 2017 16:17:36 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Enke Chen <enkechen@cisco.com>, idr@ietf.org
Message-ID: <20170427201736.GF22975@pfrc.org>
References: <alpine.DEB.2.02.1704270713380.5591@uplift.swm.pp.se> <a7a10b72-2215-9968-e4c8-0592e29ce893@cisco.com> <alpine.DEB.2.02.1704270812470.5591@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1704270812470.5591@uplift.swm.pp.se>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0rnOab0-NEW3xR-ICENyf6GDpHI>
Subject: Re: [Idr] new thread regarding capabilities handling
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: Thu, 27 Apr 2017 20:13:57 -0000

On Thu, Apr 27, 2017 at 08:14:07AM +0200, Mikael Abrahamsson wrote:
> >  https://www.ietf.org/archive/id/draft-ietf-idr-dynamic-cap-14.txt
> 
> So this is a draft first posted in 2001, with a last revision in 2011.
> 
> What's the back story here? This is obviously a well-known
> understood problem then for 16 years already, why don't we still
> have this in 2017?

Part of the issue with dynamic caps was that they renegotiated capabilities
in general.  The edge cases of having to rebuild everything dynamically that
you could negotiate and still keep a peering session up was... ugly.

A simple example would be what would happen if you added or deleted the
add-paths capability. 

I know there was discussion at one point to simplify the proposal to simply
to allow new AFI/SAFI to be re-negotiated.

The BGP multisession proposal tried to cover one other piece of the
headache.  Today, if you get a failure in one AFI/SAFI, we tear down BGP.
(You're allowed to "shut it down", but such well behaved failures are
relatively few.)  By having different sessions for the AFI/SAFI, you get
structural segregation of those classes of packet formatting errors.

The issues with multisession, aside from burning precious sockets, is that
there's state that is really shared among the family types.  The question
then becomes how you share that state appropriately when the sessions can
move at different asynchronous paths.

-- Jeff