At 03:21 PM 4/24/00 -0400, J. Noel Chiappa wrote:
>A couple of routing points, not related to NAT:
>
> > From: Ian King <[EMAIL PROTECTED]>
>
> > so that it is realistic for businesses to regularly ask for assignments
> > in more granular chunks; rather than grabbing a class A-size space
> > "just in case", big users would be willing to request another 256 when
> > the new branch office opens, then another 64 for the summer interns...
>
>Sorry, this doesn't work - at least with IPvN (N=4,6) addresses as currently
>constituted. The routing system (i.e. the software that computes paths
>through the network) uses those addresses as the namespace it works on, and
>to make the routing scale properly (a.k.a. "keep the network running"), those
>addresses have to be aggregable.
>
>In other words, you need to be able to have a single routing table entry that
>covers a chunk of the network (such as a company's in-house network) - and
>that routing table entry can't include other things as well. If a company,
>etc, had addresses assigned in dribs and drabs, the way you suggest, that
>company's addresses would no longer have that property.
This is because the way things are right now that we are thinking this way.
But we can change it.
We can make it like this.
1) Apply for the number of address that u need. i.e. small chunk.
2) If u need more address later on give back the original chunk and apply
for the large chunk.
I know that the 2nd case will not make many people happy i.e. they will
have to expend little more effort but then with proper implementaion even
that will be null and i think the price is not much rather than wasting
address. And with this the current routing will work fine because u will
still have the network portion for the entire corporate same.
>
>Other namespaces, which don't have to include location information, just
>identification (e.g. IEEE 48-bit numbers) work just fine with this kind of
>allocation policy - but not any namespace used by path selection in a large
>network.
>
>
> > From: Steve Deering <[EMAIL PROTECTED]>
>
> > making each house a TLA does not strike me as a scalable multihoming
> > solution for very large numbers of houses, given the current state of
> > the routing art.
>
>The restriction has little to do with the current state of the routing art
>(which is not to say that better path-selection architectures than the one
>the Internet is currently using do not exist :-).
>
>Even with the best routing system, it still couldn't support tracking large
>numbers of houses as individual destinations (i.e. having individual routing
>tables extries across the global scope) - even if the routers had large
>enough route table memories to hold the 100's of millions of routes which
>could result.
>
> Noel
>
>
