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

Steve Crocker <steve@shinkuro.com> Thu, 31 December 2015 19:21 UTC

Return-Path: <steve@shinkuro.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 E83531A8A3F for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.782
X-Spam-Level:
X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=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 bsr2cY7k_E7I for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:21:26 -0800 (PST)
Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id B9E811A8A28 for <ietf@ietf.org>; Thu, 31 Dec 2015 11:21:26 -0800 (PST)
Received: from dummy.name; Thu, 31 Dec 2015 19:21:26 +0000
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
From: Steve Crocker <steve@shinkuro.com>
In-Reply-To: <56857EC9.9020707@bogus.com>
Date: Thu, 31 Dec 2015 14:21:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CE862C5-DC91-4BFB-A225-018AE96F7339@shinkuro.com>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <5684FCDB.7010009@mnt.se> <A074CA07-691E-41A7-B1D7-33F4ECBED5A9@puck.nether.net> <568579FB.6030702@gmail.com> <56857EC9.9020707@bogus.com>
To: IETF <ietf@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/mBnLCcatpzD6cwA7013nLuh32fw>
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:21:28 -0000

I’ve always assumed the proper place to implement BCP 38 is at the edge of the network.  I’ve also assumed that part of the knowledge one network ought to have about another is whether the other network implements BCP 38 at its edge and requires its peers to do so at their edges and require their peers, etc.  Thus, there ought to be an ever growing collection of networks that have agreed that packets entering their networks have had their source addresses checked at their source.  Checking the source addresses as packets traverse from one tier one network to another or from a tier two network to a tier one network should not be necessary, and I can well understand why this would be a performance issue.

Steve




On Dec 31, 2015, at 2:15 PM, joel jaeggli <joelja@bogus.com> wrote:

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