The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Jan> msg00252



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Example of large IP flatnet

  • From: manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)
  • Date: Mon, 29 Jan 1996 14:50:22 -0500
  • X-Vms-Cc: ipatm
  • X-Vms-To: SMTP%"rcoltun@fore.com"

> From:	rcoltun@fore.com    29-JAN-1996 14:04
> 
> Bert,
> 
> 	I'm a bit concerned about what we are architecting here.
> It is my understanding that many commercial
> bridges allow for up to 8K entries which seems like a more reasonable
> number but even at that I think the design is a poor one.
> 
> It is entirely possilbe to build a large network running IP routing
> protocols (OSPF, BGP, CBT, PIM) which function *only* as an IP/ATM overlay.
> For example, you could build a 10,000 host system and decompose it into
> 100 LISes each having 100 hosts. Between the LISes you are running NHRP
> so reachability would be equivalent to the 10,000 host flatnet.
> This would be much more manageable and would interoperate with
> a pure IP forwarded network. It would also give you the neat VLAN
> features of associating hosts administratively but not necessarily
> physically.
> 
> So, I don't see the need for building a NHRP distribution protocol
> to scale to 10,000 entries when we have well engineered IP
> routing protocols that will allow us to scale much larger than that -
> 10,000 is somewhat small if we are talking scalable...
> 
> 
> Comments?

Rob, I think it is a "given" that one could subdivide the IP net into 100 
LISs each with 100 hosts, especially if we then have RFC-1577-style 
routers between them. To me, this is not an interesting case. Put another 
way, if we rely on IP mechanisms to route traffic over large ATM clouds, 
what does that say about ATM? It says that by itself it's basically 
inadequate. And if we need IP routing to wade through the ATM cloud, 
pretty soon one wonders why bother with ATM.

What I was trying to show, though, is that the IP prefix is not necessary
for routing messages within an ATM framework. The IP prefix would be used 
for routing outside datagrams _to_ the ATM periphery, and then the prefix 
becomes just overhead. Unless we have no faith in the NNI, the IP prefix
is unnecessary within the ATM medium. What I find interesting is that ATM
_can_ provide, all by itself, the mechanisms for routing traffic over very 
large areas, so that to an IP user this would look like a gargantuan 
flatnet. Further, if we allow ourselves some routing inefficiencies (not 
loops, mind you, but the possibility of longer data paths than perfect 
routing might create), this IP-ATM net can also be interconnected with the
normal Internet.

My faith in the NNI, especially a public NNI, comes from the fact that the 
global telephone system works remarkably well with an enormous number of 
subscribers. Much greater than the number of Internet hosts, so far at 
least. Now, one could certainly protest here, pointing out that the 
telephone routing of today doesn't have to worry about multiple QoS levels 
and the like. Agreed, but then again IP routing doesn't either.

I understand your desire to stay with IP routing protocols we know work. 
But look at this as an academic exercise, if you will.

Bert
manfredi@engr05.comsys.rockwell.com