Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

["Acee Lindem (acee)" <[e-mail]>]

Hi Ketan, Alvaro,

From: Ketan Talaulikar <[e-mail]>
Date: Thursday, October 6, 2022 at 8:10 AM
To: Alvaro Retana <[e-mail]>
Cc: Martin Duke <[e-mail]>, "[e-mail]" <[e-mail]>, Christian Hopps <[e-mail]>, Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

Hi Alvaro,

Please check inline below for response with KT2.

On Thu, Oct 6, 2022 at 4:42 PM Alvaro Retana <[e-mail]<mailto:[e-mail]>> wrote:
On October 6, 2022 at 5:44:57 AM, Ketan Talaulikar wrote:


Ketan:

Hi!


...
> KT> Added text in the security considerations that cover this issue as well
> as a proposed mitigation. Please let us know if that works.

This is the text that you added:

   A router that is misbehaving or misconfigured, may end up signaling
   varying values of reserve metrics or toggle the state of reserve
   metric.  This can result in a neighbor router having to frequently
   update its Router LSA causing network churn and instability despite
   the LSA rate-limiting behavior in the OSPF protocol.  It is
   RECOMMENDED that implementations support the detection of frequent
   changes in reverse metric signaling and ignore the reserve metric
   (i.e., revert to using their provisioned metric value) during such
   conditions.


Monitoring the changes is the right mitigation.  But the description
of how it would be done is not specific -- for a normative
recommendation.

As I think about this, it occurs to me that even though the originator
of the RM is not sending an LSA, this is an "IGP event", as described
in rfc8405.  Receiving the RM should trigger an SPF and the updated
Router LSA should also trigger SPF events elsewhere.

   IGP event: The reception or origination of an IGP LSDB change
   requiring a new routing table computation.  Some examples are a
   topology change, a prefix change, and a metric change on a link or
   prefix.  Note that locally triggering a routing table computation is
   not considered an IGP event since other IGP routers are unaware of
   this occurrence.


The same back-off mechanism from rfc8405 should be required in this case.

KT2> Indeed I was referencing RFC8405 but indirectly. Let us get into the details. The reception of RM changes the operational value of its local link metric. However, this MUST NOT be seen as an IGP Event that directly triggers the SPF on the neighbor. What needs to happen is that this metric change should trigger an update of the Router LSA (which is subject to rate-limiting - MinLSInterval). This Router LSA change would then be the one that triggers the SPF event subject to the back-off and details in RFC8405. This is the base protocol behavior - we are not changing anything here. Directly triggering local SPF on RM changes can result in aggravating microloops.

I agree with Ketan. This behavior doesn’t need to be respecified and explicit specification is most likely missing from existing RFCs for protocols mechanisms modify LSAs.

Thanks,
Acee

KT2> The recommendation was to ignore RM - i.e., suspend the RM feature during instability and revert to using the provisioned metric.

Thanks,
Ketan



Thanks!

Alvaro.