Re: [Lsr] Doubt regarding A bit set/clear

Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com> Fri, 23 April 2021 12:58 UTC

Return-Path: <gurusiddesh.nidasesi@ipinfusion.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448433A1C5B for <lsr@ietfa.amsl.com>; Fri, 23 Apr 2021 05:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: invalid data)" header.d=ipinfusion.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeQzjl4ST8YE for <lsr@ietfa.amsl.com>; Fri, 23 Apr 2021 05:58:45 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7693A1C57 for <lsr@ietf.org>; Fri, 23 Apr 2021 05:58:44 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id j4so37932814lfp.0 for <lsr@ietf.org>; Fri, 23 Apr 2021 05:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipinfusion.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wdl7fq8dZrgq4sHECgyH9bdFbjRzpd5RsyFE8bAIufs=; b=CaU8HK1KrqFZ5BEtlJ53fgUZJKwnpss80evGshMPD9rWUdqyA5PWfxczU3UGy1EXDG YINeobyNN6YUdEDr54JKPZ0oMOJaLSSHxz0vP7g62aR705bREgfnOrUoA7/rzYO/Wd4A njouVUrj+OQDtkrX2hadmfMdv3fPizVE6vGZPXeeNki9uzgqKsaadxJsUfi7kbHKasJM dWz6fWHBcgXUjIpktXv4aZbEG/e8oUYb/4hYxy6b9Iti3Vi96RoqZfhH+EhwJGNnn8g3 ZKsY7PuTG9TcqFB+L4qKO4mCiSp1pQ5WkacD8jKTLtNN2TqfsH3n42ViNNObq01jYE4j kB9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wdl7fq8dZrgq4sHECgyH9bdFbjRzpd5RsyFE8bAIufs=; b=ZPkrPQeeXiPsk+whljEc9bPWOdvW7e+s+jJ2KefzNXnREPBIvF+FqODzd4Xc2HDO48 Kpx9NcqRLuvXgXBJXZ2DNlZD1aBbts+OEojBtGGHB5702J9ONxUfI0ANSU9iDBM4gV0k cg/fzYIbh5buttRkbfBZ2FvmbrKmj3CVre02y/VllHjmlVorWdremEYAF8LO667esut7 3nyjxANh283nl0xpeCDNXAPeYZpJCMuYecA33xLCyjiYWR4iC9eIGvnmuMymqIYx/gKw NUtmjSkCSN3MWSwE4eHOa1ZuIsg9Z6wAWE2Gh25V6qA7+CmKtz2FjGBQvQpG5pAqQ1je zrXw==
X-Gm-Message-State: AOAM532Dh6FHLkry/6MTDa4wyAALc8nFbgkMoUIj6fmldU62FmWaSDSB 5D7OvBSpetSCkLWQ8ebzE5Aagy9yXraPIQhkM2ysynjEmJSWdT1J2rEojegzuQXSgjGUr7isRaz IxO9Z4nBM384iLbNw2RYqrD+ozZ0g+J0UjroASxS1jmGJm42TVwDAoWfu0cgvD94FmXI2N9lz+y owcK4JcVZCw1nG4SI=
X-Google-Smtp-Source: ABdhPJx+L4drF66IdyqaH0iTE/3JzOWaXACcA1TpR7Upozjwpt8atehEHTIpQqbR2VKu8dPZPZU+97wryim1NVvfpaQ=
X-Received: by 2002:ac2:5dd8:: with SMTP id x24mr2786321lfq.160.1619182721537; Fri, 23 Apr 2021 05:58:41 -0700 (PDT)
MIME-Version: 1.0
References: <C8D3F1D2-728D-4DE2-98FA-3155716DF241@cisco.com> <CAHhGMfGJbs8mgV6OrnPQ+r-ziL5VMOMiPF+w-3D1SfhX_UTTSg@mail.gmail.com> <BY5PR11MB433786C2E674B1EE849E65B2C1459@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB433786C2E674B1EE849E65B2C1459@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
Date: Fri, 23 Apr 2021 18:28:29 +0530
Message-ID: <CAHhGMfGcKj=SoG0HWJ9RTaCP6NhSXEkOroVOSX16Hm+-rhTJmQ@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "spencer.giacalone@gmail.com" <spencer.giacalone@gmail.com>, "stefano@previdi.net" <stefano@previdi.net>, Dona Maria John <dona.john@ipinfusion.com>, Vikram Agrawal <vikram.agrawal@ipinfusion.com>, Mahalakshmi Kumar <mahalakshmi.udhaya@ipinfusion.com>
Content-Type: multipart/alternative; boundary="000000000000f1ae9105c0a35a36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6KcK0VFZ1ydiFRjOyzoo9FXDdTE>
Subject: Re: [Lsr] Doubt regarding A bit set/clear
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Apr 2021 12:58:50 -0000

Hi Les,

Thank you very much for your response.
On top of your response, I have a few more queries. Please find them below.

1. For Min/Max Unidirectional Link Delay Sub-TLV, there is only one *A-bit.*


     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A| RESERVED    |                   Min Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   RESERVED    |                   Max Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Does this mean A-bit is applicable only for Min-delay?

IF not, then should we maintain 2 different maximum threshold and
reuse thresholds?

