Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt
Tony – Nice acronym. As regards the original use case (Node Liveness), my opinion hasn’t changed. Repackaging this in a more generic wrapper (which makes sense to me) doesn’t alter my opinion – which is this isn’t a good way to go. As regards the new use case (Capabilities), I think what you state as historical behavior isn’t accurate. If you look at the existing sub-TLVs for Router Capability, the information falls into two categories: * Stuff directly used by the protocol * TE related stuff (e.g., PCE) I would oppose any attempt to move stuff directly used by the protocol out of Router Capability and force the IGP to get this info from some application. Which leaves stuff NOT used by the IGP. The only existing example which “might” fall into this category is: S-BFD Discriminators – which we stuck into the IGP for lack of a better place. I therefore think your language regarding what is/is not a good candidate for DROID capability advertisement needs refinement. As written, it suggests that there are lots of existing cases that are being advertised by the IGP inappropriately – which I do not think is the case. I also think that asking the IGP to advertise the location(s) of DROID is an abuse of the IGP – the very thing that you have argued should not be done. The IGP – and specifically Router Capabilities – is not intended to serve as a form of DNS – advertising the location of application services in the network. It is ironic to me – given that you have framed DROID as motivated by “anti-IGP-as-a-dumptruck” – that you would then abuse the IGP by asking it to advertise the location of DROID. It opens the door to others who want the IGPs to advertise application stuff – but when that is rejected by LSR WG (as it should be) they say “OK – but can we advertise the identity of a place to get the info in Router Capabilities?”. This is unjustifiable IMO – please remove it. Finally, there is the question of where such a draft belongs. LSR seems like the wrong place. Where are you headed with this? Les From: Lsr On Behalf Of Tony Li Sent: Monday, April 4, 2022 9:48 AM To: lsr Subject: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt 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<mailto: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" mailto: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
Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt
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 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" > > > 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
[Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt
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" > > > 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
