William Herrin wrote:
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.
Yes, very true. As academics, we aren't exactly experts on the real-world hardware. =) We definitely see this as a necessary step at some point soon, but we don't believe that a narrow interpretation of current hardware capabilities should limit our exploration for the best design. It's much better to tweak a good design to work on the hardware than to miss a better design by focusing too much on hardware limitations.
I will say one thing that is encouraging for a fast mapping implementation in practice: our initial simulation results show that caches can realistically be quite small. So far, we've seen that a PE router at a reasonably sized POP would have a cache miss rate well under 1% with a 4096-entry cache, and a single default mapper could support hundreds of such TRs. We'll be sharing more details about our simulations soon.
> 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?
There is one important thing you're missing here -- the router doesn't need to *wait* for a response from the default mapper, the default mapper will forward the packet. It does still get a reply, though, and adds the entry to its cache once it receives it. So, in the mean time, the router can continue to deal with other traffic. I'm not sure if this makes any difference to the issue you're describing, though.
> 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?
Yes, but C is a transit network, by which we mean it's part of the infrastructure, think Level3 or Sprint. There aren't any pr0n servers for you in there (that we know of). If their customers have servers, then those customers need to have their prefixes in the mapping table.
-Michael and Dan -- 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