On Mon, Dec 22, 2008 at 3:23 PM, David Meyer <[email protected]> wrote: > OTOH, what would be helpful would be for you and/or Robin > to describe *the mechanism and how it works, in detail* > that you are proposing, then show how it solves the > simple example problem in Section 3 (Figure 1) for the > draft.
David, I'll speak to TRRP: >> Examples of such a heuristic include: >> >> 1. I think my Internet link is bunged up, so I press the "switch >> locators" button and that alters my map entry. My authoritative locator map is stored on several DNS servers, each sitting on BGP-advertised PA addresses. In the map, La has the top priority. Lb has second priority. When I press the "switch locators" button, the device performs a dynamic DNS update to each of those authoritative DNS servers, installing the map in which Lb has top priority. The device has a PA address from each of A and B, and it retries the dynamic update using each source until it succeeds. When the TTL on the map expires at C as much as a minute later, C re-queries the locator map from one of the DNS servers sitting on its BGP-advertised PA address and starts using Lb instead of La. >> 2. A monitoring system at my network border polls external public >> probe sites and watches for retransmission in the TCP sessions which >> pass by it. If the failure rate exceeds the programmed threshold, it >> decides my Internet link is bunged up and alters my map entry to favor >> a different locator. Same except the monitoring machine is the device in question and it presses the button for me. >> 3. A globe-spanning Akamai-like system of testpoints builds a complex >> map of Internet path states. Combined with some basic information >> about the state of my connections to my ISPs, it can compute what will >> usually be a good current locator selection for me. I subscribe to >> this service. Akamai detects that provider A has encountered a significant network bump. Testpoints at providers B and C can no longer reach testpoints at provider A. It verifies that I appear to still be adequately connected to provider B, as I claimed when I signed up. It performs a dynamic DNS update to each of my authoritative servers, changing Lb to top priority. Being clever, Akamai notices that I am still connected to provider A and provider A isn't completely dead. So, it leaves the one DNS server on provider A reporting that La has the top priority. Anyone who can still reach provider A to get to the DNS server I have there will still reach me at La. >> 2. A monitoring system at my network border polls external public > Really? You want to put the dependency that routers (or > something) must snoop the data plane for TCP state to > make connectivity work? Notwithstanding the wisdom of > introducing that dependency, what if traffic is > unidirectional (or otherwise asymmetric), UDP, or ... Then you use a heuristic device that is more appropriate to your particular network configuration. That's one point of pushing the function out into an external device: the solutions aren't one size fits all. > And what if its multiple 10GE fire hoses blasting data at > you? I'm not going to interact with 10ge flows. None of the Strategy-A systems are. I'm going to deploy my equipment shallow enough in the network to work with flows manageable on commodity PC hardware, which is currently sub-gige. The hundred gig-e flows are on the coreward side of the ITR. And if you look around at operations today, you'll find very few places where that's the slightest bit challenging and none where it can't be done at all. > But again, these high level descriptions of how something > that is largely unspecified (notably the "heuristic system > external to the protocol itself") doesn't help me > understand (i). what mechanism you are proposing, > (ii). what its properties are, and (iii). if it even > works. > > I guess I'm not understanding, primarily it seems since > you haven't given any detail about how this would > actually work. Start by reading http://bill.herrin.us/network/trrp.html . Don't just scan it. Read it. It's six pages long; it won't kill you. If there are any details for which you still don't have a solid mental picture, I'll be pleased to expand on them until you do. 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