And if both min-delay and max-delay values fall below reuse threshold
we have clear A-bit.


Will below example follow the RFC?
min-delay reuse threshold : 50 usec
min-delay maximum threshold : 100 usec

max-delay reuse threshold : 200 usec
max-delay maximum threshold : 300 usec
*1st measured value:*

min-delay: 110 usec

max-delay: 190 usec


conclusion: Set A bit. (As min-delay value has exceeded max-threshold value?)

*2nd measured value :*

min-delay: 40 usec

max-delay: 320 usec

conclusion : Do nothing (Maintain pervious state of A bit as max-delay
value has exceeded max-threshold value?)

*3rd measured value :*

min-delay: 40 usec

max-delay: 150 usec

conclusion : Clear A bit (As both min-delay and max-delay values are
falling below resue threshold?)


Thanks & Regards,

Gurusiddesh V N



On Fri, Apr 23, 2021 at 4:51 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Gurusiddesh –
>
>
>
> The short answer to all your questions is “yes”.
>
> More inline.
>
>
>
> *From:* Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
> *Sent:* Thursday, April 22, 2021 10:33 PM
> *To:* Acee Lindem (acee) <acee@cisco.com>
> *Cc:* lsr@ietf.org; spencer.giacalone@gmail.com; stefano@previdi.net; Les
> Ginsberg (ginsberg) <ginsberg@cisco.com>; Dona Maria John <
> dona.john@ipinfusion.com>; Vikram Agrawal <vikram.agrawal@ipinfusion.com>;
> Mahalakshmi Kumar <mahalakshmi.udhaya@ipinfusion.com>
> *Subject:* Re: [Lsr] Doubt regarding A bit set/clear
>
>
>
> Hi All.
>
>
>
> *Gentle Reminder!*
>
>
>
> Regards,
>
> Gurusiddesh V N
>
>
>
> On Mon, Apr 19, 2021 at 6:54 PM Acee Lindem (acee) <acee@cisco.com> wrote:
>
> Gurusiddesh,
>
>
>
> I’ll defer to the RFC authors on your question. However, please refrain
> from referring to bits as being “unset”. They are set or clear.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <lsr-bounces@ietf.org> on behalf of Gurusiddesh Nidasesi <
> gurusiddesh.nidasesi@ipinfusion.com>
> *Date: *Monday, April 19, 2021 at 6:13 AM
> *To: *"lsr@ietf.org" <lsr@ietf.org>
> *Cc: *Spencer Giacalone <spencer.giacalone@gmail.com>, Stefano Previdi <
> stefano@previdi.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>,
> Dona Maria John <dona.john@ipinfusion.com>, Vikram Agrawal <
> vikram.agrawal@ipinfusion.com>, Mahalakshmi Kumar <
> mahalakshmi.udhaya@ipinfusion.com>
> *Subject: *[Lsr] Doubt regarding A bit set/unset
>
>
>
> Hi All,
>
>
>
> I had a query regarding setting/unsetting A bit.
>
>
>
> https://tools.ietf.org/html/rfc8570#section-4.1 states that
>
> A bit:  This field represents the Anomalous (A) bit.  The A bit is
>
>       set when the measured value of this parameter exceeds its
>
>       configured maximum threshold.  The A bit is cleared when the
>
>       measured value falls below its configured reuse threshold.  If the
>
>       A bit is cleared, the sub-TLV represents steady-state link
>
>       performance.
>
>
>
> So does it mean we have to have two configurations one for reuse and another for maximum threshold?
>
> *[Les:] Yes. The goal is to prevent altering the advertisement due to small oscillations of the advertisement. If you had a single value then if the measured value bounced between (for example) +1/-1 of the threshold) the advertisement of the A-bit would change rapidly – this is undesirable.*
>
> *So the max threshold triggers setting of the A-bit and the reuse threshold triggers clearing of the bit. The reuse threshold provides some confidence that the measurement has stabilized below the maximum anomalous threshold.*
>
>
>
>
>
> Will below example follow the RFC?
>
> reuse threshold : 50 usec
>
> maximum threshold : 100 usec
>
> 1st measured value : 110 usec
>
> conclusion: Set A bit.
>
>
>
> 2nd measured value : 75 usec
>
> conclusion : Do nothing (Maintain pervious state of A bit as the value is less than reuse or greater than threshold)
>
>
>
> 3rd measurement value : 30 usec
>
> conclusion: Unset A bit.
>
>
>
> *[Les:] Yes this conforms to specified behavior.*
>
>
>
>  If we have to have two configuration for threshold to set/unset A bit, will they be different from the threshold that we use for advertisements?
>
> *[Les:] **Yes . ** This is clearly stated in Section 5:*
>
>
>
> *“4.  For sub-TLVs that include an A bit, an additional threshold*
>
> *       SHOULD be included corresponding to the threshold for which the*
>
> *       performance is considered anomalous (and sub-TLVs with the A bit*
>
> *       are sent)…”*
>
> *   Les*
>
>
>
>
>
>
>
> Regards,
>
> Gurusiddesh V N
>
>
> .
>
>
>
>
> --
>
> Thanks,
>
> Gurusiddesh V N
>
>
> .
>


-- 
Thanks,
Gurusiddesh V N

-- 
.