Hi, Robert:

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang <wang...@chinatelecom.cn>
Cc: Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Huzhibo 
<huzh...@huawei.com>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr 
<lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Xiaoyaqun 
<xiaoya...@huawei.com>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

[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. 

[WAJ] There are situations that the PUA mechanism apply when no service overlay 
running over IGP.  Scenarios described in  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
 draft-wang-lsr-prefix-unreachable-annoucement-03#section-3 are not tightly 
coupled with the overlay service.

 

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. 

[WAJ] Which comment is not addressed yet?

 

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. 

[WAJ] Or else, the application traffic will be broken.

 

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. 

[WAJ] if there are other links to reach the affected prefix via the ABR, then 
this ABR will not send the PUA information.

 

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.

[WAJ] when node become down, it can only depend on other nodes within the same 
IGP to send such unreachability information. IGP can certainly help here J

 

 

Many thx,

R.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to