-----Original Message-----
From: Robert Raszuk [mailto:raszuk at juniper.net]
Sent: Friday, July 11, 2008 7:29 AM
To: Paul Francis
Cc: curtis at occnc.com; idr at ietf.org
Subject: 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.