Re: [Idr] draft on virtual aggregation

Daniel Ginsburg <dg@ot-e.biz> Tue, 15 July 2008 15:43 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A68E3A691C; Tue, 15 Jul 2008 08:43:02 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B793A691C for <idr@core3.amsl.com>; Tue, 15 Jul 2008 08:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.571
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWw9sd5TI2N3 for <idr@core3.amsl.com>; Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from iddater.nxceso.com (iddater.malpaso.ru [89.108.83.67]) by core3.amsl.com (Postfix) with ESMTP id AEC713A68CC for <idr@ietf.org>; Tue, 15 Jul 2008 08:42:59 -0700 (PDT)
Received: from station84.amt.ru ([212.233.69.84] helo=[10.0.37.74]) by iddater.nxceso.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <dg@ot-e.biz>) id 1KImgV-0003Md-LZ; Tue, 15 Jul 2008 19:43:23 +0400
Message-ID: <487CC594.6050108@ot-e.biz>
Date: Tue, 15 Jul 2008 19:43:16 +0400
From: Daniel Ginsburg <dg@ot-e.biz>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>
References: <37BC8961A005144C8F5B8E4AD226DE1109D829@EXCHANGE2.cs.cornell.edu> <4874D48D.1090702@ot-e.biz> <37BC8961A005144C8F5B8E4AD226DE1109D854@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D854@EXCHANGE2.cs.cornell.edu>
Cc: idr@ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

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:

      1
A--B---C--|--X
    |
    |10
    |
    D------|--Y

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


-- 
dg

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