Hi, Robert:
From: Robert Raszuk <[email protected]> Sent: Wednesday, January 26, 2022 7:58 AM To: Aijun Wang <[email protected]> Cc: lsr <[email protected]>; Tony Li <[email protected]> Subject: Re: [Lsr] BGP vs PUA/PULSE I think we have to accept that we have very different understanding on what out-of-band means. But let's not get hang on this here. Because to do it efficiently and in scalable manner close cooperation with LSDB is required. Management system is completely orthogonal to that. [WAJ] Then why reluctant to accept the solution that based on the current IGP mechanism? IMO Tony's proposal is a a new IGP message type with new transport. While a separate subsystem (which can in fact run on different core and have independent memory space ie. be a different thread or process) it is both functionally and operationally an IGP service. Just like PUA or PULSE. [WAJ] There is already such message, and such transport within IGP, why design another what you called IGP-like message(actually it is not) and transport again? As said earlier, the PUA/PULSE is just also the same purpose message, it doesn’t influence the SPF efficiency. What’s the unsolved concerns regarding to the PUA/PULSE then? People may argue that flooding can get the result that the message is sent to the unsolicited node. But as also we have discussed earlier, the PUB/SUB model will eventually dive into the full-mesh style. And, we should consider the network are evolved to the stateless approach, for example, the SR/SRv6’s replace to RSVP/LDP etc. But PUB/SUB will let the PEs, especially the ABRs back to keep the (connection) state again. Do you still think it is one scalable solution? Flooding is not MUST have paradigm for an IGP where IGP == Interior Gateway Protocol. As you know some folks use BGP as IGP for MSDCs. Clearly BGP does not use too much flooding. [WAJ] Then RSVP、PIM、LDP etc. can all be called IGP protocol? Certainly not. Best, Robert. On Wed, Jan 26, 2022 at 12:48 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Robert: Then why not let all of these out of band messages delivered via the management system? Aijun Wang China Telecom On Jan 25, 2022, at 23:28, Robert Raszuk <[email protected] <mailto:[email protected]> > wrote: Auto discovery is described in the draft. You may also provision this session by your management plane just like you push 1000s of configuration lines anyway to each network element. Those are commonly used techniques to run a network. On Tue, Jan 25, 2022 at 4:07 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Or, I guess you still need the ABR to act as the server. But, how these RRs know which router is ABR? Aijun Wang China Telecom On Jan 25, 2022, at 23:01, Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Robert: You mean make every PE as the register server? Aijun Wang China Telecom On Jan 25, 2022, at 21:21, Robert Raszuk <[email protected] <mailto:[email protected]> > wrote: Aijun, No, I think you misunderstanding our purpose. You are using this argument towards a number of people ... I recommend you reconsider. The proposed solution can fit in small network, or large network and RR can locate anywhere the operator want to place. We have no assumption about the location of RR and PEs. Please observe that if you really want to put RRs outside of your local area for whatever reason (maybe you run RR as a service in the cloud) then actually we can combine X from my additional point with Tony's proposal. It just occurred to me like a really interesting deployment mode so let me describe the WG. Maybe Tony can add this model to his draft in the possible deployment section. - - - When network elements residing outside of the local area are interested in node liveness of selected nodes in the area (for example BGP Route Reflectors running in the cloud) they can register with node liveness servers in an area to receive targetted notifications for interested addresses. Such notifications can be used to invalidate service next hops or tunnel endpoints. Upon such action service information will be immediately withdrawn. That deployment model offers full flexibility with just a handful of additional TCP or QUIC sessions needed and very little to no extra state injected in the network. - - - That model also addresses some concerns associated with any to any registrations. No longer PEs need to register anything with ABRs nor ABRs need to pass that information around. Best regards, R. _______________________________________________ Lsr mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
