Re: [Idr] draft on virtual aggregation

Paul Francis <francis@cs.cornell.edu> Thu, 17 July 2008 17:11 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 AAAA93A6B19; Thu, 17 Jul 2008 10:11:20 -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 4EA3D3A6B19 for <idr@core3.amsl.com>; Thu, 17 Jul 2008 10:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XFVvojxfL-u for <idr@core3.amsl.com>; Thu, 17 Jul 2008 10:11:17 -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 43BF83A6B05 for <idr@ietf.org>; Thu, 17 Jul 2008 10:11:17 -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; Thu, 17 Jul 2008 13:11:47 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu 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: <37BC8961A005144C8F5B8E4AD226DE1109D916@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <487CCCCB.6060201@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjmliJpGyBGN5MmTcif+A6CLzlIQwBk759Q
References: <200807151426.m6FEQ2gC032246@harbor.brookfield.occnc.com> <487CCCCB.6060201@juniper.net>
From: Paul Francis <francis@cs.cornell.edu>
To: <raszuk@juniper.net>, <curtis@occnc.com>
X-OriginalArrivalTime: 17 Jul 2008 17:11:47.0474 (UTC) FILETIME=[31FC1F20:01C8E830]
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

Questions/comments inline:

> -----Original Message-----
> From: Robert Raszuk [mailto:raszuk@juniper.net]
> Sent: Tuesday, July 15, 2008 12:14 PM
> To: curtis@occnc.com
> Cc: Paul Francis; idr@ietf.org
> 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
work?

> 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)?

PF


> 
> 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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr