[RRG] Happiness; lack thereof

[Iljitsch van Beijnum <iljitsch@muada.com>]

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