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