The MPLS-OPS Archive

[Puddinhead Wilson <puddinghead_wilson007@yahoo.co.uk>]

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