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

From: "Schnitter, Stefan" <[email-masked]>
Date: Fri, 23 Feb 2007 15:41:38 +0100

Hi all,

[I assume  draft-ietf-rtgwg-ipfrr-spec-base-05 - though recently expired
- is still state of discussion regarding lfa - otherwise you can ignore
the following... ]

I was looking into ipfrr opportunities for Deutsche Telekom's internet
backbone and implemented the algorithm to calculate LFA's that is given
in section 3.6 of draft-ietf-rtgwg-ipfrr-spec-base-05 (mainly to
research the different types of coverage)
I was wondering why the distance towards the destination is not stated
more clearly as a criterion to choose the LFA if there are multiple
(e.g. node protecting) candidates available. In Step 15 (page 16) it
says

 "15.  Based upon the alternate types, the alternate distances, IP
       addresses, or other tie-breakers, decide if H_h is preferred to
       P_i.alt_next_hops.  If so, goto Step 18."

Having the shortest path towards the destination - also in an ipfrr
situation - can be beneficial (within the simulation I found numerous
case where long detours occur when the distance would not be considered)
but also the distance is a tie-breaker that is easy to evaluate.
Otherwise simulations of ipfrr might more difficult (in case of DT's
backbone the distance would almost always be sufficient to choose a
unique LFA)

So - wouldn't it be good to add an "If-condition" between 14. and 15.
that explicitly chooses the candidate with minimum distance (and not
leave this to the vendors decision)?

TIA,
 Stefan

--
Dr. Stefan Schnitter
T-Systems Enterprise Services GmbH, Systems Integration, Telco Projects
& Design
Line Of Business Networks and Processes, Team Traffic Management and
Network Optimization
Phone: +49 (0) 6151 937-8521

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

---

From: "Alia Atlas" <[email-masked]>
Date: Fri, 23 Feb 2007 09:25:27 -0800

Hi,

> - is still state of discussion regarding lfa - otherwise you can ignore

Yes, I have a slightly updated version that I'm planning on getting out
soon.

> leave this to the vendors decision)?

Would you prefer a shorter path over one that provides node protection?
That's one of the details hidden in the "depending on alternate type".

If there is consensus on what the decision-making should be, I'm certainly
willing to modify the draft.

Alia

TIA,

---

From: "Schnitter, Stefan" <[email-masked]>
Date: Sat, 24 Feb 2007 16:46:10 +0100

Hi,		

>That's one of the details hidden in the "depending on alternate type". 
	
Probably not - I'd prefer the node protection. But my understanding of
the
procedure was that this is decided already in step 11:

"11.  If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE,
      goto Paragraph 18. "

(i.e. if I can improve the protection type I prefer the candidate in any
case - and step 15 is not relevant)
My point was only to ensure that the distance is used as the first
tie-breaker
for candidates with equal protection type. 

Stefan.

---

From: "Alia Atlas" <[email-masked]>
Date: Sat, 24 Feb 2007 08:54:37 -0800

Yes, you're right.  I was rereading quickly.  The question is more between
the type of alternate (LFA, not-via, etc) and the distance.

Alia

---

From: "Schnitter, Stefan" <[email-masked]>
Date: Sun, 25 Feb 2007 14:39:49 +0100

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

---

From: mike shand <[email-masked]>
Date: Mon, 26 Feb 2007 08:59:44 +0000

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

---

From: Stewart Bryant <[email-masked]>
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.
> overhead of tunnelling the not-via may sometimes be just what you don't 
> want if you can avoid it.
> 
> 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.
>