Reply inline
-----Original Message-----
From: owner-rrg@psg.com 代理 William Herrin
Sent: 3/6/2008 (木) 6:02 午後
To: Paul Francis
Cc: rrg@psg.com; Hitesh Ballani; caotuan
Subject: Re: [RRG] a backwards compatible FIB scaling approach
On Thu, Mar 6, 2008 at 1:35 PM, Paul Francis <francis@cs.cornell.edu> wrote:
> We've written up a short informal description of the idea, posted at
> http://www.cs.cornell.edu/people/francis/va-wp.pdf.
Hi Paul,
Can you read the following and let me know if I've grasped your basic
idea? If not, what am I missing?
1. Make the MPLS label reflect the neighbor's entry router and
protocol instead of our egress router and protocol. This allows us to
drop the BGP table from our egress routers.
YES
2. Move the MPLS labelers to a handy location or set of locations away
from the entrance so that entry routers can drop the BGP table as
well. The entry routers then send packets towards the routes in the
IGP. The IGP default route will, of course, lead to a nearby labeler.
It will be BGP that delivers the packet to the labeler, but otherwise correct.
3. Parallelize the MPLS labelers and instead of announcing a default
route into the IGP, have each labeler announce the specific very short
CIDR blocks (generally /8 or shorter) for which they will encode
traffic. Every time you double the number of labelers, you halve both
the traffic to each labeler and halve the number of entries each
labeler carries in its FIB.
Sounds right.
4. The parallel labelers need not be at the same site. You could, for
example, place all of the labelers for the APNIC region /8's near your
Pacific link and place the labelers for the RIPE region /8's near your
Atlantic link. In most networks this will still produce something
close to the optimal route.
Maybe, but we haven't looked at this style of optimization. Our perf numbers are based simply on putting a couple labelers for each virtual prefix (i.e. /8) in each large POP.
5. This means you probably move the full RIB off the routers entirely
and on to cheap COTS systems (your "conduit routers" that don't
forward packets). The labelers then get feeds of only those portions
of the RIB for which they will apply labels.
The conduit routers are off-the-shelf route reflectors. My understanding is that in practice these tend to be router vendor products as well, but they don't need all the line cards and such.
Questions:
a. How do we generate labels for the neighbor's first hop instead of
our last hop? Can we do this now or would it take new software?
Everything in the paper can be done with existing product. You basically statically configure the neighbor's /32 into OSPF, carry that around with OSPF, and use LDP to establish the MPLS tunnels.
b. How does one of the labelers go about deciding that it is in good
enough working order with reasonable BGP and label feeds to offer an
aggregate route into the IGP? Without aggregation the function is
implicit, but once you add aggregation the traffic will head your way
whether you have a label to send it to or not.
Through configuration, route reflectors know which routers (labelers) do aggregation for which virtual prefixes (i.e. /8's). When the route reflector feeds the appropriate prefix to the labeler, it also feeds the next hop (the neighbor router /32). Because we fed the neighbor /32 addresses into OSPF, every router has an MPLS tunnel to every neighbor router.
PF
Regards,
Bill Herrin
--
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg