On Thu, Feb 21, 2008 at 8:14 PM, Brian Dickson <[EMAIL PROTECTED]> wrote: > If you start adding DNS into the transport itself, even remotely (e.g. > at an ITR), it changes, > however subtly, the expected behavior of the transport, especially on > the first packet. > > And, it also presupposes that DNS servers/resolvers for root, TLDs > (especially arpa), and > reachable destinations, will be available 100% of the time. While > generally that is reasonable > to expect, it is not universally so. (There have been instances where > outages in some parts > of the Internet, left large swaths of regions without root servers > reachable, which was Very Bad.)
Hi Brian, You make a fair point. DNS becomes even more critical to the functioning of the network. Might it be desirable to permit each AS to secondary the key zones that would be available at the root and capture the requisite anycast server address internally? With TRRP, normal interior routing either has priority or exists as a fallback until you get out to the first BGP node. This means that local routing won't die because of an upstream failure. The AS operator would presumably be in the best position to know whether his network reliability and distance from the DNS root exceeds the cost of running a root and risk of falling out of sync. > I will suggest, however, that making small changes to common transport > protocols (TCP and UDP at least), > to make them suitably aware and compatible with the DNS stuff going on, > might allay the concerns. I can see adjusting the stack to ignore the round-trip times for the initial SYN/SYNACK/ACK packets for congestion control purposes. This doesn't strike me as a prerequisite but it might be desirable. GRE's use in TRRP is intended to be a stopgap to facilitate deployment. Down the line as we talk about the successor protocol to GRE, it might be desirable to adjust the host stack to handle things like path MTU discovery when the outer source address has been set to the same as the inner address. To my mind that's a discussion for later, though. I'd rather get it into the field using a tunnelling protocol that already exists and then, if it proves successful, contemplate more intrusive enhancements. What else do you have in mind? Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] 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
