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

Reply via email to