[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Happiness; lack thereof



After a hiatus in reviewing drafts/proposals, I've been reading the LISP-APT draft.

I am not happy. Have we learned so little in the past years?

In a system where a fraction of all traffic requires more processing (i.e., the first packet in a session triggers setting up flow state, or in this case, initial packets for which there is no mapping are forwarded over a third infrastructure (the PA/core infrastructure being 1 and the ITR/ETR infrastructure 2)), then there will invariably arise a situation where the fraction of special case traffic is larger than what can be handled. If not for mundane reasons such as network use growing faster than hardware capabilities, then because of denial- of-service attacks. I had the pleasure of managing a router with a route cache when the slammer worm hit. It was dead in the water. An almost identical router that didn't use a cache was able to keep forwarding packets. This is a lesson we can't ignore.

Bringing all information to a central place doesn't scale. The number of entities at the top of the hierarchy must be limited in some way or another. In the case of NERD or APT this is almost trivially easy to accomplish by not using a monolithic database that holds all information for the entire internet, but by having an arbitrary number of sub-databases that each hold information about a distinct part of the address space, so mapping requests can be forwarded to the appropriate database and the databases can be updated in parallel without interdependency. Parallel is cheap and scalable, if it's easy to make your processing parallel, doing so is a no-brainer.

Implicit mapping requests should be considered harmful. Don't hide relevant information. The correlation between the need to send packets over the third infrastructure and lack of mapping state is not equal to 1, so treating the result of one as the other is a bad idea. ITRs know when they need to send mapping requests, so they should do so explicitly. This way, the mapping database doesn't have to do unnecessary work and a modicum of data and control plane separation is maintained.

Depending on return packets to indicate problems, such as the address for an ETR becoming unreachable, an ETR becoming unreachable or a destination "behind" and ETR becoming unreachable is way too dangerous. Path MTU discovery does this and it works quite poorly in practice. At a minimum, unreachables will be rate limited. They may also fail to be generated, be filtered or spoofed.

These are general comments, please apply them to proposals/solutions where the shoe fits.

On a more positive note: the mapping distribution in APT looks promising, it's just the more mundane nuts and bolts that are problematic.

--
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