Subject: Re: Fast Reroute Interoperability

From: [email-masked]
Date: Fri, 05 Oct 2001 10:06:22 -0400

What about B and C?

 B.  Implements only [DETOUR].

 C.  Implements only the local protection enhancements given in
     [RSVP-TE], according to the guidelines in [BYPASS].

 -Rajiv

----- Original Message -----
From: "Gustavo Bellotto (CEA)" <[email-masked]>
Date: Friday, October 5, 2001 9:50 am
Subject: Re: Fast Reroute Interoperability

> As far as I know neither Cisco or Juniper are in the
> Set A:
> 
>      "A.  Implements both the local protection enhancements given in
>          [RSVP-TE] and [DETOUR] as described in this draft."
> 
> mentioned in Atlas´s draft.
> 
> -Gustavo
> 
> [email-masked] wrote:
> 
> > Hello Gustavo,
> > 
> >  The following draft talks about the guidelines for 
> interoperation with 
> > either of the two implementations you mentioned:  
> >  
> >         draft-atlas-rsvp-local-protect-interop-01.txt
> >  
> >  I hope this helps.
> > 
> >   -Rajiv
> >   
> > ----- Original Message -----
> > From: "Gustavo Bellotto (CEA)" <[email-masked]>
> > Date: Friday, October 5, 2001 9:28 am
> > Subject: Fast Reroute Interoperability
> > 
> > 
> >>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: Ron Fortner <[email-masked]>
Date: Fri, 5 Oct 2001 12:22:33 -0400

Interesting concept but I worry about the complexity and scalability of such
a solution.  

-----Original Message-----
From: Gustavo Bellotto (CEA) [mailto:[email-masked]]
Sent: Friday, October 05, 2001 9:28 AM
To: [email-masked]; [email-masked]
Subject: Fast Reroute Interoperability

Hello,

Regards,
Gustavo

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

---

From: Zappacosta Rolando Jorge <[email-masked]>
Date: Fri, 5 Oct 2001 14:54:31 -0300

Gustavo: I was thinking to use Junipers as LER's running protection
switching between 'em and fast reroute in the core (cisco's GSRs). This way,
in case a link failure in the core the fast reroute would be acting in the
cisco's with no knowledge at all by part of Junipers. In case the link
between a Juniper LER and a Cisco LSR goes down the protection switching
would resolve this situation behaving just like a fast reroute solution
(i.e. the detour been taken in the router directly connected to faulty link)
Regards,
Rolando.

> -----Mensaje original-----
> De:	Gustavo Bellotto (CEA) [SMTP:[email-masked]]
> Enviado el:	Viernes 5 de Octubre de 2001 10:28
> Para:	[email-masked]; [email-masked]
> Asunto:	Fast Reroute Interoperability
> 
> Hello,
>

---

From: "Hemant P. Kelkar" <[email-masked]>
Date: Sun, 7 Oct 2001 18:36:31 -0400 (EDT)

Hi Narsim,

It was a good comparison. This means that:
#1. Those products in which the the LSP protection is using the hot
standby mode, suffer from the drawback of not using the label space
economically, apart from putting the burden of setup,management and
maintanance of the hot standby LSPs.
#2. Those products which (opposite to 1 above) discover and route the data
at the time of failure, suffer with significant protection switching
delays. The complexity of the re-route and route-calculate problem is more
in this case.
#3. What did the term in point 2 of the document, referred to ? (term =
C.B.)
#4. Products with scheme 1 seem to be less dynamic to topology changes,
since the hot standby LSPs may be set up using PVC mechanisms.
#5. By the way, how much protection switching time is expected in both
cases ?

Regards,
---
Hemant