Re: [Idr] draft on virtual aggregation

Daniel Ginsburg <dg@ot-e.biz> Wed, 09 July 2008 15:08 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 96B383A68F0; Wed, 9 Jul 2008 08:08:59 -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 528AF3A68F0 for <idr@core3.amsl.com>; Wed, 9 Jul 2008 08:08:59 -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 w7hOzQh1iaD6 for <idr@core3.amsl.com>; Wed, 9 Jul 2008 08:08:58 -0700 (PDT)
Received: from iddater.nxceso.com (iddater.malpaso.ru [89.108.83.67]) by core3.amsl.com (Postfix) with ESMTP id 6C40D3A68DB for <idr@ietf.org>; Wed, 9 Jul 2008 08:08:58 -0700 (PDT)
Received: from station88.amt.ru ([212.233.69.88] 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 1KGbI3-0004Cu-Jl; Wed, 09 Jul 2008 19:09:07 +0400
Message-ID: <4874D48D.1090702@ot-e.biz>
Date: Wed, 09 Jul 2008 19:09:01 +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>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D829@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

Paul,

I made another pass through the draft and I have few more comments, if 
you don't mind.

Section 3.2.2.2:
 > The LOCAL_PREF attribute is optional.

A small nit. As per RFC4271, section 5.1.5, LOCAL_PREF is included in 
all iBGP updates, so it can't be optional.

 >    4.  If a packet is received at the APR whose best match is the VP
 >        (i.e. it matches the VP but not any sub-prefixes within the VP),
 >        then the packet MUST be discarded (see Section 3.2.2.1).

Some ASes relay on default route to route some traffic while carrying 
[almost] full BGP table. One of notable examples is so called 
"disconnected backbone" setup. If virtual aggregation is implemented as 
described, it would break default route forwarding.

Section 3.2.2.3:
 >    The router MUST advertise the VP to its iBGP peers.  The router MUST
 >    NOT advertise the VP to eBGP peers.  (This should go without saying,
 >    since the Extended Communities T bit is set to be non-transitive.)

T-bit will only prevent extcommunity from propagating to eBGP neighbors. 
The prefix itself still will be advertised. I think NO_EXPORT should be 
always attached to VP as a safety measure.

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.

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.

-- 
dg

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