The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Apr> msg00047



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Last Call on RSVP Label Allocation for Backup Tunnels

  • From: Bora Akyol <akyol@pluris.com>
  • Date: Tue, 3 Apr 2001 18:47:30 -0700
  • Cc: mpls@UU.NET

Ping

At least in one implementation of APS and FR that I am familiar with, the
timing to generate a switchover between the two is very close in terms of
failover and in this particular implementation, APS switchover timing meets
less than 50 ms.

So I would not immediately rule out FR timing in place of APS.

Bora
Who is quite "familiar" with one implementation


-----Original Message-----
From: Ping Pan [mailto:pingpan@juniper.net]
Sent: Tuesday, April 03, 2001 6:33 PM
To: Dave Cooper
Cc: mpls@UU.NET
Subject: Re: Last Call on RSVP Label Allocation for Backup Tunnels


Dave Cooper wrote:
> 
> But on the topic of MPLS OAM, it has its
> merits -- especially when software failures (whereby the control plane
> does not detect failures in the data plane) seem to continue to be the
> bane of most MPLS implementations.  I've been preaching this directly
> to vendors for quite some time and despite what tweaks we put into the
> control plane for dealing with failure (whether its fast reroute, normal
> reroute, whatever), its still doesnt fix this constant problem.  Customers
> are tired of hearing the vendor bug excuse.
> 
> dave
> 

Dave,

Agree! Also it's hard to find much overlap between MPLS fast-reroute and
physical link failure detection (such as SONET APS). Although both try
to minimize packet loss, these are fundamentally different technologies.
One does not replace the other, and one does not preclude the use of
other. 

In particular, one big difference between the two is timing:
fast-reroute time is probably lower than typical ISIS/OSPF convergence
time in today's backbone. But fast-reroute time may still be higher than
SONET APS. In particular, I don't think that fast-reroute can offer
guarantees on the upper bound of fail-over time. There are simply too
many uncontrollable variables affecting the fail-over speed, no matter
what type of fast-reroute mechanism you choose.

Regards,

- Ping