NAT444 or ?

Mark Tinka mtinka at globaltransit.net
Sat Sep 10 06:11:19 UTC 2011


On Saturday, September 10, 2011 01:52:12 PM Dobbins, Roland 
wrote:

> All this problematic state should be broken up into
> smaller instantiations and distributed as close to the
> access edge (RAN, wireline, etc.) as possible in order
> to a) reduce the amount of state concentrated in a
> single device and b) to minimize the impact footprint
> when aberrant traffic inevitably fills up the state
> tables and said devices choke.

Certainly a consideration when an ISP considers scaling 
avenues for LSN's.

The issue is that there are simply too many variables, not 
least of which is what business the ISP is in.

The mobile types are a lot more problematic because they 
tend to centralize IP intelligence, and keep the RAN's 
pretty simple (although the RAN's are now becoming more 
intelligent thanks to your garden-variety IP vendors getting 
into the game). What we've seen also, with some mobile 
carriers, is that if you ask them to consider distributed IP 
architectures, they/you quickly realize that IP routing 
isn't really their core business or skill.

For your typical ISP, size notwithstanding, it will 
invariably come down to how much money and effort they're 
willing to spend or save with either centralized or 
distributed architectures. Mind you, they're also battling 
with other problems re: centralized or distributed 
solutions, e.g., broadband aggregation, the ratio of 
access:aggregation intelligence, access topology lay-outs, 
e.t.c. And somehow, in all this mix, LSN's must work, be 
they small units thrown around the network, or one or two 
large monsters sitting somewhere in the core.

We've certainly considered both options very thoroughly.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110910/9a5a30e3/attachment.sig>


More information about the NANOG mailing list