On Thu, 17 Mar 2016, Don Slice wrote:
Since both of these are informational rather than standards track, is
it a safe bet to operate as these two describe when there are
potential known bad side-effects? The Deployment considerations
section of RFC6987 states that inconsistent results could be seen in a
mixed environment (though it also incorrectly states that routing
loops cannot occur.) Do we know how many OSPF implementations default
to operating in RFC2328 vs RFC6987?
I don't know.
I don't mind going to 'relaxed', though I can imagine it is useful to
have both:
- "Don't route toward that router for transit at all"
and
- "Don't route toward that router, if possible"
E.g., for graceful-shutdown, the former is useful. You can set
max-metric, and all through-traffic should quickly disappear. You can
keep OSPF up (adjacencies up, etc). If anything breaks, you can also
quickly reverse it.
With the latter, stuff you didn't realise was going to break, will keep
working. Only when OSPF is truly down will you find out what breaks -
by which point your box may be shutting down.
For me, I prefer the former - I want to know about the breakage before I
/really/ take the router down. I didn't realise there were people who
prefer the latter.
If it were down to me, I would have the 2nd way be more of a "add X to
/all/ link-costs" TE type command, that feels conceptually more correct.
Though, presumably other implementations default to that for the
"stub-router" support..
Anyawy... Hmm.
regards,
--
Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A
Fortune:
An optimist is a guy that has never had much experience.
-- Don Marquis
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
