Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Apr 2022 19:17:33 +0000

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 13 Apr 2022 13:48:08 +0000

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-masked]> On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 7, 2022 3:18 PM
To: [email-masked]
Cc: [email-masked]
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

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 13 Apr 2022 19:36:04 +0530

Hi Jeffrey,

Could you grep for RFC8042 in this draft and then let us know what more is
needed?

Thanks,
Ketan

On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> Hi,
>
>
>
> I just noticed this draft, and I would like to refer to
> https://datatracker.ietf.org/doc/html/rfc8042 “OSPF Two-Part Metric”.
>
> 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.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, April 7, 2022 3:18 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *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
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 13 Apr 2022 18:43:07 +0000

Hi Ketan,

My fault. When I initially grepped for it, I used “8402” instead of “8042” and did not find it hence the comment ☹
Sorry about that.

Jeffrey

Juniper Business Use Only
From: Ketan Talaulikar <[email-masked]>
Sent: Wednesday, April 13, 2022 10:06 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

Hi Jeffrey,

Could you grep for RFC8042 in this draft and then let us know what more is needed?

Thanks,
Ketan

On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I just noticed this draft, and I would like to refer to https://datatracker.ietf.org/doc/html/rfc8042<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8042__;!!NEt6yMaO-gk!RPUE_VAZZzupPzS38nxXHMUbqLbJRk0sAmgaPk6bQwszemzqwH1ULDh1bF2rLV6x$> “OSPF Two-Part Metric”.
If this has been discussed before, please point me to an existing email thread.

                +--------+
                |   R0   |
                | 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.

Thanks.
Jeffrey

Juniper Business Use Only
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Thursday, April 7, 2022 3:18 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] Working Group Last Call for draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"

Thanks,
Acee

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 14 Apr 2022 08:58:01 +0530

Hi Jeffrey,

Thanks for confirming that we are ok with this draft's relationship with
RFC8042.

Thanks,
Ketan

On Thu, Apr 14, 2022 at 12:13 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *From:* Ketan Talaulikar <[email-masked]>
> *Sent:* Wednesday, April 13, 2022 10:06 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Acee Lindem (acee) <acee=[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: Working Group Last Call for
> On Wed, Apr 13, 2022 at 7:18 PM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> Hi,
>
>
>
> https://datatracker.ietf.org/doc/html/rfc8042
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8042__;!!NEt6yMaO-gk!RPUE_VAZZzupPzS38nxXHMUbqLbJRk0sAmgaPk6bQwszemzqwH1ULDh1bF2rLV6x$>
> “OSPF Two-Part Metric”.
>