Hi, Robert: For BGP next-hop tracking, it will help when the BGP next-hop is unreachable. But in our situation, the BGP next-hop is reachable, but should pass another ABR.
Then, in such situation, the mechanism of BGP next-hop tracking will not take effect? And thanks for your draft information, maybe we can refer to it later J Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Monday, September 7, 2020 4:54 PM To: Aijun Wang <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra <[email protected]>; Peter Psenak <[email protected]>; Huzhibo <[email protected]>; Aijun Wang <[email protected]>; lsr <[email protected]>; Acee Lindem (acee) <[email protected]>; Xiaoyaqun <[email protected]>; Tony Przygienda <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt Hi Aijun, [WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for the hold of PUA information on the nodes) among the area. If one node connect to the network after the disappearance of the PUA destination, there will be no services can be established/run on these failure node/link prefix. It’s the same as the beginning, as not all of the prefixes can be reachable within the summary address. >From my pov the only advantage of negative routes in IGP would be to very >quickly invalidate service routes (within the IGP domain) typically carried by >BGP. When this is accomplished the PUA can indeed time out with no harm. Said this - now considering tools like next hop tracking which can trigger withdraw or aggregated withdraw(*) proposal in src area I am really curious how much (if anything) we would be gaining here. (*) The original proposal for this was written over 15 years ago: https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00 We could extend it with next hop which would be the same as IGP PUA prefix. Kind regards, Robert
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
