The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2004-May> msg00033



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

Re: Reasons to deploy MPLS-TE

  • From: "Vinay Bannai" <bannai@pacbell.net>
  • Date: Thu, 6 May 2004 13:53:00 -0700
  • Cc: <mpls-ops@mplsrc.com>
  • Resent-Date: Thu, 6 May 2004 17:31:52 -0400
  • To: "Puddinhead Wilson" <puddinghead_wilson007@yahoo.co.uk>, <sthaug@nethelp.no>
  • X-OriginalArrivalTime: 06 May 2004 20:56:58.0208 (UTC) FILETIME=[ABBFC600:01C433AC]

See my comments below.

Vinay Bannai
Luminous Networks
----- Original Message ----- 
From: Puddinhead Wilson
To: sthaug@nethelp.no
Cc: mpls-ops@mplsrc.com
Sent: Thursday, May 06, 2004 11:56 AM
Subject: RE: [MPLS-OPS]: Reasons to deploy MPLS-TE


Hi,

I agree BGP forwards only 1 route, yet how would you say FRR is slower?

take this case of how it wokrs in LDP/OSPF
1. we wait for an LSP to down to be detected
2. we then use new LSP after detection and using the protocol's database to
see alternate route to node after receiving the "tigger".

>>
It all depends on the fault notification mechanism and where the reroute
happens. If the fault notification is based on such things as LOS instead of
say, software heartbeat timeouts, then the trigger can be very fast. It also
depends on how the LSP is provisioned. If the alternate (or the protect) LSP
is alreday setup a priori then it might be faster. Nowadays most of the
forwarding happens in fast path. In the event of a fault notification
message, the LSR switch has to determine the affected LSPs and the
associated alternate LSPs and downloaded/notified to the forwarding path.
There are many variables.
>>


Incase of BGP it would be:
1. VPNv4 route withdrawn, and hence the BGP update propgates a new route
immediately after running decision making alogirhtm (implicit withdraw et
al )
2. this amounts to *almost* the same propogation delay as case 1
above...does it not?

>>>
In this instance, the route churn and the computation depends on the number
of routes in the routing table and the horsepower of the router. BGP routers
do have run complicated tasks to take into account MEDs, community
attributes and other metrics before converging on the alternate route. Then
the new route needs to be advertised to its peer. The peer needs to process
this new information and then translate that into a forwarding entry to be
downloaded on the line card interfaces (assuming the routing is being done
in fast path). The mileage may vary based on each vendor's implementation.

Overall I would think that processing time for LSP re-route should be faster
(if the alternate LSP is already setup) than the BGP re-route.
>>>

Yahoo! Messenger - Communicate instantly..."Ping" your friends today!
Download Messenger Now

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