Re: [Idr] draft on virtual aggregation

Paul Francis <francis@cs.cornell.edu> Fri, 11 July 2008 12:32 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 6D10D3A6B33; Fri, 11 Jul 2008 05:32:14 -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 4E94D3A6B33 for <idr@core3.amsl.com>; Fri, 11 Jul 2008 05:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.026
X-Spam-Level:
X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, J_CHICKENPOX_13=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 mzx+h1hFYSp3 for <idr@core3.amsl.com>; Fri, 11 Jul 2008 05:32:11 -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 AD1AF3A6B1C for <idr@ietf.org>; Fri, 11 Jul 2008 05:32:11 -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; Fri, 11 Jul 2008 08:32:28 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 08:32:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 11 Jul 2008 08:32:22 -0400
Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D867@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <48774411.4060808@juniper.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjjSwsJga23ITYoQPKIyOmZc19GlAAAeqBw
References: Your message of "Mon, 07 Jul 2008 12:52:53 EDT." <37BC8961A005144C8F5B8E4AD226DE1109D823@EXCHANGE2.cs.cornell.edu> <200807091459.m69ExflG034874@harbor.brookfield.occnc.com> <37BC8961A005144C8F5B8E4AD226DE1109D856@EXCHANGE2.cs.cornell.edu> <4877053B.2060403@juniper.net> <37BC8961A005144C8F5B8E4AD226DE1109D860@EXCHANGE2.cs.cornell.edu> <48774411.4060808@juniper.net>
From: Paul Francis <francis@cs.cornell.edu>
To: <raszuk@juniper.net>
X-OriginalArrivalTime: 11 Jul 2008 12:32:28.0160 (UTC) FILETIME=[2E2D4000:01C8E352]
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

I see...so I think you are saying:

o   let's allow for a special case of VA where there is a single virtual
prefix which is a /0 (the default route),

o   that this works perfectly well for ISPs who design their POPs such that
the default routes feed into routers that contain the full FIB (using
existing anycast-like failover techniques), 

o   that if you run it this way, then the question of what goes in the FIB is
simplified (i.e. anything or nothing for edge routers, everything for "full"
routers), and therefore you no longer have to tag the default route with an
attribute calling it a VP.

o   edge routers can still keep the full RIB in order to peer with external
peers, or we use the multi-hop BGP trick to get the "full" router to peer
with external peers (FAIW, we mention this in the tech report cited in the VA
draft)


If I'm getting you right, this seems very reasonable to me.  Do you think it
makes sense to modify the current draft to include this case, or to make it a
separate thing?  

To extend your highway analogy, I agree that you don't want Trabants on the
autobahn, but it is reasonable to continue to use them on back roads...

PF


