Re: [Lsr] IGP TE Metric Extensions

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 06 June 2018 05:42 UTC

Return-Path: <ginsberg@cisco.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 44E70130EA2 for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 22:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 BKx-bYbCEIu1 for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 22:42:53 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A332130E9C for <lsr@ietf.org>; Tue, 5 Jun 2018 22:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23772; q=dns/txt; s=iport; t=1528263773; x=1529473373; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qfMa4+ag1FrF0tq0LmkIYKdtn20asikaKV/ZiN+BCZ8=; b=VThgt+g3Hrta4188Bkotz+WZWZDtkBc4jl6GHyPvO46nyE6vcpjEbeHd 0uNDrAIvewZsk4PHXXsQ7iJV5VUQmDzrB2lbqZO39sKAooSdY8RA8Nxt8 U20id6VIEoza+M+1Q3r75KcaWBVL4a46FT9CYc41QJKvL828p5CEtRi3V Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUAADrcxdb/5tdJa1bGQEBAQEBAQEBAQEBAQcBAQEBAYJORy5ifygKg26IBIxvgXmIF4w7gXgLI4RJAheCDSE0GAECAQEBAQEBAmwcDIUoAQEBAQMjCkwQAgEIEQQBASgDAgICHxEUCQgCBAENBQiDHIEbTAMVD6gWghyHCQ2BLIFjBYhCgVQ/gQ+DDIJPQgEBAgGCE4JKglUCkSyHHiwJAoVrglmDIIJ6gUWLZYdmghtKhjYCERMBgSQdOIFScBUagmSLEIU+bwGPFoEZAQE
X-IronPort-AV: E=Sophos;i="5.49,482,1520899200"; d="scan'208,217";a="409512200"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 05:42:52 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w565gqiN018000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2018 05:42:52 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Jun 2018 00:42:51 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Wed, 6 Jun 2018 00:42:51 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Stefano Previdi (IETF)" <s@previdi.net>
Thread-Topic: [Lsr] IGP TE Metric Extensions
Thread-Index: AQHT+Hu3p8iqLhmCO0GfRIj635PcyqRJrgqAgACp1QCAAFDMgIAHNj6AgABQHYCAAJ6AAP//7OlQ
Date: Wed, 06 Jun 2018 05:42:51 +0000
Message-ID: <f9596658b70148cab4869aa3bf012b57@XCH-ALN-001.cisco.com>
References: <CAKz0y8zTE_ZkN6_MdXF0hxoRJG81TpBJAk9vtvjYmzWpY6=FHw@mail.gmail.com> <B33C32CE-0EDA-41C9-B1A6-62E8DBA0E7B2@gmail.com> <CAKz0y8yGWg5=ZGyTcWiRSJQFKF7brZddnpVhMPk6GwmhhQr3Uw@mail.gmail.com> <CAJp-iyW2RRQOTfpdh4xLLqUK_xPwqLdDU7ijBPmDSXLn=HVBMQ@mail.gmail.com> <CAKz0y8wnP6PsJPOCTmXOzmHBs5X=2PuXCbgLJ_BWUm3XhNmURw@mail.gmail.com> <CA+b+ERkZNimVR0XnZUS=k6wcZRQx2z4irbE0W2y2y3+V4vG01A@mail.gmail.com> <CAKz0y8xySKpuTLx75+uinZk0b6knY0Ti0AFPHjKp4U6-j_W7Fw@mail.gmail.com>
In-Reply-To: <CAKz0y8xySKpuTLx75+uinZk0b6knY0Ti0AFPHjKp4U6-j_W7Fw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.83.152]
Content-Type: multipart/alternative; boundary="_000_f9596658b70148cab4869aa3bf012b57XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8sLKzB4MGXGa92nV6Iphi6mUvSs>
Subject: Re: [Lsr] IGP TE Metric Extensions
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 06 Jun 2018 05:42:59 -0000

Muthu –

I agree with the comments from all of the folks who have responded to you thus far.
The RFC is specifying what the externally visible behavior needs to be in order for the feature to be safely and usefully deployed – it is not specifying HOW to implement that behavior.

But, let’s assume for the moment that you are “right” and that the draft wording is suggesting that configuration knobs for the thresholds/filters should be owned by the IGP.
If, despite this “suggestion”, you were to decide to implement the knobs elsewhere (e.g., under the interface) – would it affect interoperability? Would it be detectable from the vantage point of another router?

I don’t agree with your interpretation –and I don’t feel that any change in the text is needed.
But I do defend your right to implement the knobs wherever you like.

However, before making your decision you might want to consider https://tools.ietf.org/html/draft-ietf-teas-yang-te-14#section-3.2 - which is relevant from a manageability perspective. Your choice of where to put the knobs might indeed matter (though not to the IGP externally visible behavior).

   Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of Muthu Arul Mozhi Perumal
Sent: Tuesday, June 05, 2018 6:26 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>; Stefano Previdi (IETF) <s@previdi.net>
Subject: Re: [Lsr] IGP TE Metric Extensions

Robert,

On Tue, Jun 5, 2018 at 9:28 PM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
​Muthu,​

​How is the measurement interval and filter coefficients described in the draft related to dissemination?​

​It is directly related. If you see the title of the section is: "Announcement Thresholds and Filters"​

So measurement interval does not intend to describe how often you actually measure ... it describes a time window where you report the value (which could consist of many measurements actually taken).

​Are you saying measurement interval is a misnomer? The draft clearly distinguishes measurement interval from announcement interval:

​   Additionally, the default measurement interval for all sub-TLVs
   SHOULD be 30 seconds.

   Announcements MUST also be able to be throttled using configurable
   inter-update throttle timers.  The minimum announcement periodicity
   is 1 announcement per second.  The default value SHOULD be set to 120
   seconds.​

Yet, it claims measurements are outside its scope..


We intentionally left out this part that does not belong to the igp protocol machinery.

​Which of the functionalities described in sections 5, 6, 7 of the draft belong to the IGP protocol machinery?


​What draft are you talking about ? I was under impression that we are discussing RFCs here.

​Well, both -:) I am referring to draft-ginsberg-lsr-isis-rfc7810bis and I believe there is a chance to improve some text in RFC7810..

Regards,
Muthu



​All functionality from sections 5-7 aim to provide machinery to control stability of protocol operation. It is one how you measure and this is not part of the RFCs. and completely different what and how you advertised derived values from those gathered by your measurements. Now keeping in mind that you do not advertise when you measure but only when you are allowed by protocol rules it should be easy to see the point which Stefano made above.

​Thx,
R.