[email protected]
[Top] [All Lists]

Re: ops reqs on IP FRR

Subject: Re: ops reqs on IP FRR
From: Alia Atlas
Date: Mon, 14 Nov 2005 09:14:27 -0800
Mike,

I think that there is a difference between configuration and coverage
concerns.  IP FRR must be easy to turn on; I believe that this applies
to how many boxes need to be touched, how much configuration must be
detailed, how easy it will be to troubleshoot, etc.

As you know, I tend to view the coverage issue as more of a network
architecture problem.  While it would be lovely if a simple (to
configure, to understand, to troubleshoot, etc.) mechanism existed
that gave 100% coverage, at this point it seems clear that such does
not.  Not-via has a great deal of potential, but it is not likely to
be simple to configure, possibly to troubleshoot, etc.  Certainly, the
trade-offs required in terms of decideing for/against
computation/complexity vs. coverage will need to be understood,
configured, and managed.  It also, of course, imposes the requirement
for substantial more computation on ALL nodes in the network.  That's
unfortunate.

My view is that turning on IP FRR (certainly LFAs) without much
thought/configuration should do no harm - and do some good, but it
won't just give you everything without more thought.  Certainly, when
you say 100% coverage, you are making certain assumptions about the
network (like it remains at least 2-connected regardless of topology
changes) that are not certain to be true.

The safe fall back, as you know, I completely agree with.

Alia

On 11/14/05, mike shand <[email protected]> wrote:
> Pekka,
>          Thanks for this contribution. I strongly agree with all your
> points. This is pretty much the design principles we have been working to.
> At 16:10 11/11/2005, Pekka Savola wrote:
> >Hi,
> >
> >After watching the IP FRR discussion at rtgwg, I though I should try to
> >highlight a few operational perspectives:
> >
> >  1) the solution should not require any configuration of topology, backup
> > paths or in the topology; more specifically,
>
> Yes. In particular it should not be necessary to modify the topology so
> that the IPFFR works better (or works at all).
>
>
> >   1.a) the solution must not require configuration of any parts of
> > topology which are not adjacent to the router.
>
> By "configuration" I assume you mean something other than deploying the
> software and turning it on. Or are you saying that ONLY the routers
> adjacent to the protected link should need updated software. That is fairly
> restricting.
>
>
> >Discussion: topological/routing changes happen frequently.  Having to
> >reconfigure the otherwise-unaffected routers so that IPFRR doesn't get
> >messed up is a non-starter.
>
> Exactly. If the IPFRR coverage is topology dependant it is easy for a
> "good" topology to be degraded to a "bad" topology by one or more changes.
>
>
> >  2) the solution should "just work" without any config (apart from
> > toggling it on if need be)
>
> Yes.
>
>
> >  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")
>
> Yes. This is critical. "Do no harm". This why I have a problem with IPFRR
> solutions which have less than 100% coverage. IPFRR and loop prevention
> must go together. One without the other is not useful (for failure
> protection.... loop prevention on its own is useful for management invoked
> topology changes). ALL known loop prevention schemes delay convergence
> (some more than others). This is not intrinsically a problem, since the
> fast repair will be carrying the traffic for this time. However, that is
> only true if the repair is able to repair 100% of the traffic. For any
> fraction of the traffic which cannot be repaired, the delay introduced by
> the loop prevention mechanism will result in that traffic receiving worse
> service than for normal routing convergence.
>
> Multiple uncorrelated failures may be difficult of impossible to deal with.
> For those cases, the proposed action is to abandon the IPFRR/loop
> prevention and fall back to normal convergence. This can be actioned when
> multiple conflicting LSP/LSA s are received. This may take marginally
> longer than normal convergence, owing to propagation delays, but it is a
> small difference.
>
> This "fall back" seems an important safety property.
>
>          Mike
>
>
>
>
>
>
>
> >HTH in choosing a deployable and manageable solution,
> >
> >--
> >Pekka Savola                 "You each name yourselves king, yet the
> >Netcore Oy                    kingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >_______________________________________________
> >Rtgwg mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/rtgwg
>
> _______________________________________________
> Rtgwg mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rtgwg
>

_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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