Re: [Idr] draft on virtual aggregation

Daniel Ginsburg <> Tue, 15 July 2008 15:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9A68E3A691C; Tue, 15 Jul 2008 08:43:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3B793A691C for <>; Tue, 15 Jul 2008 08:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.571
X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_RU=0.875, J_CHICKENPOX_52=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nWw9sd5TI2N3 for <>; Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AEC713A68CC for <>; Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1KImgV-0003Md-LZ; Tue, 15 Jul 2008 19:43:23 +0400
Message-ID: <>
Date: Tue, 15 Jul 2008 19:43:16 +0400
From: Daniel Ginsburg <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Paul Francis <>
References: <> <> <>
In-Reply-To: <>
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"

On 10.07.2008 16:44 Paul Francis wrote:

>> Section 4.2:
>> There're some possible externally visible traffic engineering issues.
>> AS
>> with VA deployed might choose different exit points as compared to AS
>> without VA.
>> These issues are similar to that of route reflectors deployments.
> I don't see why VA would choose a different exit point.  VA doesn't change
> the BGP decision process at all.  If a router selected a particular next-hop
> without VA, it would select the same next-hop with VA.  Perhaps what you mean
> is the following?
> Say you had the following topology:
> A--B--C--|--X
>    |
>    D-----|--Y
> where X and Y are external peers.  In the case without VA, A gets a packet,
> picks X as the exit, forwards the packet to B, which decides to pick Y as the
> next hop (can this happen?).  If this is VA, however, once A picks X, it
> tunnels the packet to X, so B can't divert it to a different exit.  If this
> case occurs, then you are right that VA can cause a change in exit...

Yes, it can happen. Assume the following link metrics:


Without VA, A would choose X as the exit point, D would choose Y. Now
with VA, D is APR. D still chooses Y, but A doesn't carry a specific
route and tunnels packets to D, and the packets now exit to Y.

>> Section 4.3:
>>  >    Likewise, routers can bootstrap VA by first bringing up the IGP,
>> then
>>  >    establish LSPs, then establish routes to all required sub-
>> prefixes,
>>  >    and then finally advertise VPs.
>> Hmm, wouldn't delayed VP advertisement require non-APR routers to
>> temporary install all the specific prefixes? If so, FIB overflow might
>> occur. Some platforms react badly to such cases (i.e. overloading CPU,
>> starving routing protocols and possibly crash), so it may destabilize
>> the network.
> Very nice catch!  I think the only good way to fix this is to require that
> all VA routers be statically configured with the complete set of VPs.  It is
> easy to conjure up scenarios where a router simply won't know all the VPs at
> the point in time at which it needs to start loading up its FIB.  If the
> router statically knows all the VPs, then it has a basis for deciding which
> FIB entries to suppress, and avoiding FIB overflow.

Hmm, now if both APRs and non-APR are statically configured with VPs, 
what's left to the proposed protocol extension?

> PF
>> --
>> dg


Idr mailing list