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

Re: [RRG] Re: map change due to a path failure?



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