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