Hi,
I just noticed this draft, and I would like to refer to
https://datatracker.ietf.org/doc/html/rfc8042 "OSPF Two-Part Metric".
If this has been discussed before, please point me to an existing email thread.
It seems that in the LAN case, the two-part metric mechanism would work better.
+--------+
| R0 |
| Router |
+--------+ +--------+
(a) Physical ^ ^ ^ (b) Layer-3 | R0 |
Topology | | | Topology +--------+
v v v ^ ^ ^
+----------------+ | | |
| Layer 2 Switch | | | |
| (Aggregation) | +---+ | +---+
+----------------+ | | |
^^ ^ ^ ^ ^ ^ v | v
|| | | | | | +------+ | +------+
+----+| | | | | | | R1 | | | R3 |
| +---+ | | | | +----+ +------+ | +------+
v v v v v v v v
+--------+ +--------+ +--------+ +--------+
| R1 | | R2 | | R3 | | R2 |
| Router | | Router | | Router | +--------+
+-- -----+ +--------+ +--------+
The reason is, when R1's link to the switch goes up/down, the reverse metric
from R0 to R1 is not only determined by R1 itself - it depends on the capacity
between R0 and the switch as well. The two-part metric mechanism handles that
well - each router advertises its metric to/from the "network", and the R0->R1
metric is the sum of the R0-network and network-R1 metric.
It would be good for this draft to clarify its use in LAN and compare with the
two-part-metric mechanism.
Thanks.
Jeffrey
Juniper Business Use Only
From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 7, 2022 3:18 PM
To: [email protected]
Cc: [email protected]
Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric -
"OSPF Reverse Metric"
[External Email. Be cautious of content]
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