Thus spake "William Herrin" <bill@herrin.us>
On Mon, Mar 24, 2008 at 7:48 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:On 2008-03-23 09:50, William Herrin wrote: > 2a. What's the maximum acceptable time in which one EID may be > inaccessible to another because of a map change due to a path failure? That seems to assume that a failure will produce a map change. I expect a failure to produce a change in the routing tables, but why should a (temporary) failure produce any change in the map? I would expect this would cause the routing algorithm to be told about the failure and to find an alternative path involving the same or an alternative map entry.Hi Brian, I suppose that depends on how you split the duties between routing and mapping. With TRRP, path failures between the endpoint and a little ways upstream of the ETR will be handled by a map change (expressing which ETRs are currently able to natively reach the endpoint) while most path failures between the ITR and ETR will be handled by a BGP route change. In both cases, the question which matters is: how long does it take to detect the failure and restore service?
My understanding is that a temporary path failure would _not_ require a mapping change in a protocol that provided the complete set of potential EID-to-RLOC mappings to the ITR and featured reachability tests. That is, after all, one of the prime reasons to go with multiple mappings.
A mapping change is only required for protocols that provide only a single mapping at any given time (like Ivip, and which causes many other problems) or does not have the ITR test reachability of the ETRs.
Lets rephrase the question so that it's agnostic on the map/route issue: 2a. What's the maximum acceptable time in which one EID may be inaccessible to another during change propagation due to a path failure?
A second or two at most, ideally, because folks are going to try to run VoIP over this system. The good news is that it's not "zero" or "50ms" like it would have been a decade ago, as cell phones have conditioned people to expect occasional audio loss they wouldn't have accepted when accustomed to the general high reliability of the wireline PSTN.
S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws theK5SSS dice at every possible opportunity." --Stephen Hawking
-- 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