Subject: [mpls] COMMENTS/CONCERNS/... about draft-defeng-mpls-mini-fast-rerouting-00.txt

From: JP Vasseur <[email-masked]>
Date: Tue, 8 Mar 2005 11:10:10 -0600

Hi,

Note sure where to start ....

First comment, you pointed out potential weaknesses of both IPFRR and 
MPLS TE FRR that actually are incorrect ....

You write:

The characteristics of IP FRR is that it performs the reroute according
to the port state and the backup ports are configured manually, so the
optimization can't be guaranteed in the case of complex network
topology, what's more, when the configured backup port is in failure
prior to the primary port, even there are other ports can function as
backup port, they can't be used as rerouting.

Both statement are actually incorrect ! The backup path can be computed 
dynamically of course.

MPLS network need FRR to protect the traffic transported on MPLS LSP in
the case of link or node failure, and in [2]
draft-ietf-mpls-rsvp-lsp-fastreroute-07, the MPLS fast rerouting
mechanism of extension to RSVP-TE is detailed, it requires that RSVP-TE
is deployed as the label distribution protocol in the network, however,
in some network, LDP rather than RSVP-TE is deployed as label
distribution protocol, so FRR based on RSVP-TE can't be performed;

Note that their deployment is not exclusive

another point is that the backup LSP in RSVP-TE FRR is manually
configured, so the configuration job is such a burden in large scale
network; moreover, to protect the link, node or path respectively, the
different backup LSP are accordingly required, which will consume a
large amount of resource in the network. In this section, a simple MPLS
FRR mechanism based on LDP(called MPLS mini-FRR) is introduced.

No ! the backup tunnel path can be configured dynamically (even 
including many other constraints such as SRLG membership). Note that 
there are several implementations supporting this. And of course, the 
FRR document does not mandate to manually configure the backup tunnels 
by all means,

2) Note that the two previous scheme are local protection schemes.

3) More importantly ... your mini-FRR scheme works well on a 
mini-topology ....

In your example, please try the two following changes:

-> make the shortest path from R3 to R5 be: R3-R1-R2-R5
-> insert a router between R2 and R3 so that R3 cannot detect the R2's 
failure.

?

Thanks.

JP.

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 08 Mar 2005 12:28:35 -0500

The method in the document seems to compute a "second-best" path in the 
event of the isolated local failure.  Unfortunately, the second-best path 
may not be one that can actually taken in the network successfully until 
the network has converged.   This is one of the complications with IPFRR.

JP's modified example below demonstrates this problem.

Alia

At 12:10 PM 3/8/2005, JP Vasseur wrote:
>3) More importantly ... your mini-FRR scheme works well on a mini-topology 
>....
>