[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] draft on virtual aggregation
I mis-typed...I meant, the issue is more in the edge than the core...
PF
> -----Original Message-----
> From: idr-bounces at ietf.org [mailto:idr-bounces at ietf.org] On Behalf Of
> Paul Francis
> Sent: Friday, July 11, 2008 6:40 AM
> To: raszuk at juniper.net
> Cc: idr at ietf.org
> Subject: Re: [Idr] draft on virtual aggregation
>
>
>
> > -----Original Message-----
> > From: Robert Raszuk [mailto:raszuk at juniper.net]
> > Sent: Friday, July 11, 2008 3:01 AM
> > To: Paul Francis
> > Cc: curtis at occnc.com; idr at ietf.org
> > Subject: Re: [Idr] draft on virtual aggregation
> >
> > Hi Paul,
> >
> > > In the meantime, however, FIB size alone is an immediate problem
> for
> > a
> > > lot of ISPs, because it is specifically this that forces them to
> > > upgrade hardware when they otherwise don't need to do it.
> >
> > As Curtis pointed out deployment of any form of tunneling in the core
> > MPLS or IP ultimately addresses the FIB scaling of that part of the
> > networks.
>
> Yes, but only that part of the network. As I said, from the ISPs I've
> talked
> to, the issue is more in the core than the edge.
>
> >
> > 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. 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
> 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.
>
> >
> > 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. 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.
>
> >
> > 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.
>
> 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.
>
> PF
>
>
> >
> > Cheers,
> > R.
> >
> >
> > > It is true that there are a number of routing problems that
> > ultimately need
> > > to be solved...RIB and FIB size, convergence time, security, multi-
> > homing.
> > > RRG is working on a single grand solution to all of this, but I'm
> not
> > holding
> > > my breath.
> > >
> > > In the meantime, however, FIB size alone is an immediate problem
> for
> > a lot of
> > > ISPs, because it is specifically this that forces them to upgrade
> > hardware
> > > when they otherwise don't need to do it. This is evidenced by the
> > various
> > > hacks that ISPs currently employ to extend the life of their
> routers.
> > One is
> > > the "disconnected backbone" arrangement that Dan Ginsburg mentioned
> > in his
> > > email. Another is to simply ignore /24's that you don't have
> enough
> > space
> > > for (see for instance
> > > http://mailman.apnic.net/mailing-
> > lists/pacnog/archive/2004/12/msg00000.html).
> > > I'm even familiar with a Tier1 ISP (I'm not at liberty to say who)
> > that is
> > > actually using a hack that messes up the AS-path, and could create
> > loops if
> > > another ISP did the same thing).
> > >
> > > So this is already a problem that needs fixing. Worse, as IPv4
> > addresses run
> > > out, there is real concern that addresses will become less
> > aggregatable, and
> > > I'd like to have something in place should that happen. VA
> > represents about
> > > the simplest architecturally sound solution I can imagine.
> > >
> > > I guess you are suggesting that, since RAM is "cheap and dense",
> FIB
> > really
> > > isn't the problem? I personally don't know router architecture
> very
> > well,
> > > but if what you say is true, why don't router vendors simply build
> > routers
> > > with more FIB? I suppose you could argue that they try to, but
> that
> > they
> > > under-estimate DFRT growth? This doesn't sound likely. Tony Li
> has
> > argued
> > > (see RFC4984) that because router memories are built in volume,
> > Moore's law
> > > doesn't really apply. This all suggests to me that there is a real
> > cost to
> > > huge FIBs.
> > >
> > > As for operational complexity, I don't think that you or I know if
> it
> > is
> > > "too" much or not. Really it is a question of the value ISPs get
> out
> > of this
> > > versus the difficulty of doing it. I'm not going to pretend that
> > running VA
> > > is trivial, but nor does it strike me as all that bad. It strikes
> me
> > for
> > > instance as simpler than route reflectors (though that ain't saying
> > much!).
> > > And given that ISPs already deal with config complexity in the
> hacks
> > I
> > > mention above, there is a good chance in my mind that VA will be an
> > > acceptable solution.
> > >
> > > Regarding some specific points in your email:
> > >
> > > Regarding core-router MPLS fix: To be clear, VA isn't about
> reducing
> > *core*
> > > router FIB size, it is about reducing FIB size in *any* routers,
> all
> > of them
> > > if that's what you want to do. Since most routers aren't core
> > routers,
> > > solutions that only address core routers are only so useful. I've
> > been told
> > > by folks at ISPs that the greater concern are edge routers.
> > >
> > > Regarding on-chip FIBs: I've been told by Tony Li that he believes
> > he can
> > > fit 200K FIB entries on-chip. VA can get you 5x reduction very
> > easily, and
> > > with some deployment creativity (which would take time and
> experience
> > to
> > > development) I'll be we could do much much better better. But that
> > is
> > > somewhat besides the point...the goal here is not to get to single-
> > chip
> > > routers (though that might be where this leads us anyway), but to
> > allow ISPs
> > > to extend the lifetime of their routers, which is something that at
> > least
> > > some of them clearly want to be able to do (see below).
> > >
> > > Thanks,
> > >
> > > PF
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: curtis at occnc.com [mailto:curtis at occnc.com]
> > >> Sent: Wednesday, July 09, 2008 11:00 AM
> > >> To: Paul Francis
> > >> Cc: idr at ietf.org
> > >> Subject: 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 AGS+ 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
> > >
>
> _______________________________________________
> Idr mailing list
> Idr at ietf.org
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr