Hi Tony, Very happy to see this draft.
First question - the draft seems to be focusing on hierarchical IGPs and is clearly driven by liveness propagation discussion. But the motivation of offloading non routing information from IGPs (and/or BGP) is also full applicable to non hierarchical IGPs where there is no ABRs. Do you plan to rewrite section 3 accordingly ? Also putting liveness aside wouldn't it be feasible to also relax the attachment to each area/level such that truly opaque information can be exchanged even if we use as broker DROID cluster sitting only in core area and listening to data or liveness from all clients ? The DROID discovery in the latter case could be as simple as one line cfg. Networks could also use well known anycast address to connect network elements to DROID cluster. Thx, Robert On Mon, Apr 4, 2022 at 6:48 PM Tony Li <tony...@tony.li> wrote: > > Hi all, > > As discussed during our last meeting, the Node Liveness Protocol could be > generalized to support arbitrary data. > > I’ve done that work, turning it into a distributed object store. > > In particular, node capabilities are now a generic example of the use of > this mechanism. Node Liveness is still included as an custom mechanism. > > Comments? > > Tony > > > Begin forwarded message: > > *From: *internet-dra...@ietf.org > *Subject: **New Version Notification for draft-li-lsr-droid-00.txt* > *Date: *April 4, 2022 at 9:43:57 AM PDT > *To: *"Tony Li" <tony...@tony.li> > > > A new version of I-D, draft-li-lsr-droid-00.txt > has been successfully submitted by Tony Li and posted to the > IETF repository. > > Name: draft-li-lsr-droid > Revision: 00 > Title: Distributed Routing Object Information Database (DROID) > Document date: 2022-04-04 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/archive/id/draft-li-lsr-droid-00.txt > Status: https://datatracker.ietf.org/doc/draft-li-lsr-droid/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-li-lsr-droid > > > Abstract: > Over time, the routing protocols have been burdended with the > responsiblity of carrying a variety of information that is not > directly relevant to their mission. This includes VPN parameters, > configuration information, and capability data. All of the > additional data impacts the performance and stability of the routing > protocols negatively. > > This has been convenient since the backbone of a routing protocol is > a small distributed database of routing information. Any service > needing a distributed database has considered injecting its data into > a routing protocol so that it can leverage the protocols database > service. Architecturally, this is a mistake that puts the protocol > at risk from undue complexity and overhead. > > To avoid this, DROID is a subsystem that is tangential to, but > independent of the routing protocols, and provides distributed > database services for other routing services. It is based on the > publish-subscribe (pub/sub) architecture and is intentionally crafted > to be an open mechanism for the transport of ancillary data. > > > > > The IETF Secretariat > > > > _______________________________________________ > 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
