Re: [Idr] draft on virtual aggregation

[Paul Francis <[e-mail]>]

I mis-typed...I meant, the issue is more in the edge than the core...

PF


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Paul Francis
> Sent: Friday, July 11, 2008 6:40 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Idr] draft on virtual aggregation
> 
> 
> 
> > -----Original Message-----
> > From: Robert Raszuk [mailto:[e-mail]]
> > Sent: Friday, July 11, 2008 3:01 AM
> > To: Paul Francis
> > Cc: [e-mail]; [e-mail]
> > 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: [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
> > >
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr