Re: [Idr] draft on virtual aggregation

Robert Raszuk <> Fri, 11 July 2008 13:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 46EC73A6B06; Fri, 11 Jul 2008 06:34:16 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 393643A6B06 for <>; Fri, 11 Jul 2008 06:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ISPzlvB9k9uc for <>; Fri, 11 Jul 2008 06:34:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E06AE3A6AF9 for <>; Fri, 11 Jul 2008 06:33:58 -0700 (PDT)
Received: from source ([]) by ([]) with SMTP; Fri, 11 Jul 2008 06:33:41 PDT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:26 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:26 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:25 -0700
Received: from [] ([]) by (8.11.3/8.11.3) with ESMTP id m6BDWNx36813; Fri, 11 Jul 2008 06:32:24 -0700 (PDT) (envelope-from
Message-ID: <>
Date: Fri, 11 Jul 2008 06:32:21 -0700
From: Robert Raszuk <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Paul Francis <>
References: Your message of "Mon, 07 Jul 2008 12:52:53 EDT." <> <> <> <> <> <> <>
In-Reply-To: <>
X-OriginalArrivalTime: 11 Jul 2008 13:32:25.0630 (UTC) FILETIME=[8E6F9BE0:01C8E35A]
Subject: Re: [Idr] draft on virtual aggregation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"


That's exactly the point I was making. IMHO the current draft could be 
the right place to accommodate this as this is just a subset of the VA 
overall idea.


PS. Also as said I agree to use Trabants on the back roads. Some people 
are really attached to them :)))

> I I think you are saying:
> o   let's allow for a special case of VA where there is a single virtual
> prefix which is a /0 (the default route),
> o   that this works perfectly well for ISPs who design their POPs such that
> the default routes feed into routers that contain the full FIB (using
> existing anycast-like failover techniques), 
> o   that if you run it this way, then the question of what goes in the FIB is
> simplified (i.e. anything or nothing for edge routers, everything for "full"
> routers), and therefore you no longer have to tag the default route with an
> attribute calling it a VP.
> o   edge routers can still keep the full RIB in order to peer with external
> peers, or we use the multi-hop BGP trick to get the "full" router to peer
> with external peers (FAIW, we mention this in the tech report cited in the VA
> draft)
> If I'm getting you right, this seems very reasonable to me.  Do you think it
> makes sense to modify the current draft to include this case, or to make it a
> separate thing?  
> To extend your highway analogy, I agree that you don't want Trabants on the
> autobahn, but it is reasonable to continue to use them on back roads...
> PF
>> -----Original Message-----
>> From: Robert Raszuk []
>> Sent: Friday, July 11, 2008 7:29 AM
>> To: Paul Francis
>> Cc:;
>> 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:
>> 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