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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2022 17:09:29 +0000

Speaking as WG member and document shepherd:

I support publication of this draft. IS-IS has had this capability for some time now and we need it in OSPF. The technical aspects of the draft are sound.

One detail that I think needs to be added is the stub link metric corresponding to the link is not modified by acceptance of the reverse metric. At least this is my understanding and opinion.

I also have some comments on the readability. I’ve attempted to correct these in the attached diff (there may be mistakes as I did this editing quickly).

  1.  I don’t like the “to itself” terminology. I know what it mean since I’ve seen both the OSPF and IS-IS presentations on the feature. This constitutes most of my suggested changes.
  2.  Avoid run-on sentences like the one at the end of section 2.
  3.  I don’t think “use case” should be hyphenated.
  4.  Should we really refer to “statically provisioned metrics” when in many case reference bandwidth is used?
  5.  Some other editorial changes.

Anyway, you can use your best judgement on these.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Thursday, April 7, 2022 at 3:18 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 14 Apr 2022 10:39:50 +0530

Hi Acee,

Thanks a lot for your detailed review and your suggestions. We will be
incorporating them in the next update.

Please also check inline below for further responses.

On Wed, Apr 13, 2022 at 10:39 PM Acee Lindem (acee) <[email-masked]> wrote:

> I support publication of this draft. IS-IS has had this capability for
> some time now and we need it in OSPF. The technical aspects of the draft
> are sound.
>
>
>
> One detail that I think needs to be added is the stub link metric
> corresponding to the link is not modified by acceptance of the reverse
> metric. At least this is my understanding and opinion.
>

KT> That is correct. The draft talks about router links (thanks for that
suggestion) and does not cover stub links since there are no neighbors on
those links to signal the RM in the first place.

>
>
> I also have some comments on the readability. I’ve attempted to correct
> these in the attached diff (there may be mistakes as I did this editing
> quickly).
>
>
>
>    1. I don’t like the “to itself” terminology. I know what it mean since
>    I’ve seen both the OSPF and IS-IS presentations on the feature. This
>    constitutes most of my suggested changes.
> KT> Ack to all of the above.

>
>    1. Should we really refer to “statically provisioned metrics” when in
>    many case reference bandwidth is used?
>
> KT> Changed to "provisioned metric" to cover both scenarios where metric
value is specified or derived via specified reference bandwidth
configuration.

Thanks,
Ketan

>
>    1.
>    2. Some other editorial changes.
>
>
>
> *From: *Lsr <[email-masked]> on behalf of "Acee Lindem (acee)"
> <acee=[email-masked]>
> *Date: *Thursday, April 7, 2022 at 3:18 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>
> *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
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 Apr 2022 02:17:04 -0400

Hi Ketan

I reviewed the draft and support publication.

Can you add the two use cases in ISIS RM RFC 8500 about LDP IGP
synchronization and the DC lead to spine scenario where the spine had links
down or congestion.

Kind Regards

Gyan

On Thu, Apr 14, 2022 at 1:10 AM Ketan Talaulikar <[email-masked]>
wrote:

>>    1. I don’t like the “to itself” terminology. I know what it mean
>>    since I’ve seen both the OSPF and IS-IS presentations on the feature. This
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 14 Apr 2022 12:34:14 +0530

Hi Gyan,

Thanks for your review and feedback. Please check inline below.

> synchronization and the DC lead to spine scenario where the spine had links

KT> The LDP IGP synchronization use case in RFC8500 is related to LAN
environments and addressed by OSPF Two-Part Metric RFC8042. So it is out of
the scope of this draft. The DC spine/leaf use case in RFC8500 is very
similar to what is already covered by Sec 2.2. Also, note that the RFC8500
Spine Leaf Sec 1.3 references draft-ietf-lsr-isis-spine-leaf-ext and is not
applicable for OSPF.

Thanks,
Ketan

>>>    1. Should we really refer to “statically provisioned metrics” when
>>>    in many case reference bandwidth is used?
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Apr 2022 19:38:55 -0400

Hi Ketan

Welcome.

Responses in-line

Kind Regards

Gyan

> Spine Leaf Sec 1.3 references draft-ietf-lsr-isis-spine-leaf-ext and is not

    Gyan> LDP - IGP synchronization has to do with the MPLS data plane
convergence and is independent of network type broadcast or point-to-point
but is generally used for /31 or /127 P2P networks were the IGP metric is
set to “max metric” until the LDP comes up and can be further delayed in
second “ ldp igp sync delay x” to prevent the IGP from black hole of
traffic until LDP control plane state is Up at which time the IGP max
metric is unset back to its original metric and traffic can be converged
back onto the link.  LDP-IGP synchronization and sync delay implementation
CLI knob is critical for MPLS data plane operation.  The RFC 8042 two part
metric has a use case for router/satellite and router/terminal use cases
which I can’t see how that would apply to LDP-IGP sync.  The reverse metric
completely makes sense as the max metric would be advertised to override
the configured metric and then would get unset to original metric when LDP
comes Up.

>>>> KT> Changed to "provisioned metric" to cover both scenarios where
>>> metric value is specified or derived via specified reference bandwidth
>>> configuration.
>>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>>
>>>>
>>>>    1.

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Sun, 17 Apr 2022 22:20:51 +0530

