Subject: Re: Question regarding multi-homed prefix LFA computation

From: mike shand <[email-masked]>
Date: Fri, 15 Feb 2008 10:02:06 +0000

Kui Zhang wrote:

Hi Alia,

If there is
a way to decide how that prefix is
attached to multiple advertising routers before the failure, and which
one is
preferred, can we make that prefix inherit the alternate next hop from
the
advertising router?

Interestingly that is what we propose in the not-via draft, BUT it
requires that the traffic be tunnelled to the next best attachment
point.

You cannot do as you propose without tunnelling, because the packets
will always be routed towards the "best" attachment point (which may be
the node which has failed.

Mike

The
alternate next hop should be loop free respect to that
prefix. Otherwise, must we make the logical topological transformation
to
compute alternate next hop for multi-homed prefixes? I think we should
provide
an alternative to achieve this.

As for
node-protecting alternatives, I read the
following description in section 3.3.
Broadcast and
NBMA Links:

“Because the shortest
path from the pseudo-node goes through E, if a

loop-free
alternate from a neighbor N is
node-protecting, the

alternate
will also be link-protecting
unless the router S can only

reach the
alternate neighbor N via the
same pseudo-node.”

This means
only the SRLG of broadcast and NBMA links
make the node-protecting LFA failed to provide link protection.
Otherwise,
node-protecting alternate should always be link protecting. Is that
right?

zhangkui

From:
Alia Atlas [mailto:[email-masked]]

Sent: Friday, February
15, 2008
12:39 PM

To: Kui Zhang

Cc: mike shand; [email-masked]; 邓秋林;
王允庆

Subject: Re: Question
regarding
multi-homed prefix LFA computation

Hi Zhang Kui,

2008/2/14
Kui Zhang <[email-masked]>:

Hi Alia and
Mike,

For a
multi-homed prefix, I suggest we can also point out, if the
logical topological transformation is not desirable, consider it as a
single-homed prefix. In this case, we should also point out the
destination
router D used to compute the alternate next hop for this prefix should
be the
one preferred in the normal route calculation process.

I don't believe that you can
consider a multi-homed
prefix as a single-homed prefix.  The original SPF that is in use
before
the failure will not have done that.  There's no way of deciding how
that
prefix was attached.

Besides, the
dependency between link-protecting LFA and node-protecting
LFA condition seems not so clear, can we point out if a candidate
neighbor
meets the node-protecting inequality, it will always meet the
link-protecting
inequality? I read the following words in section 3.6.  Selection
Procedure, which seems implying such a dependency exactly.

"Loop-Free
Node-Protecting Alternate -  This next-hop
satisfies

Inequality 1 and Inequality 3.  The
path avoids S, S's primary

neighbor E, and the link from S to E."

It is not the case that a
node-protecting LFA is
guaranteed to also be a link-protecting LFA.

I believe that there is a clear counter-example given in the section
discussing
broadcast interfaces (such as Ethernet).

Alia

zhangkui

From: Alia
Atlas [mailto:[email-masked]]

Sent: Thursday,
February 14, 2008
10:08 PM

To: mike shand

Cc: Kui Zhang; [email-masked]

Subject: Re:
Question regarding
multi-homed prefix LFA computation

It does look like
the costs are not correct
to have A provide a node-protecting alternate.  As Mike suggests, I'll
change the cost of SA to be 8 instead of 4.

As to the multiple-prefix with the same difference, that is correct.
Certainly the costs between the advertising routers and the prefixes
need to be
considered, but they can be grouped intelligently for computation.  Let
me
see if I can explain better - perhaps we can but some better text in
there.

Say there is another prefix p2 that is also attached to E, with a cost
of 3,
and to F with a cost of 5.  Then one could just look at the difference
between the costs for the attachments for the computation.

Compare   cost(S to E) + 0     versus
cost(S to F) + 2

Now, one can add 3 to both parts without changing which is larger - and
that
will give the final cost to p2.

Similarly, one can add 5 to both parts without changing which is larger
- and
that will give the final cost to p.

Alia

On
Thu, Feb 14, 2008 at 7:17 AM, mike shand <[email-masked]>
wrote:

Kui
Zhang wrote:

Hi
all,

I
have a doubt about multi-homed prefix LFA
computation described in draft-ietf-rtgwg-ipfrr-spec-base-10:

"If
the alternate
next-hop for the

prefix
p is simply inherited from
the router advertising it on the

shortest path to p, then the prefix p's
alternate next-hop would be

the link to C. This would provide link
protection, but not the node

protection that is possible via A.

5   +---+  4   +---+  5  +---+

------| S |------| A |-----| B |

|     +---+      +---+
+---+

|
|
|

|     5 |
5 |

|       |
|

+---+ 5 +---+   5       7
+---+

| C |---| E |------ p -------| F |

+---+
+---+
+---+

Figure 6: Multi-homed prefix"

It
seems router A is not a valid node-protecting
LFA, which will cause a forwarding loop.

And
the following words seem incorrect since we have
to take the cost from the advertising router to the advertised prefixes
into
consideration.

"If there exist multiple
multi-homed prefixes that share the same

connectivity and the difference in
metrics to those routers, then a

single node can be used to represent
the set."

For
example, in figure 6, if the cost for prefix p to
F decreases to 4, then router A will be a valid node-protecting LFA.

Do I
miss something here? Thanks for helping me in
advance.

There does seem
to be something wrong here
as you point out. Actually even decreasing F-p to 4 doesn't completely
fix it
because then A would have an ECMP path to p (both cost 14). The cost
would need
to reduce to 3 to fix this.

However, it would be better to fix it by (say) increasing the cost of
link SA
to 8. This would ensure that the later text about prefix X was also
correct.

But maybe Alia had something else in mind?

Alia?

Mike

Regards,

Zhangkui

_______________________________________________

rtgwg mailing list

[email-masked]

http://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________

rtgwg mailing list

[email-masked]

http://www.ietf.org/mailman/listinfo/rtgwg

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