Re: [Idr] draft on virtual aggregation
Robert Raszuk <raszuk@juniper.net> Fri, 11 July 2008 13:34 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 46EC73A6B06; Fri, 11 Jul 2008 06:34:16 -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 393643A6B06 for <idr@core3.amsl.com>; Fri, 11 Jul 2008 06:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level:
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 ISPzlvB9k9uc for <idr@core3.amsl.com>; Fri, 11 Jul 2008 06:34:13 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id E06AE3A6AF9 for <idr@ietf.org>; Fri, 11 Jul 2008 06:33:58 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Fri, 11 Jul 2008 06:33:41 PDT
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:26 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:26 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jul 2008 06:32:25 -0700
Received: from [172.26.250.82] ([172.26.250.82]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6BDWNx36813; Fri, 11 Jul 2008 06:32:24 -0700 (PDT) (envelope-from raszuk@juniper.net)
Message-ID: <487760E5.3010702@juniper.net>
Date: Fri, 11 Jul 2008 06:32:21 -0700
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>
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> <37BC8961A005144C8F5B8E4AD226DE1109D867@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D867@EXCHANGE2.cs.cornell.edu>
X-OriginalArrivalTime: 11 Jul 2008 13:32:25.0630 (UTC) FILETIME=[8E6F9BE0:01C8E35A]
Cc: idr@ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
Paul, That's exactly the point I was making. IMHO the current draft could be the right place to accommodate this as this is just a subset of the VA overall idea. Cheers, R. PS. Also as said I agree to use Trabants on the back roads. Some people are really attached to them :))) > 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
- [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Curtis Villamizar
- Re: [Idr] draft on virtual aggregation Daniel Ginsburg
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Robert Raszuk
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- Re: [Idr] draft on virtual aggregation Paul Francis
- Re: [Idr] draft on virtual aggregation Rajiv Asati (rajiva)
- [Idr] Latest draft of FIB suppression Paul Francis