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

From: "Alia Atlas" <[email-masked]>
Date: Thu, 1 Mar 2007 12:08:57 -0800

On 2/26/07, Stewart Bryant <[email-masked]> 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.

Alia

- 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-masked]
> >> https://www1.ietf.org/mailman/listinfo/rtgwg
> >
> >
> > _______________________________________________
> > rtgwg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rtgwg
> >
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg