[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Happiness; lack thereof
- To: Routing Research Group <rrg@psg.com>
- Subject: [RRG] Happiness; lack thereof
- From: Iljitsch van Beijnum <iljitsch@muada.com>
- Date: Fri, 7 Mar 2008 00:03:08 +0100
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