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. 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. 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. Best, Robert. On Wed, Jan 26, 2022 at 12:48 AM Aijun Wang <wangai...@tsinghua.org.cn> 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 <rob...@raszuk.net> 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 <wangai...@tsinghua.org.cn> > 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 <wangai...@tsinghua.org.cn> 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 <rob...@raszuk.net> 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 >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
