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 <[email protected]> On Behalf Of Tony Li
Sent: Monday, April 4, 2022 9:48 AM
To: lsr <[email protected]>
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: [email protected]<mailto:[email protected]>
Subject: New Version Notification for draft-li-lsr-droid-00.txt
Date: April 4, 2022 at 9:43:57 AM PDT
To: "Tony Li" <[email protected]<mailto:[email protected]>>
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
