> [WAJ] Such information is for underlay link state and should be flooded
> via IGP? The ambiguity arises from IGP summary behavior and should be
> solved by itself?

Well if we look at this problem from a distance while on surface it seems
like an IGP issue (not to mention some which use BGP as IGP :) IMO it is
only hurting when you have some service overlay on top utilizing the IGP.

So typically today if I am running any service with BGP I do count on BGP
to remove routes which are no longer reachable. IGP just tells me how to
get to the next hop, which direction to go and not if the endpoint (service
CPE or PE connected to given CE) is up or down.

So today smart BGP implementations in good network design can use RD based
withdraws to very fast (milliseconds) remove the affected service routes.
When I said should we do it in BGP I meant to ask WG if this is good enough
to quickly remove service routes. If not maybe we should send such affected
next hop in BGP to even faster invalidate all routes with such next hop as
failing PE.

Bottom line if you think the problem is IGP then I think Acee's comments

Last - See today you are bringing the case to signal transition to DOWN ...
but for some people and applications it may be not enough. In fact UP/DOWN
they can get via BGP. But if you have two ABRs and one will due to topology
changes in its area suddenly will be forced to reach atomic destination
covered by summary over much higher metric path that for applications
running above may be much more severe case and not acceptable one too.

And BGP will not remove service routes nor modify best path in any way as
summary is masking the real metric to some next hops. So while in the
network you may have alternate better native transit paths with a lot of
free capacity if you only switch to a different bgp next hop (not talking
about any TE at all) you are stuck offering much worse service to your

Those cases are starting to be solved by performance routing both at the
service itself or at BGP nh levels. Should IGP assist here ... I am not

Many thx,
Lsr mailing list

Reply via email to