> -----Original Message-----
> From: Robert Raszuk [mailto:raszuk@juniper.net]
> Sent: Friday, July 11, 2008 7:29 AM
> To: Paul Francis
> Cc: curtis@occnc.com; idr@ietf.org
> Subject: Re: [Idr] draft on virtual aggregation
> 
> Hi Paul,
> 
> >> True that some networks do not have the core ... the network can be
> >> meshed edges or more specifically meshed POPs.
> >>
> >> A very simple observation can be made that you can use a tunnel from
> >> the
> >> edge to one router (per POP for example) do IP lookup then
> encapsulate
> >> to the exit point. In that scenario your edge routers are free from
> >> carrying full table and due to shift in the place where single IP
> >> lookup
> >> is done and switching decision determined.
> >
> > This would overload that one router, as well as create a point of
> failure.
>  > So you'd need to increase the capacity of that router, plus
> replicate
>  > it for failure.
> 
> It needs to be noticed that this one router can be any of today's edge
> router as if current edge handles full Internet table in FIB. The gain
> is that all other edge routers do not any more keep state in FIB.
> 
> Reg single point of failure ... of course not. Two such routers (per
> POP
> or in small AS per network) would anycast common next hop and we would
> relay on IGP for failure detection and even for data packets in flight
> redirection.
> 
> > So in essence you are designing a core architecture.  The point
> > behind VA is that you don't force ISPs to change their architecture
> and
> 
> Disagree 100%. VA is what I described + dividing the address space into
> chunks.
> 
> > upgrade their routers to deal with table growth.  Plus anyway you
> can't do
> > this for your edge routers that peer with ISPs that require the full
> routing
> > table, so this fix is quite limited.
> 
> Why not ? Remember we are dealing with FIB only. (My idea works with
> RIB
> as well using multihop ebgp session, but let's focus on FIB). Why ASBRs
> peering with ISPs would require to store all the routes in FIB ?
> Core/POP full nodes would attract all traffic make switching decision
> then encapsulate and ship. It is very much the same as Lixia's APT
> model
> except no mapping plane is needed :).
> 
> >> It is clearly not true that vendors today have any issues in
> delivering
> >> boxes which could keep today's Internet table and at least allow for
> >> 5-10 time it's grow. I know at least two of them which have been
> >> shipping such routers for few years now.
> >
> > Yes I understand that there are routers that can hold 5x or 10x the
> current
> > table.  Your company makes them.  How long will these routers last,
> given the
> > "end-game" of IPv4 address allocation?  5 years ago the new
> generation of
> > routers looked like they could handle a lot of table growth, but now
> they
> > have run out of space and yet ISPs want to keep them.
> 
> If one have bought an ISP class router 5 years ago there is no reason
> to
> upgrade now capacity wise. 5 years ago internet table were about 130K
> today is 270K src: http://www.cidr-report.org/
> 
> Those routers 5 years ago were already design and ready to handle 1-2M
> routes and not due to expectation of Internet growth ... due to
> requirement for L3VPN deployments.
> 
> > Basically you are
> > telling them that the solution is simple---buy your latest product.
> And to
> > not worry about growth because you'll have yet another product for
> them a few
> > years down the road.  This is exactly what this draft is trying to
> avoid.
> 
> If we compare Internet to Highways your draft still is trying to keep
> old Trabants going ... moreover bunch of them. It seems that they may
> be
> at some point became an obstacle on the road and it may be much better
> to find other uses for them then carrying passengers.
> 
> What I proposed is to keep all of those still running on the edge while
> based the
> 
> 
> >> And such architecture does not require dividing address space in any
> >> chunks and can be deployed today on any exiting hardware without
> >> waiting
> >> for any new protocol extensions.
> >
> > I'm not sure what you mean by "such architecture".  But many existing
> routers
> > in the field today cannot realistically use the kind of trick you
> mention
> > above to manage FIB size.  Rather, they resort to simply dropping
> some
> > fraction of routes, for instance.
> 
> What would be a single reason why at least pair of routers in any ISP
> could not carry full Internet table today in FIB ? I know quite a few
> ISP & SP networks worldwide and can't find any such example. Rest of
> the
> edge routers could function just fine without even slight need to drop
> anything.
> 
> My proposal is a special case of yours ... So saying that routers in
> the
> field can not support this means that your proposal suffers from the
> same.
> 
> The overall idea is good it is just I want to make sure that in
> whatever
> form this work goes forward ISP MUST be allowed to have single VA as
> well.
> 
> And that would not require any new protocol extension as BGP could
> inject such default route today with next hop being APR.
> 
> That means that the extended community attribute you are proposing
> should be optional as well.
> 
> > To be clear, we are talking about one new attribute, zero changes to
> the data
> > plane, zero changes to the existing BGP decision process....just some
> rules
> > for automatically setting up tunnels and new address aggregates
> (virtual
> > prefixes).  Better to do this now well before the next generation of
> routers
> > runs out of FIB.
> 
> My concern is not about adding new attribute. The concern is about the
> additional deployment, operational and troubleshooting difficulties it
> will introduce.
> 
> Having forwarding boxes partitioned with different information (which
> will have to be statically managed by hand) is very error prone. It
> also
> have other consequences including the need redesign on behavior of fast
> reroute technics or HA features. It is not the steady state of
> operation
> where things go out of control.
> 
> Cheers,
> R.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr