Re: [Idr] Possible usecases of one-time selective route refresh

Rob Shakir <rjs@rob.sh> Sun, 14 November 2010 22:49 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781DE3A6B5E for <idr@core3.amsl.com>; Sun, 14 Nov 2010 14:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Level:
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl-3tlZLxL79 for <idr@core3.amsl.com>; Sun, 14 Nov 2010 14:49:01 -0800 (PST)
Received: from mocha.rob.sh (mocha.rob.sh [193.239.32.250]) by core3.amsl.com (Postfix) with ESMTP id 578E83A6C41 for <idr@ietf.org>; Sun, 14 Nov 2010 14:49:01 -0800 (PST)
Received: from [193.47.147.2] (helo=2.kerrison.flarg.net) by mocha.rob.sh with esmtpa (Exim 4.66) (envelope-from <rjs@rob.sh>) id LBWCQS-0023MZ-4N; Sun, 14 Nov 2010 22:49:40 +0000
From: Rob Shakir <rjs@rob.sh>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 Nov 2010 22:49:22 +0000
To: idr@ietf.org, Jie Dong <dongjie_dj@huawei.com>
Message-Id: <2DDDE57A-0AB0-485A-B26A-632ADF0FA01A@rob.sh>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: Re: [Idr] Possible usecases of one-time selective route refresh
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sun, 14 Nov 2010 22:49:02 -0000

[...Split from the draft-chen-ebgp-error-handling thread for readability...]

On 11 Nov 2010, at 14:47, Jie Dong wrote:

> Also there can be other usecases of these lightweight maintenance tool. More thoughts on the usecases would be appreciated.

Hi Jie,

From my point of view, there's a set of problems that aren't considered in these use cases, that is probably quite useful from an operator point of view.

In VPNv4 routing implementations, we have a set of local VRFs configured on a PE, which have specific import criteria based on route-targets. To keep each VRF RIB consistent is not a problem based on receiving an initial copy of the VPNv4 RIB, however, on a policy change, a problem exists in ensuring that the local VRF's tables are consistent with the new import policy (and as such, from a customer's perspective, that their local L3VPN actually reflects the changes they requested on all PE devices they connect to). This problem cannot be solved locally, in general, due to the fact that most PE implementations do not hold the Adj-RIB-In in memory, due to resource constraints - inbound filtering is performed based on imported RTs.

At the moment, to apply such a policy change, one can either stipulate that VRF tables are only consistent based on newly received UPDATEs (i.e. as each remote PE re-advertises prefixes), or initiate a Route Refresh. At the current time, this requires the remote neighbour to re-advertise the complete RIB. Since the remote speaker is typically a route reflector in many SP deployments, this can result in 600K+ prefixes being re-sadvertised to the PE (most of which will be re-discarded due to inbound filtering based on imported route-targets). Therefore, from our perspective, if the local device can perform a route refresh based on the specific import criteria for the VRF that has changed policy, this constrains the number of prefixes re-advertised to the PE from the RR to the number that really require refresh to ensure that the local RIB is consistent. This is a significant advantage over the current behaviour.

Whilst this problem could be solved with ORF at the current time - this does not achieve the same bound on the problem - specific PEs, for example those supporting NNI, may import a large subset of the VPNv4 RIB for the AS - and hence the general ORF policy from the RR to the PE may still result in a refresh that results in a large number of prefixes being sent.

From a resource consumption perspective, since the PE has generated the ORF, then the RR needs only to process this filter, and apply it to egress prefixes. If we assume that building the UPDATEs is the most taxing activity in the re-advertisement of routes to the PE, then this behaviour should result in a net CPU reduction for the devices.

For this reason, I would see this draft as a useful addition to the protocol.

Kind regards,
Rob