Re: [Idr] draft on virtual aggregation
Paul Francis <francis@cs.cornell.edu> Tue, 15 July 2008 16:15 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 00E6A28C237; Tue, 15 Jul 2008 09:15:24 -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 D66B228C21F for <idr@core3.amsl.com>; Tue, 15 Jul 2008 09:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.047
X-Spam-Level:
X-Spam-Status: No, score=-6.047 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
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 M3RP8oCUkSYV for <idr@core3.amsl.com>; Tue, 15 Jul 2008 09:15:21 -0700 (PDT)
Received: from exch-hub2.cs.cornell.edu (mail-hub-2.cs.cornell.edu [128.84.103.139]) by core3.amsl.com (Postfix) with ESMTP id B6F763A6ACF for <idr@ietf.org>; Tue, 15 Jul 2008 09:15:21 -0700 (PDT)
Received: from EXCHANGE1.cs.cornell.edu (128.84.96.42) by mail-hub.cs.cornell.edu (128.84.96.245) with Microsoft SMTP Server id 8.0.813.0; Tue, 15 Jul 2008 12:15:49 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jul 2008 12:15:48 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 15 Jul 2008 12:15:34 -0400
Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D8BC@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <487CC594.6050108@ot-e.biz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmkYj4cmOIPeg5R4CnJ47OQ6Jp3AAAhRsQ
References: <37BC8961A005144C8F5B8E4AD226DE1109D829@EXCHANGE2.cs.cornell.edu> <4874D48D.1090702@ot-e.biz> <37BC8961A005144C8F5B8E4AD226DE1109D854@EXCHANGE2.cs.cornell.edu> <487CC594.6050108@ot-e.biz>
From: Paul Francis <francis@cs.cornell.edu>
To: Daniel Ginsburg <dg@ot-e.biz>
X-OriginalArrivalTime: 15 Jul 2008 16:15:48.0802 (UTC) FILETIME=[0B3BF220:01C8E696]
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
inline > -----Original Message----- > From: Daniel Ginsburg [mailto:dg@ot-e.biz] > Sent: Tuesday, July 15, 2008 11:43 AM > To: Paul Francis > Cc: idr@ietf.org > Subject: Re: [Idr] draft on virtual aggregation > > 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. Ok. > > >> 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? Heh! Will have to think about this. But maybe in fact we don't need the extension. For instance, say an ISP wants to configure a new VP. It would first configure the APRs for that VP, which would start advertising the VP route (without the new attribute, but with NO_EXPORT). Subsequently, it could reconfigure the non-APRs (one by one) so that they now know that the VP is in fact a VP, and could start suppressing sub-prefixes...off-hand seems ok... PF > > > > PF > > > >> -- > >> dg > > > -- > dg _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- [Idr] Latest draft of FIB suppression Paul Francis