Subject: RE: [Idr] Link failures and hot-potato routing

From: András Császár (IJ/ETH)<[email-masked]>
Date: Fri, 1 Apr 2005 12:37:54 +0200

Hi people!

Thanks for the useful answers. So, with pure IP it is a non-neglactable phenomenon that IGP path changes result in edge router change as well (i.e. BGP path changes).

However, if MPLS shortcuts are appropriately configured between edge devices, this will not occur.

And what about timing? If I remember correctly, there is no upcall from IGPs to BGP if the intra-domain path cost changes, so the router will not immediately detect the change. Instead, the BGP process runs periodical scans for IGP changes, is that right? What is a practical value for this timer, 60sec?

What do you think, is the following scenario practically possible:

- In an AS, packets are forwarded to a destination D between the ingress router I1 and the egress router E1.
- At a point, an intermediate link goes down, IGP has a re-route between I1-E1. The path changes the first time due to IGP re-route. (Sprint results show that sub-second IGP convergence is realistic.)
- The new path has a higher cost than an alternative I1-E2 route, i.e. some time later the BGP process will select this as a new best path, so we'll have a second route change, e.g. a minute later.

Thanks,
András

----Original Message----
From: Sebastien Tandel [mailto:[email-masked]]
Sent: 2005. április 1. 6:01
To: András Császár (IJ/ETH)
Cc: [email-masked]
Subject: Re: [Idr] Link failures and hot-potato routing

>> Hi!
>> 
>> Does anyone have any statistical data how often intra-domain link
>> failures cause that a new (egress) edge router is used after the
>> failure?  
>> 
>> Am I correct to assume that this is very much possible with BGP in
>> case of hot-potato routing (i.e. if the best path is selected based
>> on the IGP cost metric)?  
>> 
> yes, it may be the case.
> 
>> For example, if the new path between the original ingress-egress
>> routers after re-routing has a higher IGP cost after an IGP SPF
>> calculation than another path between the original ingress and
>> another egress edge router. correct !   
> 
> 
> 
> There's a paper on this topic from Renata Teixeira and Jenifer Rexford
> submitted to PAM05:
> http://www.cse.ucsd.edu/~teixeira/tm.pdf
> 
> As Abilene was mentioned, there is also the european counterpart,
> GEANT, from which a study has been made but the paper is only
> submitted. It's a different way to study this case but I can't say
> you more until the paper is accepted ... :(
> 
> It's a hot topic for the moment, nobody really knows the actual
> implications of the interaction between the IGP and BGP in practice.
> But in a few words, it strongly depends on the design of the IGP and
> the eBGP peerings. If you want more information than ones in the paper
> forementioned you may send me a mail.
> 
> 
> Sebastien Tandel

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 01 Apr 2005 11:16:14 -0500

In message <[email-masked]>
Andr s Cs sz r writes:
>  
> And what about timing? If I remember correctly, there is no upcall
> from IGPs to BGP if the intra-domain path cost changes, so the router
> will not immediately detect the change. Instead, the BGP process runs
> periodical scans for IGP changes, is that right? What is a practical
> value for this timer, 60sec?

That's implementation dependent.  A decade ago that is how the leading
vendor(s) did things.  Today most widely used implementations afaik do
the IGP SPF within 10s of msec of an isolated IGP change, a few 100
msec normal worst case (flood of IGP changes), then apply BGP routes
to the new IGP next hops immediately after IGP routes are changed.
Vendors are claiming sub-second to a few seconds of convergence of BGP
after IGP change though some claims may not be specific about how many
BGP routes.  60 sec on IGP change is not viable product today at least
for core routers.  Might be OK for enterprise but not desireable.

Curtis

ps - This is really about implementation and not about protocol.
Please excuse the continuation of this slightly off topic discussion
(slightly off topic for the IDR mailing list).