Hi Alvaro,
On Thu, 14 Apr 2016, Alvaro Retana (aretana) wrote:
Paul:
Hi!
You and I have had a similar conversation off-list...
Indeed, thanks for your help there. ;)
However, it is a fact that the behaviour desired by RFC6987 can be
universally achieved with metrics of 0xfffe or lower. That was true
before any misinterpretation, and is still true now.
Both MaxLinkMetric and 0xfffe are "very large numbers" (VLN), which
means that if we use 0xfffe, or any other VLN (including
MaxLinkMetric), then we should get "the same" behavior.
I wrote ""the same"" because the result can vary depending on which
VLN a router in the network uses with respect to another router that
may also want to be a stub. For example, given 2 paths to a
destination, if a router uses 0xfffe (or any other VLN which is not
MaxLinkMetric) it should become a stub. However, if a router on the
second path decides to use MaxLinkMetric, then the first one (the one
using 0xfffe) will become transit. We can obviously expand that
example to n number of links and n values of VLN and end up with a
wide variety of results -- which will not be deterministic unless we
know which VLN each router used in each case...
Indeed.
However, this can happen with consistent use of 0xffff too. If both are
0xffff, then a 3rd party router can still choose /either/ to route via,
or both. Etc.
So, whether a router will or will not be used for transit will depend on
the network topology, when a "transit is still OK" approach is still
used.
Also, this does not take the original link-metric into account either,
right? It could be that the links on the one path originally were 100
the other 1000. Clearly, if both now go stub, you'd want 3rd parties to
prefer the "originally 100" one, but that information is lost.
So, if this were a consideration, wouldn't it be better to do
stub-router with a "Add X to existing cost of all the links" approach?
Where X is larger than the largest path cost, but less than the
difference to 0xffff?
When we originally wrote rfc3137 (the precursor of rfc6987), we chose
MaxLinkMetric because it guarantees the stub behavior (no other VLN is
higher), unless an alternate path does not exist. Clearly we took
advantage of how the metric is treated in the current OSPF
specification (starting with rfc1583). If we has used 0xfffe (or any
other VLN) then the behavior wouldn't have been guaranteed (using the
current OSPF spec).
Ah, ok.
Though, you didn't want to guarantee a router wouldn't be used... and as
above judging the cost of alternate paths gets tricky with... Anyway. ;)
0xffff today will not universally be recognised as meaning "you can
still calculate transit paths out of a router using that link".
0xfffe or below will.
That is the reality today.
True, but only for pre-rfc1583 routers.
Well, Quagga has treated 0xffff links as infinite / strictly-no-transit
out of a vertex for 9 years now.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"I don't think they could put him in a mental hospital. On the other
hand, if he were already in, I don't think they'd let him out."
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
