I support progressing this draft.
However, I have some concerns about the current content – specifically the use
cases – which I would like to see addressed before going to Last Call.
The equivalent functionality is defined in RFC 8500 for IS-IS and has proven
useful – make sense to also have it for OSPF.
But the primary use case discussed in RFC 8500 is during maintenance – which is
discussed extensively and is mentioned as the first use case.
In the case of draft-ietf-lsr-ospf-reverse-metric, the maintenance use case is
not even mentioned.
Of the two use cases that are mentioned, the one in Section 2.1 has many
limitations and constraints. These include:
* Only works when there is a switch in the middle – something which the
protocol is not able to detect
* Only works in the presence of symmetrical metrics
* If both neighbors have L2 bundles to the switch and are both doing
auto-cost adjustment based on the number of members currently up, the mechanism
doesn’t work
* Detecting symmetrical metrics in the presence of reverse metric is
problematical. Is the neighbor cost including the reverse metric or does it
reflect something else (e.g., config change on the neighbor)
I would prefer that this use case be removed. If not, a more complete
discussion of the limitations should be included.
In summary, before progressing this draft I would like to see maintenance
included as the primary use case and the use case described in Section 2.1
removed.
Les
From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 7, 2022 12:18 PM
To: [email protected]
Cc: [email protected]
Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric -
"OSPF Reverse Metric"
This begins a Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric.
While there hasn’t been as much discussion as I would like on the draft, it is
filling a gap in OSPF corresponding to IS-IS Reverse Metric (RFC 8500). Please
review and send your comments, support, or objection to this list before 12 AM
UTC on April 22nd, 2022.
Thanks,
Acee
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
