[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: "Alia Atlas"
Date: Thu, 1 Mar 2007 12:08:57 -0800

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.


- 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.
>         Mike
> At 13:39 25/02/2007, Schnitter, Stefan wrote:
>> >Yes, you're right.  I was rereading quickly.  The question is more
>> between
>> >the type of alternate (LFA, not-via, etc) and the distance.
>> Not really. Imho the types you introduce (NONE, LFA and PRIMARY) are
>> also
>> considered before and won't break any ties here. Of course, things might
>> change
>> when you introduce new types like not-via (although my understanding was
>> that
>> the relation between different ipfrr implementations would better fit
>> into the
>> framework draft)
>> Stefan.
>> _______________________________________________
>> 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]

rtgwg mailing list
[email protected]
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Question regarding draft-ietf-rtgwg-ipfrr-spec-base-05, Alia Atlas <=