Re: What to improve? BCP-38/SAC-004 anyone?

joel jaeggli <joelja@bogus.com> Thu, 31 December 2015 19:15 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C41A8A1E for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 z2K-5FNKJ6VD for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:15:24 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144F51A8A1D for <ietf@ietf.org>; Thu, 31 Dec 2015 11:15:24 -0800 (PST)
Received: from mb-2.local ([IPv6:2601:1c0:c102:22fb:b1f0:895a:628c:ab66]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tBVJFL9o089444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 31 Dec 2015 19:15:22 GMT (envelope-from joelja@bogus.com)
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Jared Mauch <jared@puck.nether.net>, Leif Johansson <leifj@mnt.se>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <5684FCDB.7010009@mnt.se> <A074CA07-691E-41A7-B1D7-33F4ECBED5A9@puck.nether.net> <568579FB.6030702@gmail.com>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56857EC9.9020707@bogus.com>
Date: Thu, 31 Dec 2015 11:15:21 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <568579FB.6030702@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="tBVk2Ki2nIPQxSX6a3sfJIj4E5J6rQ5Cp"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5uXuijXO0oSx1zD958L268HwxwE>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2015 19:15:25 -0000

On 12/31/15 10:54 AM, Brian E Carpenter wrote:
> On 01/01/2016 06:04, Jared Mauch wrote:
> ...
>> The reason we (as an operator) can’t use BCP-38 is the vendor hardware can’t do it at line-rate and the performance hit is too much to sustain.
> 
> That seems worth a bit more discussion. I'd always naively assumed that BCP38 was
> scalable since all it appears to need is a prefix match, and routers are very
> good at matching prefixes; it's just that they don't normally match the source
> prefix. Could some router-vendor person comment on this?

Not all routers use ternary cams , and some that do employ them
algorithmically, so it's not one and done in either case. if you have
multiple depedant memory accesses associated with a match, those need to
be serialized.

If the maximum pps of your linecard drops by say 50% when you enable a
feature that's a bit of a problem.

> There's another issue here, though. BCP-38 and uRPF are also a potential cause of
> connectivity problems: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host
> 
>    Brian
> 
>