Hi, Hannes: -----Original Message----- From: Hannes Gredler <[email protected]> Sent: Monday, November 29, 2021 5:27 PM To: Aijun Wang <[email protected]> Cc: 'Robert Raszuk' <[email protected]>; 'lsr' <[email protected]>; 'Les Ginsberg (ginsberg)' <[email protected]>; 'Tony Li' <[email protected]>; 'Shraddha Hegde' <[email protected]>; 'Peter Psenak' <[email protected]> Subject: Re: [Lsr] BGP vs PUA/PULSE
On Mon, Nov 29, 2021 at 09:42:57AM +0800, Aijun Wang wrote: [ ... ] | Option 3: The “DOWN” detection on ABR is same as PUA/PULSE, the different | is how to propagate such “DOWN” information. Considering we have observed | that all P/PE router in other areas may be interested such information, | your proposal will require every P/PE router run BGP-LS, which is not the | aimed deploy scenarios for BGP-LS. HG> BGP-LS has been conceived to solve the very problem of providing HG> visibility of other area's link state. I fail to see what is out of scope here. [WAJ] Yes. But it is not for the nodes within IGP itself. It's main aim is to feed the underlay topology information to the controller. | Then, if IGP has such capabilities, why bother BGP? What is the benefit? HG> simply put: seperation of concerns. Agreed consensus is to mostly HG> use the IGP for topology discovery and put the bulk of carrying reachability information into BGP which gives us: 1) flow-control capabilities (=by virtue of TCP) and 2) furthermore operators can scale and isolate the distribution vehicle for a given AFI/SAFI service using a dedicated RR infrastructure which does not mess with your bread and butter service infra. IMO it is not a good idea to put (negative) reachability information back into the IGP as you would loose this "seperation of concerns" aspect and potentially de-stabilize your topology discovery tool and hence *all* your bread-and-butter services. [WAJ] Yes. We are seeking the solution to the potential use of such unreachable information. Current BGP solutions has not convinced me until now. HTH, /hannes _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
