The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: Reasons to deploy MPLS-TE
I think the reason for the FRR is faster than others is frr is local repaired.In most the isp network,the service traffic is carried by bgp route.So when the topology is changed,the igp convenge is faster than bgp to change the forwarding table.the most time is wasted in bgp change the nexthop.the the total time is igp convenge time+forwarding table time.this time is larger the frr so far and it's assocate with the network topology.in some topology,the igp+bgp convenge time is so larger than your considered. -----Original Message----- From: mpls-ops-request@mplsrc.com [mailto:mpls-ops-request@mplsrc.com]On Behalf Of Puddinhead Wilson Sent: 2004年5月7日 14:00 To: Vinay Bannai; sthaug@nethelp.no Cc: mpls-ops@mplsrc.com Subject: Re: [MPLS-OPS]: Reasons to deploy MPLS-TE Hello Vinay, inline.. Vinay Bannai <bannai@pacbell.net> wrote: 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. >> >>>>>>>This depends on what the intermediate devices are, does it not? Eitherways, one can use BGP based ECMP kind of things to achieve the result. Moreover, in eithercase, the one end of the LSP has to know that the other end is down. How does this work out if a node withdraws a prefix if one was to use IGP/LDP or RSVP-TE or PWE for settin up LSPs? >>>>>>>>>For simplicity, let us assume it is an ordinary v4 network and we are advertising v4 prefixes as tunnel end points. In OSPF we would flood a v4 withdrawal or send out a new LSA with the missing prefix. If it is BGP full mesh, the node would anyways send it out to all other nodes. >>>>>>>In either case, each node has to stop using a particular LSP, to FRR to another (even if the backup LSP is already set up), does it not? So the "event trigger" is *still* needed. ofcourse, it can be flooded. However, if each intermediate node was to "set the next-hop" to "self", would it actually account for such a considerable change in the "FT" when rerouting an LSP?? I agree this is topology specific, but in most cases, the change in FT entries would be limited to a specific subset of the path even in BGP?? >>>>>>Typically on a simple v4 network today, how does it matter if one uses BGP full mesh? there is no "pseudo wire" from A to B, so even if the topology has not compeltly converged, packets will traverse around the network till they reach a node which is accurate and then reach the end point. How would it be a problem as packets do not drop even in this case? If you say that "packets" already on the "way" can be dropped, then it can happen in the other case too till we get the "trigger" 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 http://uk.messenger.yahoo.com/download/index.html ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml |
|