How to enter static prefix with multiple nexthops but no ECMP?

[Kenth Eriksson]

On Thu, 2019-10-17 at 12:14 +0200, Ondrej Zajicek wrote:
> On Wed, Oct 16, 2019 at 02:52:10PM +0000, Kenth Eriksson wrote:
> > On Wed, 2019-10-16 at 16:43 +0200, Ondrej Zajicek wrote:
> > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> > > 
> > > 
> > > On Wed, Oct 16, 2019 at 01:41:45PM +0000, Kenth Eriksson wrote:
> > > > Hi!
> > > > 
> > > > Does bird support a static prefix with multiple nexthops, without
> > > > installing all of them in the kernel as ECMP?
> > > 
> > > Hi
> > > 
> > > I think that you are talking about multiple routes/paths with the same
> > > prefix. Static protocol currently does not support that (and behaves
> > > strangely when such multiple routes are defined). Simple workaround
> > > is to define multple static protocol instances. We have a patch for
> > > multiple static routes with the same prefix and different preference
> > > in one static protocol (commit 9861dba5230da539e6ce7d2b6baa4f2631556d09),
> > > but we plan to rewrite that significantly before merging to master.
> > > 
> > 
> > Ok, thanks for clarifying that. What is the target release for that
> > feature?
> 
> Probably something like 2.0.8-9.
> 
> The design of our protocol-table interface requires that if i have
> multiple routes with the same networks, there must be an u32 value
> that distinguishes them (that is inspired by BGP ADD-PATH design).
> 
> In the patch above we used preference for this distinguisher, but later
> we got some feedback that it may be more useful to have IGP-comparable
> metric (i.e. igp_metric attribute) for this (so multiple routes with
> the same preference and different igp_metric can be used). Another
> possibility is to have separate 'id' argument for distinguisher unrelated
> to any real attribute, but that may be inconvenient for users. Yet another
> possibility is to have some automatic 'id' assignment based on all static
> route attribute through hash table, but that seems like a too much /
> unnecessary work.
> 

So then the key for static routes would be the tuple {net, preference,
igp_metric}? Or is also nexthop part of the key? The igp_metric could
be useful, but for our current use case a preference value with local
significance would be sufficient. 

Another desirable change for static routes is that they should show up
in the RIB. Current design does not important all static routes into
the RIB, but instead may set the dormant flag on them. 


> So i would like to get some feedback w.r.t. that.
>