[email protected]
[Top] [All Lists]

Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05

Subject: Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05
From: Stewart Bryant
Date: Mon, 26 Feb 2007 10:11:23 +0000
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.

- Stewart

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

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
[email protected]

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