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

Ketan Talaulikar <> Thu, 06 October 2022 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A041FC14F720; Thu, 6 Oct 2022 05:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVvCp5W7exXg; Thu, 6 Oct 2022 05:10:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7AB43C14F741; Thu, 6 Oct 2022 05:10:03 -0700 (PDT)
Received: by with SMTP id f129so1070303vsc.7; Thu, 06 Oct 2022 05:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=+HDT+f8tKdBNP9TialfxovU/KQTcs/9dRS1L3aH8TK0=; b=OIiJD8uJ0oTiSPDjubmKHd1c0Ea0lXD1/NSiH5+MrLYjkgtHti6R0KsukK3fokUgTE GHEIKxeCi6oP84fOuABT2ud8Ejn0GjjqHpwbTIYsgYGJvLPmH26EhsVRe72fDRx20PTP epIOPusXjRnx/yzp5ochUi/zfVKAfIFCsjf2JoJoWksWWkV0zHX00MyI8LR8fqGCTCGu PNB0r+xCDY5HIebnY+S0ou2FDCYiG8PFrn75626Qrl5SluUOMJqReBpka4s+4Q4b8gc+ 6ah26OK59tLSskSncfcSENn6HsgQmOZXFOgy8h3xPJd0I2TN6AD8iqPgA3v9fgJgYwds gxvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=+HDT+f8tKdBNP9TialfxovU/KQTcs/9dRS1L3aH8TK0=; b=1qAz9dlATzFFyWsPOoVH7fvsGC2+pfGi3SBUN7GQHhrtf4FG7lnpi6Fuq0+Z4CiMZ4 N3SSZ1zYzjKGMMfZW6iMou9r8JZz2M+cNf4btKHwa8ZosqWHEXirCd5BLTrPt0OwFv2V pM0QHZUHXNgBdzq6hHienMX30g3Td6r7ASilUHsEVUorg9dS7CcS2yL6MAmT/D8o0650 6zc09081PhVXLrOlApDjPJw9oiTnfOF5UdboE2XENTalHVVAsK6M2Ujy+7GLOg4pkR9D NIasH5Fn7898ZLR6qrsVKgkL4s17U9NvCWEZpnOun6bL+kDeFifv2ylbf3gdZzgFk5vi jVkQ==
X-Gm-Message-State: ACrzQf1XT8442MpC2mvLJ8ZjEPFHi+646+Di5thYSzoY/A5cVnX6zifd 8XSwE/bH7R/l+TsDTHeJYMzvcPWWx9U0GEJTZT9CQlz2E7U=
X-Google-Smtp-Source: AMsMyM5ok7Ny+aF6KZ030ko01ydNCcaEKDSkCgAhoCi98xZZ065prRfScS76qlcSSo68bTjYyaTt9t1gETnl6R6NYTE=
X-Received: by 2002:a67:c11d:0:b0:3a6:f3c5:a706 with SMTP id d29-20020a67c11d000000b003a6f3c5a706mr1187295vsj.64.1665058202241; Thu, 06 Oct 2022 05:10:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ketan Talaulikar <>
Date: Thu, 06 Oct 2022 17:39:50 +0530
Message-ID: <>
To: Alvaro Retana <>
Cc: Martin Duke <>,,,,, The IESG <>,
Content-Type: multipart/alternative; boundary="000000000000accc9905ea5c92d3"
Archived-At: <>
Subject: Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Oct 2022 12:10:05 -0000

Hi Alvaro,

Please check inline below for response with KT2.

On Thu, Oct 6, 2022 at 4:42 PM Alvaro Retana <> 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

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


> Thanks!
> Alvaro.