Re: [Idr] draft on virtual aggregation

Paul Francis <> Thu, 17 July 2008 17:11 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id AAAA93A6B19; Thu, 17 Jul 2008 10:11:20 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EA3D3A6B19 for <>; Thu, 17 Jul 2008 10:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8XFVvojxfL-u for <>; Thu, 17 Jul 2008 10:11:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 43BF83A6B05 for <>; Thu, 17 Jul 2008 10:11:17 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id 8.0.813.0; Thu, 17 Jul 2008 13:11:47 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Jul 2008 13:11:47 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 17 Jul 2008 13:11:45 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmliJpGyBGN5MmTcif+A6CLzlIQwBk759Q
References: <> <>
From: Paul Francis <>
To: <>, <>
X-OriginalArrivalTime: 17 Jul 2008 17:11:47.0474 (UTC) FILETIME=[31FC1F20:01C8E830]
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Questions/comments inline:

> -----Original Message-----
> From: Robert Raszuk []
> Sent: Tuesday, July 15, 2008 12:14 PM
> To:
> Cc: Paul Francis;
> Subject: Re: [Idr] draft on virtual aggregation
> Hi Curtis,
> > Idr should not be adding a hack for small gain in FIB size when
> better
> > techniques exist and products already exist with quite a few binary
> > orders of magnitude headroom.
> This is not a hack. In fact all what this is about can be accomplished
> today by sitting down and configuring three routers: edge, lookup
> router
> and egress (an option). 

Are you saying here that no router modifications are needed to make this

> If someone really want to divide the addressing
> space as Paul suggest marking can be reg community. This is provider
> contained solution - it does not cross any inter-as boundaries.

I'm not sure what you mean by "marking can be reg community".  Can you expand
a bit?

> All this document attempts to is present such option for operators.
> Some
> may find them useful some may not.

I'm concerned that the folks that may find them useful (lower-tier ISPs)
aren't typically involved in IDR or IETF for that matter.  If there are folks
listening who can speak for lower-tier ISPs, please do so.  (My knowledge
here, such as it is, is all second- or third-hand.)

> Moreover there are other then edge FIB scaling real operational
> benefits
> for such solutions ... to name one I want to point at very fast
> reachability restoration in the event of failure.
> To meet customer's and today's applications requirements one can forget
> about hop by hop switching, sending withdraws network wide, re-
> propagate
> new best paths etc ... That is gone model.

For all of this fast restoration stuff, I gather you are thinking in terms of
the core-edge structure that most (all?) tier-1 ISPs have?  Is your point
that simply shrinking the number of routers that have to participate in
re-routing will help scale ASBR/PE failure detection, and that we don't need
explicit new mechanisms along these lines (i.e. BGP Virtual Link Attribute)?


> To meet such requirements requires to store backup paths for all
> destinations in FIB ahead of any failure + make sure that such router
> have very fast failure detection scheme. Every one could see that the
> less routers are configured with accelerated restoration features it
> scales much better ... or it allows for much faster OS upgrades on such
> boxes vs running around and upgrading all edge boxes.
> Imagine also vast reduction in number of BFD sessions if someone would
> choose to use this technology for ASBR/PE failure detection.
> Another one assuming that we would go one step fwd and remove RIB from
> the edge and just fully mesh those couple of IP lookup routers any
> problems with oscillations are history as well as vast reduction in
> intra-as triggered BGP instabilities.
> For the FIB reduction indeed small/mid size ISPs or enterprise networks
> may benefit.
> But for not directly mentioned in the draft benefits of moving to
> schemes which reduces the number of FIB lookup routers in the network
> many ISPs may be interested. And indeed I would like to hear their
> opinion on the list on that.
> Cheers,
> R.

Idr mailing list