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

Re: [RRG] Happiness; lack thereof



Iljitsch van Beijnum wrote:
On 7 mrt 2008, at 0:30, Michael Meisel wrote:

Iljitsch van Beijnum wrote:
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.
This is worth exploring, but, in APT at least, there is no time that an ITR requests a mapping from a default mapper without also requesting a packet to be forwarded on its behalf. So it seems unnecessary.
Hm, what about the case where a host sends packet p1 to destination d, 
and the local ITR doesn't have mapping for d so it sends the packet down 
the third infrastructure and waits for a mapping reply.
I think you may have misunderstood something fundamental to our design. 
There is no third infrastructure. Each transit AS that deploys APT 
deploys their own default mapper(s). Default mappers store the full 
mapping table, so even on the case of an ITR cache miss, no third party 
is involved in data forwarding.
But before that mapping reply comes back, the host sends packet p2 also to d. The mapping server now gets packet p1 which requires a mapping reply, but it also gets packet p2, which doesn't really need to generate a mapping reply because the mapping reply to p1 will get there before the mapping reply for p2 anyway.
We have a deaf timer in default mappers to prevent a burst of traffic 
from generating a burst of mapping replies. It still forwards the 
packets, but the mapping replies get rate limited. We do this at the 
default mapper to (1) keep the ITRs as simple as possible, and (2) make 
sure misconfigured ITRs can't bog down the default mapper.
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.
Though APT relies on return packets to indicate problems, I think we've addressed a number of these issues. First of all, we use normal IP packets for this purpose, so filtering is unlikely. The destination address for such packets comes from the mapping database, and the sender cryptographically signs these packets. The info that went into the mapping database was also cryptographically verified. So spoofing should be very difficult. Since it's part of the APT protocol, I don't see why these packets are any less likely to be generated than a BGP withdrawal today.
Well, we can have a discussion on the practical issues, which can of 
course be addressed one by one to varying degrees of satisfaction. But 
in my opinion, it's architecturally undesirable to depend on the 
behavior of a third party system for the communication to work. (I mean 
third party as in managed by a third party, obviously routers and DNS 
servers are generally required in addition to the end hosts.) When 
problems arise, you don't have much recourse. If the source is able to 
detect failures on its own, this is fundamentally more robust.
There's no third party -- the party that sends the failure notification 
is the transit AS containing the ETR. They are the transit provider for 
the destination, and therefore have an incentive to make sure their 
customers' traffic gets rerouted in the case of a failure.
At the risk of re-stating the obvious: fundamentally, we are just 
replacing the mechanism by which transit networks learn about 
connectivity changes to edge networks. That is, today, all edge network 
connectivity info is propagated via BGP. APT (like any Map & Encap 
scheme) takes edge networks out of the transit networks' BGP tables. But 
they still need to know about connectivity changes so they can pick a 
working ETR. But we don't want to propagate everything like BGP -- we 
would put back most of the control traffic we are trying to remove.
-Michael

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