Re: [Idr] draft on virtual aggregation

[Paul Francis <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, July 09, 2008 11:00 AM
> To: Paul Francis
> Cc: [e-mail]
> Subject: Re: [Idr] draft on virtual aggregation
> 
> 
> In message
> <[e-mail]>
> 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
> > [e-mail]
> > 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
[e-mail]
https://www.ietf.org/mailman/listinfo/idr