Re: [Isis-wg] Alissa Cooper's Discuss on draft-ietf-isis-te-metric-extensions-09: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Wed, 03 February 2016 17:32 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3B11B357F for <isis-wg@ietfa.amsl.com>; Wed, 3 Feb 2016 09:32:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
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 hqFkjJZTxDWI for <isis-wg@ietfa.amsl.com>; Wed, 3 Feb 2016 09:32:31 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3D41B357D for <isis-wg@ietf.org>; Wed, 3 Feb 2016 09:32:31 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 348E520897 for <isis-wg@ietf.org>; Wed, 3 Feb 2016 12:24:45 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 03 Feb 2016 12:24:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=KXzKSKSx5V1DqXptA2bfruCW3l4=; b=KTenE+ uKuguBERX8ZBBau4H0DOOKrk/n+iaAks6F3qscnweINbwhN72MirFxDTwKJAuQy0 zO7rDPRUuCKcfWLmD9o1KXlx55IqqxeYfEcKIbHR/jN4arA4Sssju3XLbdX9GXvB IzbFWYji9HmALE3jCBBH+RME0lNEaMeOLN+zA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=KXzKSKSx5V1DqXp tA2bfruCW3l4=; b=i+AMgWIhU/GOqvUmuG00xHGe9+yfWdgw3rEw8ldYihizR/O z4jQi39VhDhXUfGBraOmcjv0bNufiath/DowxJFhauL+VHYlaEFTFTLemdgJSJIT 8YYnFLdbkZ5ziwcNtEvDRab5KMIpZuaxKOMuP8ubOZeeHPF/Ymn+z+4VDlG8=
X-Sasl-enc: NBWovWVFebXxsUcsFrRSr7Joy8PQ+yTrV+8CitSXddyv 1454520284
Received: from dhcp-171-68-20-87.cisco.com (dhcp-171-68-20-87.cisco.com [171.68.20.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 526E468013B; Wed, 3 Feb 2016 12:24:44 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <F5E7BA79-8013-49F2-B6CA-93F971393B26@cisco.com>
Date: Wed, 03 Feb 2016 09:24:43 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <870A3143-5031-4099-9B38-F64630024BD5@cooperw.in>
References: <20160202000623.2041.75747.idtracker@ietfa.amsl.com> <0313B05C-9CAF-4629-A598-C97CFE33AF8F@cisco.com> <96D0C84E-DCAC-4905-B0C0-9085010CB7B1@cooperw.in> <F5E7BA79-8013-49F2-B6CA-93F971393B26@cisco.com>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/t18BOpDyivWDENs8mcbyILMn1jI>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, "draft-ietf-isis-te-metric-extensions@ietf.org" <draft-ietf-isis-te-metric-extensions@ietf.org>, IESG <iesg@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>
Subject: Re: [Isis-wg] Alissa Cooper's Discuss on draft-ietf-isis-te-metric-extensions-09: (with DISCUSS and COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2016 17:32:32 -0000

> On Feb 2, 2016, at 11:44 PM, Stefano Previdi (sprevidi) <sprevidi@cisco.com> wrote:
>>>> 
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> (1) There seems to be some inconsistency in the way the A-bit is
>>>> described as applied to the min/max delay sub-TLV. Section 4.2 says:
>>>> 
>>>> "A-bit.  The A-bit 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 clear,
>>>> the sub-TLV represents steady state link performance."
>>>> 
>>>> Is the A-bit meant to apply only to the min delay? Or only to the max
>>>> delay?
>>> 
>>> 
>>> As stated, is the value of max-delay that triggers the setting of the a-bit and it is used to indicate that something is going wrong with that link.
>> 
>> What do you mean “as stated”? The text does not say whether the A-bit is triggered by min delay or max delay. It says it is triggered by “this parameter,” but there are two parameters in the sub-TLV.
> 
> 
> sorry, my fault, I was looking at the wrong section.
> 
> Indeed, the A-bit is set when any of the two parameter exceeds the configured threshold.
> 
> The correct text should be:
> 
>   This field represents the Anomalous (A) bit.  The A bit is set when
>   one or more measured values exceed a configured maximum threshold.
>   The A bit is cleared when the measured value falls below its
>   configured reuse threshold.  If the A bit is clear, the sub-TLV
>   represents steady state link performance.
> 
> which is also in line with RFC7471.

Ok, this makes sense. I still think clarification is also needed in Section 5.

> 
> s.
> 
> 
>>>> Then Section 5 says:
>>>> 
>>>> "For sub-TLVs which include an A-bit (except min/max
>>>>   delay), 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)."
>>>> 
>>>> Since min/max delay is excepted from this recommendation, I don't
>>>> understand what the A-bit means in the min/max delay sub-TLV.
>>> 
>>> 
>>> if delay is higher than a configured value the a-bit is set.
>> 
>> Min delay? Or max delay? And if the min/max delay sub-TLV includes the A-bit a specified in 4.2, why is it excepted from this recommendation?