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