> > [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 apply. 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 customers. 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 sure. Many thx, R.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr