|On 2/26/07, Stewart Bryant <[email protected]> wrote:
Unlike the advanced schemes in which more more that one node
has to take special action with the packet, LFAs are a local
matter and the router can use any criteria it likes to
choose between the LFA alternatives. That makes the choice
one of implementation/configuration and not a protocol issue.
As such I prefer making no comment on the choice, since as
Mike suggests one size will not fit all.
However we should say that a downstream route is a better
choice than an LFA, since a DSR will not loop in the
presence of a node-failure, but an LFA pair may.
I agree with this. I've added the following text:
"If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and
D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h
is a downstream alternate and P_i.alt_next_hops is simply an
LFA. Prefer H_h and goto Step 19."
as Step 15.
Please let me know if there are any other changes desired. I'll be submitting the
slightly updated draft this week.
mike shand wrote:
> These are interesting questions concerning preference, and I'm not sure
> there is a "one size fits all "answer.
> Do you prefer a high metric LFA over a lower metric not-via? It all
> depends. If the metric were high because the link was very low
> bandwidth, this might be a very bad choice. On the other hand, the
> overhead of tunnelling the not-via may sometimes be just what you don't
> want if you can avoid it.
> Similarly you may want to choose between a single LFA neighbor which
> gives LFA protection for all destinations, but is sub-optimal in terms
> of metric for some of them, as against the extra FIB complexity and
> memory required for using multiple different LFA neighbors giving a more
> optimal path for some destinations.
> There are plenty of other such tradeoffs.
> Unfortunately this rather points to having lots of knobs to control
> these preferences. Something I would much rather avoid. One of the
> advantages of IPFRR in general is that configuration should be
> At 13:39 25/02/2007, Schnitter, Stefan wrote:
>> >Yes, you're right. I was rereading quickly. The question is more
>> >the type of alternate (LFA, not-via, etc) and the distance.
>> Not really. Imho the types you introduce (NONE, LFA and PRIMARY) are
>> considered before and won't break any ties here. Of course, things might
>> when you introduce new types like not-via (although my understanding was
>> the relation between different ipfrr implementations would better fit
>> into the
>> framework draft)
>> rtgwg mailing list
>> [email protected]
> rtgwg mailing list
> [email protected]
rtgwg mailing list
rtgwg mailing list