Maybe even use SDN / PCE centralized controller , stateful PCE which has peer to each node to instantiate the LSP as well as now manage the component prefixes state. So we can drift completely out of the IGP realm but we are choosing to stay in IGP realm with PUB/SUB.
The PUB/SUB model has been mentioned that it has very low overhead as it propagates the notification messaging using PUB/SUB model which is in theory less chatting then PULSE and PUAM IGP flooding of the event notification. PULSE/PUAM also have the same very low overhead as it’s the same PUB/SUB link Up/Down notification messaging being carried by the IGP and not via separate protocol (out-of-band). In the PUB/SUB model in reality it is similar to and no different then IGP flooding, as once a prefix goes Up / Down, the message is sent immediately to all nodes in the area, no different then PUA/PULSE IGP flooding. The ABRs flood over a TCP mesh to all routers in the area which is literally identical to IGP flooding just using a different transport protocol. Kind Regards Gyan On Tue, Jan 25, 2022 at 6:48 PM Aijun Wang <[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]> 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]> > 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]> 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]> 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] >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
