ietf
[Top] [All Lists]

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

2015-12-31 13:21:54
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(_at_)bogus(_dot_)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