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

Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com> Fri, 23 April 2021 05:33 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 6B2873A1300 for <lsr@ietfa.amsl.com>; Thu, 22 Apr 2021 22:33:10 -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 s4iDkN-wVD_4 for <lsr@ietfa.amsl.com>; Thu, 22 Apr 2021 22:33:05 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 79B8A3A12FD for <lsr@ietf.org>; Thu, 22 Apr 2021 22:33:05 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id j4so36210129lfp.0 for <lsr@ietf.org>; Thu, 22 Apr 2021 22:33:05 -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=Ba6+3u3LdVkofkaV/uX/GpkwFHMX30Tm3v1+3rpFT3c=; b=k4b89AAEOcxB0sKxuxlSdtbqodsrW4gCZly0rNl1Wid1BUy4ApnMfhJqHYXDkw32mB OT4YdNP3eKQB+VXFOzBGEqQgCSo711x1EMxzzBcDbS4n9tTE1H2aa3VvW/F8NBD2kZtj zQwvJi4t8IMmRV5xnyxNPcTtAjdOBLmTP9+6Yzg0+XBFBeWRGajSjWZlL31CWcGKGnue FStuPPnRE56sL4FOh+n9uRShgigXjKW1evS5R2/MmFN9SxENRcckQCqqZ+BV4EnrdzQx NlGhGtRg3orM2s2yL/Pf0KMgdtUHKpMPMTN9uq/gW8saeWDfHbCjTNBgj9y6Fwolx9w5 D5pw==
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=Ba6+3u3LdVkofkaV/uX/GpkwFHMX30Tm3v1+3rpFT3c=; b=PxvJrImDzv2i14Wb89IwW2pGYozmhZPYa6EkiLyoFFu/b/5J88OWYVX4+WXFEi/oh5 Qvb3j87b115s65i2Un+UKo1EfH8FGliajfm8YCVcKuLUKVBbU5W3s/r48ON8qur6U+XL R9LNN/hHOZvE9eODytIl2r/sOyRJb2Tn3Tz+UuSZPybmE7FMQZb5SNCSWyuADjiqGuTO aHO7PbDCbpo2K3yV7NbxrbrI+x3ucmaN1GJEVzkvgAcPA9Mx2ZGkerYffBBOfi21SiN8 fQPhXtJRRCmDb42w7vufoBQD1IXBPrleTy7JsAJdPCkDzepZpr6cHyafXSn4sfFtBeFe HU5A==
X-Gm-Message-State: AOAM532zlKcq5joZwYAJh5lMKzLOf6KJziXx/JMWK1U8JiXXjh1PWmc5 FD4iPgw/btt3F66wEui4ZX3+zh+5bl8yKBKvX6jAiif3SC7BTlPkE1Dz6/t9ik+0ubWJjGUMUUg 2GHfzsjN0wkU2PmA48Yhmac3ncMcwW8jqOuKEp98DlFCekikoBx6wroNQviPncxrqifCAAq3ZEE PCPx47hUSqOawZOms=
X-Google-Smtp-Source: ABdhPJwLj0vFG9WGBxlwimSfjGIAMpPlbgePUIaAKop4Bxa4FLKLbrU5BSPRvAL9NVjGmMrI+w+ey/n9ax7uZwwCWcY=
X-Received: by 2002:ac2:50d8:: with SMTP id h24mr1386203lfm.564.1619155982337; Thu, 22 Apr 2021 22:33:02 -0700 (PDT)
MIME-Version: 1.0
References: <C8D3F1D2-728D-4DE2-98FA-3155716DF241@cisco.com>
In-Reply-To: <C8D3F1D2-728D-4DE2-98FA-3155716DF241@cisco.com>
From: Gurusiddesh Nidasesi <gurusiddesh.nidasesi@ipinfusion.com>
Date: Fri, 23 Apr 2021 11:02:49 +0530
Message-ID: <CAHhGMfGJbs8mgV6OrnPQ+r-ziL5VMOMiPF+w-3D1SfhX_UTTSg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "spencer.giacalone@gmail.com" <spencer.giacalone@gmail.com>, "stefano@previdi.net" <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>
Content-Type: multipart/alternative; boundary="00000000000029dd7b05c09d21e5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/SbWvAXasAtC6uaSAyi8Zwek4f54>
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 05:33:11 -0000

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?
>
> 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.
>
>
>
>  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?
>
>
>
>
>
> Regards,
>
> Gurusiddesh V N
>
>
> .
>


-- 
Thanks,
Gurusiddesh V N

-- 
.