[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] draft on virtual aggregation
In message <37BC8961A005144C8F5B8E4AD226DE1109D823 at EXCHANGE2.cs.cornell.edu>
Paul Francis writes:
>
>
> Gang,
>
> At the following URL is a draft on virtual aggregation that I'm posting to
> IETF (it'll show up in a day or two), and which I'll present at IDR in
> Dublin.
>
> http://www.cs.cornell.edu/people/francis/draft-francis-idr-intra-va-00.txt
>
> Title and abstract are below. I hope to create a work item on this in IDR.
> I would characterize this as falling under the general charter of scaling
> BGP.
>
> Any comments and discussion on this prior to Dublin is of course greatly
> appreciated.
>
> PF
>
>
> Title: Intra-Domain Virtual Aggregation
>
>
> Virtual Aggregation (VA) is a technique for shrinking the DFZ FIB
> size in routers (both IPv4 and IPv6). This allows ISPs to extend the
> lifetime of existing routers, and allows router vendors to build FIBs
> with much less concern about the growth of the DFZ routing table. VA
> does not shrink the size of the RIB. VA may be deployed autonomously
> by an ISP (cooperation between ISPs is not required). While VA can
> be deployed without changes to existing routers, doing so requires
> significant new management tasks. This document describes changes to
> routers and BGP that greatly simplify the operation of VA.
>
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
Paul,
Is there a need?
Are we still trying to do the equivalent of keeping an AGFrom idr-bounces at ietf.org Wed Jul 9 08:01:08 2008
Return-Path: <idr-bounces at ietf.org>
X-Original-To: idr-archive at megatron.ietf.org
Delivered-To: ietfarch-idr-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9193328C17C;
Wed, 9 Jul 2008 08:01:08 -0700 (PDT)
X-Original-To: idr at core3.amsl.com
Delivered-To: idr at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0262C28C178
for <idr at core3.amsl.com>; Wed, 9 Jul 2008 08:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.161
X-Spam-Level:
X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,
IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1]
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 qJWTgTJt7H4G for <idr at core3.amsl.com>;
Wed, 9 Jul 2008 08:01:07 -0700 (PDT)
Received: from harbor.brookfield.occnc.com (unknown [69.37.59.172])
by core3.amsl.com (Postfix) with ESMTP id 7194C28C250
for <idr at ietf.org>; Wed, 9 Jul 2008 08:00:29 -0700 (PDT)
Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com
[69.37.59.172])
by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id
m69ExflG034874; Wed, 9 Jul 2008 10:59:41 -0400 (EDT)
(envelope-from curtis at harbor.brookfield.occnc.com)
Message-Id: <200807091459.m69ExflG034874 at harbor.brookfield.occnc.com>
To: Paul Francis <francis at cs.cornell.edu>
From: Curtis Villamizar <curtis at occnc.com>
In-reply-to: Your message of "Mon, 07 Jul 2008 12:52:53 EDT."
<37BC8961A005144C8F5B8E4AD226DE1109D823 at EXCHANGE2.cs.cornell.edu>
Date: Wed, 09 Jul 2008 10:59:41 -0400
Cc: idr at ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis at occnc.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr at ietf.org>
List-Help: <mailto:idr-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>,
<mailto:idr-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces at ietf.org
Errors-To: idr-bounces at ietf.org
In message <37BC8961A005144C8F5B8E4AD226DE1109D823 at EXCHANGE2.cs.cornell.edu>
Paul Francis writes:
>
>
> Gang,
>
> At the following URL is a draft on virtual aggregation that I'm posting to
> IETF (it'll show up in a day or two), and which I'll present at IDR in
> Dublin.
>
> http://www.cs.cornell.edu/people/francis/draft-francis-idr-intra-va-00.txt
>
> Title and abstract are below. I hope to create a work item on this in IDR.
> I would characterize this as falling under the general charter of scaling
> BGP.
>
> Any comments and discussion on this prior to Dublin is of course greatly
> appreciated.
>
> PF
>
>
> Title: Intra-Domain Virtual Aggregation
>
>
> Virtual Aggregation (VA) is a technique for shrinking the DFZ FIB
> size in routers (both IPv4 and IPv6). This allows ISPs to extend the
> lifetime of existing routers, and allows router vendors to build FIBs
> with much less concern about the growth of the DFZ routing table. VA
> does not shrink the size of the RIB. VA may be deployed autonomously
> by an ISP (cooperation between ISPs is not required). While VA can
> be deployed without changes to existing routers, doing so requires
> significant new management tasks. This document describes changes to
> routers and BGP that greatly simplify the operation of VA.
>
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
Paul,
Is there a need?
Are we still trying to do the equivalent of keeping an AGS+ with
S+ with
DFRT alive somewhere? RAM is cheap and dense. To get to on-chip
RAM would require orders of magnitude reductions in DFRT size.
Other techniques exist for dramatically reducing core router FIB
size if that becomes a goal for a provider.
For example, MPLS (or GRE) tunneling through a BGP free core reduces
FIB size to about the size of the IGP (should easily fit in on-chip
memory). It requires no protocol change. Only down side is no ICMP
when tunnel faults in middle prior to the ingress knowing about it
(usually the case anyway due to VPN and VRF) and no fallback to IP
when ingress knows that the tunnel is down and hasn't yet rerouted.
Is the solution worse than the problem?
This seems too operationally problematic.
Curtis
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr
DFRT alive somewhere? RAM is cheap and dense. To get to on-chip
RAM would require orders of magnitude reductions in DFRT size.
Other techniques exist for dramatically reducing core router FIB
size if that becomes a goal for a provider.
For example, MPLS (or GRE) tunneling through a BGP free core reduces
FIB size to about the size of the IGP (should easily fit in on-chip
memory). It requires no protocol change. Only down side is no ICMP
when tunnel faults in middle prior to the ingress knowing about it
(usually the case anyway due to VPN and VRF) and no fallback to IP
when ingress knows that the tunnel is down and hasn't yet rerouted.
Is the solution worse than the problem?
This seems too operationally problematic.
Curtis
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr