Re: [Idr] draft on virtual aggregation

Hi Paul,

>> True that some networks do not have the core ... the network can be
>> meshed edges or more specifically meshed POPs.
>>
>> A very simple observation can be made that you can use a tunnel from
>> the
>> edge to one router (per POP for example) do IP lookup then encapsulate
>> to the exit point. In that scenario your edge routers are free from
>> carrying full table and due to shift in the place where single IP
>> lookup
>> is done and switching decision determined.
> 
> This would overload that one router, as well as create a point of failure.
 > So you'd need to increase the capacity of that router, plus replicate
 > it for failure.

It needs to be noticed that this one router can be any of today's edge 
router as if current edge handles full Internet table in FIB. The gain 
is that all other edge routers do not any more keep state in FIB.

Reg single point of failure ... of course not. Two such routers (per POP 
or in small AS per network) would anycast common next hop and we would 
relay on IGP for failure detection and even for data packets in flight 
redirection.

> So in essence you are designing a core architecture.  The point
> behind VA is that you don't force ISPs to change their architecture and

Disagree 100%. VA is what I described + dividing the address space into 
chunks.

> upgrade their routers to deal with table growth.  Plus anyway you can't do
> this for your edge routers that peer with ISPs that require the full routing
> table, so this fix is quite limited.

Why not ? Remember we are dealing with FIB only. (My idea works with RIB 
as well using multihop ebgp session, but let's focus on FIB). Why ASBRs 
peering with ISPs would require to store all the routes in FIB ? 
Core/POP full nodes would attract all traffic make switching decision 
then encapsulate and ship. It is very much the same as Lixia's APT model 
except no mapping plane is needed :).

>> It is clearly not true that vendors today have any issues in delivering
>> boxes which could keep today's Internet table and at least allow for
>> 5-10 time it's grow. I know at least two of them which have been
>> shipping such routers for few years now.
> 
> Yes I understand that there are routers that can hold 5x or 10x the current
> table.  Your company makes them.  How long will these routers last, given the
> "end-game" of IPv4 address allocation?  5 years ago the new generation of
> routers looked like they could handle a lot of table growth, but now they
> have run out of space and yet ISPs want to keep them.

If one have bought an ISP class router 5 years ago there is no reason to 
upgrade now capacity wise. 5 years ago internet table were about 130K 
today is 270K src: http://www.cidr-report.org/

Those routers 5 years ago were already design and ready to handle 1-2M 
routes and not due to expectation of Internet growth ... due to 
requirement for L3VPN deployments.

> Basically you are
> telling them that the solution is simple---buy your latest product.  And to
> not worry about growth because you'll have yet another product for them a few
> years down the road.  This is exactly what this draft is trying to avoid.

If we compare Internet to Highways your draft still is trying to keep 
old Trabants going ... moreover bunch of them. It seems that they may be 
at some point became an obstacle on the road and it may be much better 
to find other uses for them then carrying passengers.

What I proposed is to keep all of those still running on the edge while 
based the

>> And such architecture does not require dividing address space in any
>> chunks and can be deployed today on any exiting hardware without
>> waiting
>> for any new protocol extensions.
> 
> I'm not sure what you mean by "such architecture".  But many existing routers
> in the field today cannot realistically use the kind of trick you mention
> above to manage FIB size.  Rather, they resort to simply dropping some
> fraction of routes, for instance.

What would be a single reason why at least pair of routers in any ISP 
could not carry full Internet table today in FIB ? I know quite a few 
ISP & SP networks worldwide and can't find any such example. Rest of the 
edge routers could function just fine without even slight need to drop 
anything.

My proposal is a special case of yours ... So saying that routers in the 
field can not support this means that your proposal suffers from the same.

The overall idea is good it is just I want to make sure that in whatever 
form this work goes forward ISP MUST be allowed to have single VA as well.

And that would not require any new protocol extension as BGP could 
inject such default route today with next hop being APR.

That means that the extended community attribute you are proposing 
should be optional as well.

> To be clear, we are talking about one new attribute, zero changes to the data
> plane, zero changes to the existing BGP decision process....just some rules
> for automatically setting up tunnels and new address aggregates (virtual
> prefixes).  Better to do this now well before the next generation of routers
> runs out of FIB.

My concern is not about adding new attribute. The concern is about the 
additional deployment, operational and troubleshooting difficulties it 
will introduce.

Having forwarding boxes partitioned with different information (which 
will have to be statically managed by hand) is very error prone. It also 
have other consequences including the need redesign on behavior of fast 
reroute technics or HA features. It is not the steady state of operation 
where things go out of control.

Cheers,
R.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr