Unnumbered PtP links (Was: Re: OSPF: incorrect path computation for v2.0.5+?)

[Joakim Tjernlund]

On Fri, 2020-05-22 at 22:59 +0200, Ondrej Zajicek wrote:
> On Fri, May 22, 2020 at 07:14:44PM +0000, Kenth Eriksson wrote:
> > On Thu, 2020-05-21 at 12:43 +0200, Ondrej Zajicek wrote:
> > > This patch should fix the issue, could you try it?
> > 
> > Looks promising, applied on top of 2.0.7, and a quick test on the 5
> > node setup looks correct. Will do some more testing.
> > 
> > We definitely need this fix in the pending 2.0.8 :-)
> 
> This issue has a long history. In 2012, we changed data field for
> unnumbered PtP links from iface id (specified by RFC) to IP address based
> on reports of bugs in Quagga that required it, and we used out-of-band
> information to distinquish unnumberred PtPs with the same local IP
> address.
> 
> Then with OSPF graceful restart implementation, we found that we can no
> longer use out-of-band information, and we need to use only LSAdb info
> for routing table calculation, but i forgot to finish handling of this
> case, so multiple unnumbered PtPs with the same local IP addresses were
> broken.
> 
> This patch returned back iface id to data field for unnumbered PtP links
> (i.e. reverted back the change from 2012), while doing computation just
> from LSAdb info. It fixed your case (multiple unnumbered PtPs with the
> same local IP address) and is correct per RFC, but it may trigger bugs
> with other implementations (like the one that led to the 2012 change).

Not sure I follow here, have you done away with rt_pos_to_ifa() and friends now
and gone back to the old way? The old way had several drawbacks, one of them was this
dependency on interface ID. Does current impl. depend on a well behaved neighbor too?
Is it compatible with any other Bird release?

 Jocke