Re: [Idr] new thread regarding capabilities handling

Enke Chen <enkechen@cisco.com> Thu, 27 April 2017 17:25 UTC

Return-Path: <enkechen@cisco.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 32DC1129B35 for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 10:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 psaFIo79HR7T for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 10:25:14 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704F1129B45 for <idr@ietf.org>; Thu, 27 Apr 2017 10:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1507; q=dns/txt; s=iport; t=1493313749; x=1494523349; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fNJSUmz+OTxYTcYA0NNxVZiwwm9CpcZvH8X5yL2PHsU=; b=A5NwCUVVTpdrJ4vC1FLQ+0nwTHWcTNSgvms25bwoVOiBzTtr/v3HcLo9 8VVWLMtHPe5rerhskTgQ+TCEO9uHyD01cEB9JA+RnMINQgD3Wmy0yRcfO l3GQ4qc9ovvmU7upiOVky+PJ2EB597dWP/mbzpkzptf9+G7pgohx1wH4P M=;
X-IronPort-AV: E=Sophos;i="5.37,384,1488844800"; d="scan'208";a="241510818"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 17:22:28 +0000
Received: from [10.82.250.87] (rtp-vpn6-597.cisco.com [10.82.250.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3RHMRUS009018; Thu, 27 Apr 2017 17:22:28 GMT
To: Robert Raszuk <robert@raszuk.net>
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> <CA+b+ERnfz9kVgJQBhwD2atq1yz+0fWCwYn8P7RsWuZdeqRfU-g@mail.gmail.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, idr wg <idr@ietf.org>, Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <e79bcc96-cd21-6370-a9da-40e58068a8a6@cisco.com>
Date: Thu, 27 Apr 2017 10:22:27 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERnfz9kVgJQBhwD2atq1yz+0fWCwYn8P7RsWuZdeqRfU-g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bSPeim0V0hFY_btIXql1RlGYvTo>
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 17:25:15 -0000

Certainly with GR, the need for "Dynamic Capability" is significantly reduced.

Thanks.  -- Enke

On 4/27/17 6:44 AM, Robert Raszuk wrote:
>  
> 
>     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?
> 
> 
> ​Since you asked :) ....
> 
> 1. Actually number of customers asked for it various vendors however non of them showed sufficient money so naturally features which are not associated with significant revenue are not that high on anyone's list (unless BGP code you are maintaining is your hobby). 
> 
> 2. If we talking intra-domian in most cases ​you go via RRs. And it is a good practice to configure your RR side either with multiple loopbacks or even different contexts for each address family so each SAFI is independent from one another. That way within your domain you can add/delete AFI/SAFIs without impacting others. Moreover in case of using multiple context (VMs or LXCs for reflection) you get multithreading across SAFIs for free too. 
> 
> 3. And last in general what really matters is to continue forwarding packets and not to impact your other peers by BGP session reset. And here comes quite well supported feature BGP Graceful Restart (RFC4724) It is applicable for both iBGP and eBGP peers. And honestly many networks still do not have it enabled even though it has been shipping for long time in most major BGP code basis. 
> 
> Kind regards,
> Robert.
> 
>