[email protected]
[Top] [All Lists]

Re: ops reqs on IP FRR

Subject: Re: ops reqs on IP FRR
From: Alia Atlas
Date: Fri, 11 Nov 2005 19:52:35 -0800
On 11/11/05, Pekka Savola <[email protected]> wrote:
> On Fri, 11 Nov 2005, Alia Atlas wrote:
> > >   3) the solution, when enabled, must not have a failure mode where the
> > > result would be blackholing or duplicating traffic for a noticeably
> > > longer period than non-IPFRR would ("optimizations must not make
> > > corner cases worse")
> ...
> > This brings up two questions.  First, can we ignore the extra delay to
> > collect all relevant advertisements?  This delay is important for
> > identifying broadcast link, SRLGs or node failures.  I think we've
> > tossed around delay times of 50ms or so.

If you figure network convergence might take 2-3 seconds, then we're
talking about the possibility of doubling it, b/c the DELAY_TYPEC
would be after that.  So, if could be
quite noticable.

> > Second, how much benefit do we get from type C routers delaying?  This
> > delay means that PLSN only fails to repair type C <-> type C loops.
> > Without that delay, any type C would introduce a potential micro-loop.
> > Of course, the number of type Cs is relatively small; perhaps Mike
> > has his simulation results to hand?
> >
> > Is it better to have a technique that keeps the current behavior for
> > all cases but is less effective?  How corner-case does a case have to
> > be before it isn't a concern?
> (As a bit of context, we're a traditional IP-only (v4/v6,
> uni/multicast) NREN without MPLS, VPNs, or TE -- and no desire to get
> any of that. The goals might or might not be different esp. for those
> which use TE but that seems to imply MPLS as well.)
> These are good questions, and I can't give a good answer because I
> haven't been able to study the specs in detail (and in any case
> different operators' MMV).  That's why I wrote "should" and
> "noticeably longer period". (e.g. over 10% increase for times above
> half a dozen seconds might qualify as "noticeable").
> The key point IMHO is that the vendors and operators could just turn
> this on without fear that it would have (too) bad effects.
> On the other hand, as you write, there may be a real cost associated
> with too much conservatism for corner cases.  One potential approach
> would be specifying non-default behaviour w/ config knob which the
> operators could toggle on after they've studied the potential
> tradeoffs, impact on their particular topology and accepted them.
This seems to argue for 2 things.  First, that if S doesn't have an
alternate, it should prefer to loop rather than drop (since this will
get the "same" behavior in most cases).  Second,
that by default, DELAY_TYPEC should be 0 - and then then knowledgable
operator could adjust it.  This would impact the effectiveness, but
give the original behavior (modulo the small % extra delay to collect


Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>