Subject: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt

From: Tony Li <[email-masked]>
Date: Mon, 4 Apr 2022 09:47:45 -0700

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-masked]
> 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-masked]>
> 
> 
> 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
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Apr 2022 21:52:12 +0200

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 <[email-masked]> wrote:

> 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-masked]
> *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-masked]>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Apr 2022 20:13:44 +0000

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-masked]> On Behalf Of Tony Li
Sent: Monday, April 4, 2022 9:48 AM
To: lsr <[email-masked]>
Subject: [Lsr] Fwd: New Version Notification for draft-li-lsr-droid-00.txt

Hi all,

Comments?

Tony

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>>

Name:                draft-li-lsr-droid
Revision:           00

Abstract:

The IETF Secretariat

---

From: Tony Li <[email-masked]>
Date: Mon, 4 Apr 2022 14:11:18 -0700

Hi Robert,

> Very happy to see this draft. 

Thanks.

> First question - the draft seems to be focusing on hierarchical IGPs and is clearly driven by liveness propagation discussion. 

The main problem in networking is scale. If you haven’t dealt with scale, you haven’t solved the problem. The way that we deal with scale is to install hierarchy. Thus, if you don’t have hiearchy, you don’t have a scalable network.

Single level networks are simply degenerate cases of hierarchical networks and should be dealt with as such.  Pick two routers.  Make them L1L2.  Poof, all done.

> 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 ? 

No, since it’s not necessary.  :)

If you would like to see alternate text, please feel free to propose.

> 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 ? 

I’m not sure that I parse this correctly.  Yes, you’re welcome to use DROID without worrying about liveness.  That’s one use case and it’s not mandatory.

> 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. 

Yes, but TCP/QUIC anycast is not quite as reliable as I would like.  I prefer simple redundancy. :-)

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 4 Apr 2022 14:20:38 -0700

Les,

> Nice acronym. 😊

Thank you. I blame the wordle craze. :)

> 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 go…

This is well known and does not need restatement.  :)

> Stuff directly used by the protocol
> TE related stuff (e.g., PCE)
>  

And that’s not what I was suggesting.

I am NOT suggesting we move anything that is currently defined, regardless of whether it is appropriate or not.  I would simply like to avoid forthcoming atrocities.

> 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…

Well, we can continue to disagree.

I was, in fact, thinking of the slew of capabilities that are about to be proposed for the MPLS MNA work.  I know of about ten new capabilities just from that direction.

>  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 Capabiliti…

Yup. One small sin to prevent a host of subsequent sins.

> This is unjustifiable IMO – please remove it.

I will be happy to do as soon as there is a working service discovery protocol.  But I’m not holding my breath.  Until then this is expedient.

> Where are you headed with this?

The LSR chairs have said that this is an appropriate home for now. There is no point in discussing this.  Nothing has changed.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Apr 2022 23:32:45 +0200

Hi Tony,

Just two follow up points,

#1 - I can't stop the feeling that DROID is very IGP centric and not
generic enough. Do you think we need DROID-2 to start offloading BGP or at
least stop trashing it ? Or you think that DROID as proposed could take on
day one flowspec v2 with its various extensions as example ?

#2 - When I mentioned anycast I meant not in the view of anycast redundancy
- too many issues with that. I meant just as session/service
bootstrapping then falling into dedicated pair of IPs. Simple redundancy
could be still easy with two such domain wide addresses.

Thx,
Robert.

On Mon, Apr 4, 2022 at 11:11 PM Tony Li <[email-masked]> wrote:

> > First question - the draft seems to be focusing on hierarchical IGPs and
> is clearly driven by liveness propagation discussion.
>
>
> The main problem in networking is scale. If you haven’t dealt with scale,
> you haven’t solved the problem. The way that we deal with scale is to
> install hierarchy. Thus, if you don’t have hiearchy, you don’t have a
> scalable network.
>
> Single level networks are simply degenerate cases of hierarchical networks
> and should be dealt with as such.  Pick two routers.  Make them L1L2.
> Poof, all done.
>
>
> > 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 ?
>
>
> I’m not sure that I parse this correctly.  Yes, you’re welcome to use
> DROID without worrying about liveness.  That’s one use case and it’s not
> mandatory.
>
>
> > 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

---

From: Tony Li <[email-masked]>
Date: Mon, 4 Apr 2022 14:37:42 -0700

Hi Robert,

> #1 - I can't stop the feeling that DROID is very IGP centric and not generic enough. Do you think we need DROID-2 to start offloading BGP or at least stop trashing it ? Or you think that DROID as proposed could take on day one flowspec v2 with its various extensions as example ? 
> 
> #2 - When I mentioned anycast I meant not in the view of anycast redundancy - too many issues with that. I meant just as session/service bootstrapping then falling into dedicated pair of IPs. Simple redundancy could be still easy with two such domain wide addresses. 

The only thing about DROID that’s tied to the IGP at this point is service discovery, as Les points out.  AFAIK, we still don’t have an effective, domain-wide service discovery mechanism. I agree that that’s a problem, but I’m not about to wait for that to get deployed. :)

Yes, you could use two domain-wide addresses, if there was a good way of distributing those.  We don’t have one. See above.

T

---

From: Tony Li <[email-masked]>
Date: Mon, 4 Apr 2022 23:04:10 -0700

Hi Robert,

>> Or you think that DROID as proposed could take on day one flowspec v2 with its various extensions as example ? 

I realized I did not answer this explicitly.  

DROID aspires to be completely generic. If it can be encoded in bytes, then there’s no reason that it can’t go in DROID.  Flowspec v2 is certainly within scope.

T