<div dir="auto">That is correct, it will not be compatible with other OSPF implementations.<div dir="auto"><br></div><div dir="auto">From what I've searched, there is no standard for supporting SADR in OSPF, only some IETF drafts (some of which expired) that describe the desired behavior.<div dir="auto"><br><div dir="auto">One or two of these drafts plan to use OSPF extended LSAs to support SADR, but the extended LSAs are also still drafts, and I am not sure they would cooperate with the current ospf standard.</div><div dir="auto"><br></div><div dir="auto">So yes, the design details are mine, but they are based on the OSPF behavior specified in these documents.</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 Mar 2017 11:41, "Toke Høiland-Jørgensen" <<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dean Luga <<a href="mailto:dluga93@gmail.com">dluga93@gmail.com</a>> writes:<br>
<br>
> I used the configure switch since SADR makes changes to the LSAs and<br>
> it will slightly impact network traffic even with source 0::/0. If<br>
> someone doesn't want that, they can disable it.<br>
<br>
As in, when you enable SADR all routes announced now carry a SADR? Does<br>
that mean bird with SADR enabled will no longer compatible with an OSPF<br>
implementation that does not understand? And if so, is this inherent in<br>
the OSPF SADR extension, or is this a design choice of your<br>
implementation?<br>
<br>
-Toke<br>
</blockquote></div></div>