Re: [RRG] How to Incrementally Deploy APT

["William Herrin" <bill@herrin.us>]

On Fri, Feb 22, 2008 at 3:33 PM, Michael Meisel <meisel@cs.ucla.edu> wrote:
>  > How do I go about deploying exactly one APT network into an existing
>  > BGP AS? What new equipment do I install?
>
>  You would need to make some modification to all border routers so that
>  they can do encap/decap and store a cache for mapping information. We
>  are hoping this can be a software-only upgrade for most hardware.

Hi Michael,

Hmm. This is potentially a problem. In routers you have the "fast
path" and the "slow path."

The fast path is a hardware path through tailored ASICs. It can
generally only do trivial, well defined functions that the hardware
was specifically built for: decrement the ttl. Move to this interface
queue. That sort of thing. It does these tasks really really fast, all
the way from receiving the packet on one interface to transmitting it
on the next without the benefit of a CPU.

The slow path runs through the router's CPU. You can permute the
packet any way you want here but the capacity is much much less,
perhaps 1% of the router's normal capacity.

I know routers have been built that can handle things like GRE tunnels
and MPLS labeling in the fast path but I'm not sure how that stacks up
versus typical deployed hardware or to what extent those hardware
assists are software-reprogrammable to support some other encoding
scheme.


Is the encoder pulling data from the mapping cache? If yes and you
want it to live in the fast path then the map cache will have to go in
the TCAM. Depending on how large the map cache is (compared to the BGP
routes you've withdrawn) that could be a really bad thing. The FIB
size problem *is* a TCAM size problem.


If it's not possible to shoehorn APT into the fast path of existing
routers then because this change has to be made to every one of the
AS's border routers it could cost hundreds of thousands of dollars to
deploy for a modest size ISP.

Randy Bush keeps making this criticism wrt IPv6. If critical
functionality that was in the fast path the old way isn't in the fast
path the new way, deployment requires a forklift upgrade to devices
where it is in the fast path.

I think if I was in your shoes, I'd lavish some attention on exactly
which router models can be field-reprogrammed to do apt encoding not
just at a basic level but in the fast path.


>  > What does it feed into my routing table? What do
>  > I remove from my routing table? If you need to make assumptions about
>  > the architecture of my existing BGP AS in order to give a concrete
>  > answer, please do so.
>
>  Since APT is a map & encap system, you won't have any additions to your
>  routing table, but the default mapper(s) store the full *mapping* table,
>  and the border routers store a small cache of recently used mappings.

Okay, so my border router receives a packet from a non-APT neighbor.
It's a bare IP packet. I look up the destination in the TCAM FIB and I
get no routes. So, I send it to the APT encoder.

The APT encoder looks it up in the TCAM map cache and finds no map.
So, it bounces the packet to the slow path.

In the slow path, the router queries the default mapper for a prefix
and ETR map. The query comes back. The router encapsulates the packet
with an APT header for that ETR and sends it on. It also installs that
prefix and ETR in the TCAM map cache so that the next packet for that
destination stays in the fast path.

Do I understand correctly? If not, would you correct my understanding?

If yes then this system suffers from some of the performance issues
attributed to Cisco fast switching. The most serious of these is that
you overwhelm the router slow path whenever a worm on grandma's DSL
link starts spraying queries to random destinations that transit your
network without stopping there. Systems which place the encoder out of
line with the transit path don't suffer as much from this problem; she
still overwhelms the encoder but it doesn't take down the transit path
with it.


>  > A-(B-C-D)-E-F
>  > Now A wants to talk to C. You've stated that BGP in the island does
>  > not contain prefixes in the island's mapping table. How does A get C's
>  > prefixes?
>
>  Since we are intending to separate A from the routing space of the APT
>  island, A CANNOT address any host in C. This is meant to be a feature.
>  End users should not need to talk directly to nodes in the infrastructure.

Eh? But C is an entire APT network that was formerly a BGP AS. It
contains pron servers that I want to surf! How do I surf them from A?

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