Subject: Fast Reroute Interoperability

From: "Gustavo Bellotto (CEA)" <[email-masked]>
Date: Fri, 05 Oct 2001 10:28:14 -0300

Hello,

In spite of the different way that Juniper and Cisco have taken
to provide fast reroute protection, making them not interoperable,
I'm wondering if there is any way to build a scheme were both can
coexist in a MPLS fault protected network. A valid solution could
consider nested tunnels and statically configured LSPs.
In our particular case Cisco GSR builds up the core and Juniper the
edge of the backbone.

Regards,
Gustavo

---

From: Jim Boyle <[email-masked]>
Date: Fri, 5 Oct 2001 10:15:41 -0400 (EDT)

> In our particular case Cisco GSR builds up the core and Juniper the

This is true, and in the last meeting it was noted by the authors that
they think they can bring together a common draft.  That would be a good
thing as it would seem to meet one of the requirements in
draft-ietf-tewg-restore-hierarchy-00.txt.  This is the only approach to
restoration times in the 10s to 100s of ms.

Another approach that both do support is that of 1:1 Path LSPs where when
traffic is on a primary, and if that has problems, the traffic shifted
onto another pre-signalled LSPs (assuming that one is still ok).  This can
bring restoration times down significantly (maybe shave 5-10 seconds off
not having this), but there still are impacts at the head end routers as
they shift the traffic.  This approach satisfies another
restoration requirement in the above mentioned tewg document.

Jim

---

From: Jim Boyle <[email-masked]>
Date: Fri, 5 Oct 2001 10:15:41 -0400 (EDT)

Jim

---

From: Ping Pan <[email-masked]>
Date: Fri, 05 Oct 2001 09:48:31 -0700

> to provide fast reroute protection, making them not interoperable,

Juniper and Cisco try to solve the same problem differently. Each scheme
has its own features. It's not an issue of "not interoperable". It's an
issue that they were designed and implemented separately. As discussed
in the last IETF, we are actively merging both drafts together in a way
that can benefit network operators to provide the best fast reroute
functionality that both drafts can offer.

> coexist in a MPLS fault protected network.

Yes.

> A valid solution could

No. You turn on the fast reroute function at the headend, and config the
router interfaces according to your needs (if necessary). Fast reroute
should work in the background for all LSP's.

Take care!

- Ping

> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: Ping Pan <[email-masked]>
Date: Fri, 05 Oct 2001 09:55:24 -0700

Jim,

> restoration times in the 10s to 100s of ms.

OK.

> onto another pre-signalled LSPs (assuming that one is still ok).

Yes.

> This can
> they shift the traffic.

As you mentioned above, there is an impact (ERO recomputation and LSP
setup delay) if the headend router has to setup a new LSP to repair the
failed one. If you have a "hot" standby LSP at the headend, the impact
will be very small.

Fast reroute is to protect the traffic that is already in the network.
When there is a link failure, the router will reroute the traffic, while
notifying the headend routers. Hopefully and eventually, headend routers
should switch the traffic to better LSP's.

Regards,

- Ping

>  This approach satisfies another