On 4/13/16, 4:14 PM, "OSPF on behalf of Paul Jakma" <[email protected] on behalf of [email protected]> wrote:
[Speaking as WG participant and author of rfc6987.] Paul: Hi! You and I have had a similar conversation off-list... ... >I may have misinterpreted RFC6987, sure. > >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... 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). >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. Regards, Alvaro. _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
