Speaking as WG Chair: I believe this discussion has gone off track and the details of the BGP alternatives need to be discussed on the IDR list. For the purposes of the LSR discussion, Robert believes that this is a problem that needs to be solved but that it could be better solved using BGP as described in draft-raszuk-idr-yet-another-complex-idr-draft-00.txt.
Correct me if I'm wrong... Thanks, Acee On 11/29/21, 10:46 AM, "Lsr on behalf of Hannes Gredler" <[email protected] on behalf of [email protected]> wrote: hi aijun, On Mon, Nov 29, 2021 at 07:16:18PM +0800, Aijun Wang wrote: | 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. HG> BGP-LS has been used now beyond 3rd party controllers. I do also see you as co-author of some drafts in LSVR Note that a similar protocol machinery like used in LSVR can be made to work for your use case here. | | 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. perhaps you start elaborating what *exactly* you find not convincing of the proposed IGP/BGP split. thanks, /hannes _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
