On Wed, 13 Apr 2016, Acee Lindem (acee) wrote:
One of the authors or myself will write an errata to clarify this
definition.
Great. :)
But the OSPF stub router functionality is achieved using 0xffff, so
your proposal is NOT backward compatible.
Why not?
Any sufficiently large metric (relative to the cost of the longest path
in the network) will induce the desired "transit is still fine"
behaviour in the stub-router RFC.
It turns out the 0xffff metric was never intended to be special by that
RFC - or we wouldn't be having this discussion. It _not_ intended to
change SPF behaviour. So, how could using a lower value cause
compatibility issues? ??
The reality is that the standards WILL NOT change to match your
interpretation.
Well, not asking you to. ;)
I'm just saying Quagga has been shipping for years with "0xffff link
metric means its SPF will not follow such a link out of a router when
calculating the SPF tree" behaviour. The reason was provide the
"absolutely no-transit" type behaviour (as "discouraged, but transit is
still OK" behaviour is achievable with many other metrics).
I'm not arguing for anything, I'm just saying the existence of such
implementations is a reality.
For Quagga, it seems the best way forward is:
- As/when H-bit clearly is going to be a standard, Quagga can use H-bit
+ 0xffff link metrics to signal "absolutely no transit", when the
administrator desires that behaviour.
* This will have the desired effect with all routers that recognise
the H-bit, and all Quagga
- If the administrator wants "discourage, but transit still OK" then
Quagga will just set some large, non-0xffff metric in the links (e.g.
0xfffe).
* This will have the desired effect with all routers, Quagga old and
new, RFC2328, pre-1583, etc., without any issues (AFAIK).
That seems the best thing we can do.
It leaves other cases where things might not quite be consistent. For
those there'll be an admin option to control the SPF-0xffff-transit
behaviour between the longish-standing Quagga "no-transit" behaviour and
1583/2328. That will probably have to default to the "no-transit"
behaviour for a while longer, but in time hopefully flip it over to
2328.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Given sufficient time, what you put off doing today will get done by itself.
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