Hi Gyan,

Perhaps I am not able to parse your email well.

1) The LDP-IGP sync is something already implemented and supported widely
and is not the subject of this draft. Especially related to p2p link
operations, is there anything that needs the reverse metric?

2) This draft does not apply to LAN interfaces - that functionality is
provided by RFC8042.

So I am not sure that I follow what is it that you are proposing to be
added to the OSPF reverse metric draft that is related to IGP-LDP sync. Can
you please explain or better still, propose text?

Thanks,
Ketan

On Sun, Apr 17, 2022 at 5:09 AM Gyan Mishra <[email-masked]> wrote:

>>>> KT> That is correct. The draft talks about router links (thanks for
>>>> that suggestion) and does not cover stub links since there are no neighbors
>>>> on those links to signal the RM in the first place.
>>>>
>>>>
>>>>>
>>>>>
>>>>> I also have some comments on the readability. I’ve attempted to
>>>>> correct these in the attached diff (there may be mistakes as I did this
>>>>> editing quickly).
>>>>>
>>>>>
>>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 17 Apr 2022 21:24:31 -0400

Hi Ketan

I was mentioning the use case of LDP-IGP used in RFC 8500 for LAN use case
where with LDP-IGP sync all nodes on the LAN get set to max metric, however
with reverse metric optimization only on the  nodes pairs that require the
max metric get the reverse metric for outbound and inbound without
impacting all other nodes on the LAN.

So this would be an optimization to existing LDP-IGP sync which has been
around for decades.  All nodes that would receiving the reverse metric
would require upgrade to support the feature.

So this seems to be an important application of reverse metric for OSPF as
well.

1.4 <https://datatracker.ietf.org/doc/html/rfc8500#section-1.4>.  LDP
IGP Synchronization

   In [RFC5443 <https://datatracker.ietf.org/doc/html/rfc5443>], a
mechanism is described to achieve LDP IGP
   synchronization by using the maximum link metric value on the
   interface.  But in the case of a new IS-IS node joining the broadcast
   network (LAN), it is not optimal to change all the nodes on the LAN
   to the maximum link metric value, as described in [RFC6138
<https://datatracker.ietf.org/doc/html/rfc6138>].  In this
   case, the Reverse Metric can be used to discourage both outbound and
   inbound traffic without affecting the traffic of other IS-IS nodes on
   the LAN.

Thanks

Gyan

On Sun, Apr 17, 2022 at 12:51 PM Ketan Talaulikar <[email-masked]>
wrote:

>>>>>> I support publication of this draft. IS-IS has had this capability
>>>>>> for some time now and we need it in OSPF. The technical aspects of the
>>>>>> draft are sound.
>>>>>>
>>>>>>
>>>>>>
>>>>>>    1. Should we really refer to “statically provisioned metrics”
>>>>>>    when in many case reference bandwidth is used?
>>>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Ketan Talaulikar <[email-masked]>
Date: Mon, 18 Apr 2022 08:40:32 +0530

Hi Gyan,

As mentioned previously, the OSPF reverse metric mechanism is not
applicable for LAN (at least not proposed in this draft) since there is an
existing OSPF two-part metric mechanism RFC8042 for LANs.

Thanks,
Ketan

On Mon, Apr 18, 2022 at 6:54 AM Gyan Mishra <[email-masked]> wrote:

> 1.4 <https://datatracker.ietf.org/doc/html/rfc8500#section-1.4>.  LDP IGP Synchronization
>
>    In [RFC5443 <https://datatracker.ietf.org/doc/html/rfc5443>], a mechanism is described to achieve LDP IGP
>    to the maximum link metric value, as described in [RFC6138 <https://datatracker.ietf.org/doc/html/rfc6138>].  In this
>>>>> On Thu, Apr 14, 2022 at 1:10 AM Ketan Talaulikar <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> Hi Acee,
>>>>>>
>>>>>> Thanks a lot for your detailed review and your suggestions. We will
>>>>>> be incorporating them in the next update.
>>>>>>
>>>>>>> *From: *Lsr <[email-masked]> on behalf of "Acee Lindem
>>>>>>> (acee)" <acee=[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 17 Apr 2022 14:29:05 -0400

Understood. Thanks for the clarification.

Thanks Ketan

Gyan

On Sun, Apr 17, 2022 at 11:10 PM Ketan Talaulikar <[email-masked]>
wrote:

>> I was mentioning the use case of LDP-IGP used in RFC 8500 for LAN use
>> case where with LDP-IGP sync all nodes on the LAN get set to max metric,
>> however with reverse metric optimization only on the  nodes pairs that
>> require the max metric get the reverse metric for outbound and inbound
>> without impacting all other nodes on the LAN.
>>
>> So this seems to be an important application of reverse metric for OSPF
>> as well.
>>
>>> 1) The LDP-IGP sync is something already implemented and supported
>>> widely and is not the subject of this draft. Especially related to p2p link
>>>>>>>>    1. I don’t like the “to itself” terminology. I know what it
>>>>>>>>    mean since I’ve seen both the OSPF and IS-IS presentations on the feature.
>>>>>>>>    This constitutes most of my suggested changes.

-- 

*Gyan Mishra*

*M 301 502-1347*