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

[Kenth Eriksson]

On Mon, 2020-05-25 at 23:04 +0200, Ondrej Zajicek wrote:
> > Tried a small interop by loading bird 2.0.4 on node 2 and Quagga
> > 0.99.11 on node 3 (the Quagga build has the unnumbered patch mentioned
> > by Jocke). Results looks correct as far as I can tell.
> > 
> > Seems like that patch is also part of FRR;
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFRRouting%2Ffrr%2Fcommit%2Fc81ee5c94f&data=02%7C01%7CKenth.Eriksson%40infinera.com%7C630dfc1f3cd542e6263408d800ef4369%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637260374926746579&sdata=B%2FjY%2Fi06o2Lzg0zAFE3WgBu5kBWApIGRnrzkPpUys2E%3D&reserved=0
> > 
> > And it still looks like at least the functions are there in latest FRR
> > 7.3.1.
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFRRouting%2Ffrr%2Fblob%2Ffrr-7.3.1%2Fospfd%2Fospf_interface.c%23L393&data=02%7C01%7CKenth.Eriksson%40infinera.com%7C630dfc1f3cd542e6263408d800ef4369%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637260374926746579&sdata=q3B2op7fe9f8e%2FL4WHw6TqroFtCE5gXi71V6QdtY88k%3D&reserved=0
> 
> Hi
> 
> Checked that. Seems like FRR uses the similar approach like BIRD 2.0.4,
> so that is OK. It also seems that FRR does not implement OSPF graceful
> restart, so they did not (yet) hit the same issue with Jocke's patch like
> we in 2.0.5.

The development of OSPF graceful restart in bird is a good first step.
But I believe most use cases would need unplanned GR. If you are
limited to a planned GR, you probably have a service window anyway.
 
> 
> > Haven't actually tested if this actually interops with bird.
> > 
> > The RFC states that unnumbered ptp links shall use ifIndex, whereas as
> > numbered ptp links shall use IP interface address. Any reason to not
> > follow the RFC?
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2328%23page-130&data=02%7C01%7CKenth.Eriksson%40infinera.com%7C630dfc1f3cd542e6263408d800ef4369%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637260374926746579&sdata=ELhNbVgkTrU4EOVzBsjESQSoPyiuWNs6QKPStsENC5M%3D&reserved=0
> 
> Well, i generally prefer not to make intentional changes that break
> existing setups, and switching to this (as done by the patch i sent)
> would break Mikrotik compatibility for unnumbered PtP links (due to
> Mikrotik broken SPF calculation).
> 
Not sure I agree the alternative is better. Violating standard to
maintain interoperability with a broken Mikrotik implementation. That
only makes sense if the Mikrotik way of doing it was de facto standard.
If not, drop compatibility.

> 
> > Ondrej, what are you plans for the patch provided? Good to go for
> > master?
> 
> Seems to me that perhaps the least painful solution is to use 2.0.4
> approach (position based) for regular OSPF, and switch to ifIndex/data
> based approach (like the patch) when OSPF graceful restart is enabled.

So does that mean that there is a bird interop issue for nodes running
with and without GR activated? 

> 
> So plan is to make a new/different patch for master.
> 
>