On Thu, Jan 1, 2009 at 2:43 PM, Brian E Carpenter <[email protected]> wrote: > On 2009-01-02 05:37, William Herrin wrote: >> I insist on me being able to >> satisfactorily explain how a particular approach would reduce the need >> or demand for core routing slots. > > Slide 15 in > http://www.cs.auckland.ac.nz/~brian/RRG0708.pdf
Thanks Brian. I follow how slide 15 achieves reliable multihoming given two constraints: 1. System contains client machines. If it contains servers, they are limited to those protocols which have a thoroughly defined layer-7 multihoming process, such as SMTP. 2. Loss of session during a multihoming event deemed acceptable. I accept the proposition that some significant fraction of the multihoming demand could be satisfied with a system meeting criteria #2. Given a satisfactorily low rate of multihoming events, a pizza joint is happy as long as the SIP phones immediately re-establish and the web users can get the page by hitting reload. I accept that slide 15 offers qualitatively different multihoming versus slide 16 in that slide 15 does not require hosts to deal with routing constructs with which they are not presently familiar. When fleshed out to provide a complete multihoming solution, slide 16 evolves into strategy B. Question: What's the cause to believe that systems meeting criteria #1 represent a more-than-negligible portion of the multihoming demand that is either unserved or served by BGP? You may choose to dispute criteria #1. Before you do, I remind you that the primary API for access to the DNS (gethostbyname) is irretrievably defective, at least as it pertains to providing an ephemeral GUID to LOC map. > So if you were product manager for a highly reliable > distributed application, I'm sure you would insist that it was > coded to detect permanent transport failures and try alternative > addresses. Like a web browser, let's say? Think HTTP handles this? Think again. Once the browser successfully connects to a particular IP address for a given server name, it nails itself to that address in order to avoid an otherwise unsolvable javascript+DNS hacking vector. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
