Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Re: Factors affecting in-region utilization - way forward?

Kofi ansa akufo kofi.ansa at
Sun Jul 20 17:56:23 UTC 2014


On 20 July 2014 21:16, Mark Tinka <mark.tinka at> wrote:

> On Sunday, July 20, 2014 07:00:13 PM Stephen Wilcox wrote:
> > We are also scaling a system that was designed 30 years
> > ago not to do what it does today. Breaking the
> > stereotypes could prove to be problematic - core routers
> > handling more than a few Mbps will switch in hardware
> > and rapid growth in the number of routes in the global
> > table could quickly overwhelm certain in service
> > devices. Its okay to understand your 500k FIB limited
> > box has a lifetime of 3yrs when you buy it but if you
> > see irresponsible deaggregation or sudden announcement
> > of small blocks you might cause people's equipment to
> > become EOL faster than they can cope.
> Which is true, but the problem is this issue is not equally
> widespread.
> So if a service provider takes action against de-aggregates
> (either by blocking them off or charging for them), it puts
> them at a disadvantage with their competitors.
> > Is there data on this (I am not doubting you just that I
> > haven't heard this being stated before)
> As a function of implementation and hardware capability -
> not so much the protocol itself.
> As much as I discourage the use of NAT in networks, I believe address
translation has its niche in the ecosystem. Its has played a key role in
scaling a system that was born over 30 years ago.

What I see stereotypical is people condemning NAT based on trivial
negatives. Needless to say most of us run networks and know the reality on
the ground.

I would rather like to see solid arguments such as how NAT affects the
battle against Cyber Threats. Issues like "function of implementation and
hardware capability" seem far fetched if I understand the semantics :)

I stand to be corrected.

> _______________________________________________
> rpd mailing list
> rpd at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list