Re: [Lsr] IGP TE Metric Extensions

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 05 June 2018 12:04 UTC

Return-Path: <ketant@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 66686130FF1 for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 05:04:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 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_HIGH=-0.01, URIBL_BLOCKED=0.001, 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 37re1qjb12ts for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 05:04:21 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33674130FEA for <lsr@ietf.org>; Tue, 5 Jun 2018 05:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35718; q=dns/txt; s=iport; t=1528200261; x=1529409861; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8z3StKCOJrCMlyaJjiMO4O3w7NmDGzZOxr9IDf819Nc=; b=BxxToFN3iF8DWMrzl+3jkl6Ia4YaA9AkFWxXcl3LfRNr0qvztaSCQyzi XY+dHXoEGlPy0lf/HFFhQy5TtbmPk+NDVLbMarUwDC8/bx+5f02l6GNwf vv48IuwTdGRSAMwlHu+GuQgCrPquPnyLlBuGGwTN8r22Oi9409IGLOsJ2 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DFAADlexZb/4oNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJOdWJ/KAqDbogEjG2BeYgVjDaBdQMLGAEKhEkCF4IJITQYAQIBAQEBAQECbBwMhSgBAQEDAQEBIQpBCwULAgEGAhEEAQEBIAEGAwICAh8GCxQJCAIEDgUIgxyBG0wDDQgPi2ObR4IchwcNgSyBYwWIQoFUP4EPgwyCT0IBAYIWgkqCVAKRByCHGywJAotggnmBRIN4h2aKQoY2AhETAYEkHTiBUnAVO4JDixCFPm+OKYEZAQE
X-IronPort-AV: E=Sophos;i="5.49,478,1520899200"; d="scan'208,217";a="405982831"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 12:04:00 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w55C40q8000908 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2018 12:04:00 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Jun 2018 07:03:59 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Tue, 5 Jun 2018 07:03:59 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
CC: "Stefano Previdi (IETF)" <s@previdi.net>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>
Thread-Topic: [Lsr] IGP TE Metric Extensions
Thread-Index: AQHT+Hu3yMVd+pXj+0u0nPyEp9to2aRJrgqAgACp1QCAAFDMgIAHNj6A//+uw9CAAFt9AP//sAyw
Date: Tue, 05 Jun 2018 12:03:59 +0000
Message-ID: <b5583439198442cdab833a798985c377@XCH-ALN-008.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> <cb14fd79505a48f6b9fa57be5354673a@XCH-ALN-008.cisco.com> <CAKz0y8w7cO1AGZxp83Rf-_TvjeEz6zEjsB5UBLmAsC17c34e2w@mail.gmail.com>
In-Reply-To: <CAKz0y8w7cO1AGZxp83Rf-_TvjeEz6zEjsB5UBLmAsC17c34e2w@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.65.51.194]
Content-Type: multipart/alternative; boundary="_000_b5583439198442cdab833a798985c377XCHALN008ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/sq1VfH005IU_TaliM3bX0J1p9ZE>
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: Tue, 05 Jun 2018 12:04:25 -0000

Hi Muthu,

These are implementation specific aspects and I am not sure if this is something that the draft should be getting into.

Thanks,
Ketan

From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Sent: 05 June 2018 17:19
To: Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Stefano Previdi (IETF) <s@previdi.net>; lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
Subject: Re: [Lsr] IGP TE Metric Extensions

Sounds reasonable to me..

Adding a clarification note in the draft would be useful, IMHO.

Regards,
Muthu

On Tue, Jun 5, 2018 at 5:00 PM, Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Muthu,

The Sections 5, 6 and 7 of these drafts are critical as it impacts the IGP protocol operation and stability though it is not an integral part of the IGP protocol machinery. This functionality in a system, whether achieved in the IGP/measurement/some-other module, is an implementation specific aspect.

To answer your question, these aspects may be implemented outside the core IGP module and the IGPs simply flood these while satisfying the aspects specified in the document.

Thanks,
Ketan

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Muthu Arul Mozhi Perumal
Sent: 05 June 2018 16:42
To: Stefano Previdi (IETF) <s@previdi.net<mailto:s@previdi.net>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>
Subject: Re: [Lsr] IGP TE Metric Extensions


​Please see inline..​

On Fri, Jun 1, 2018 at 2:34 AM, Stefano Previdi (IETF) <s@previdi.net<mailto:s@previdi.net>> wrote:

On Thu, May 31, 2018, 6:15 PM Muthu Arul Mozhi Perumal <muthu.arul@gmail.com<mailto:muthu.arul@gmail.com>> wrote:
Thanks, Jeff. Would be good to have this clarified in
​​
draft-ginsberg-isis-rfc7810bis. My original message seems to have been stripped off, so including it again for the lsr list..

​Both RFC 7810 and RFC 7471 say that:

   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

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

However, both RFCs initially say that they only describe mechanisms for disseminating performance information and methods of measurements is outside their scope.

Moreover, for a first time reader, it seems to suggest that the measurement interval and filter coefficient must be supported and configurable under the IGP.


No. This is not suggested in any form.
It is clearly indicated that the draft does not deal with measurements which means no recommendation is made.


In a system supporting multiple IGPs, I would expect that they be implemented outside the IGP and the IGPs just disseminate the information provided to them.

Thoughts, especially from an implementation standpoint?


Again, the draft is only about dissemination, not measurements..

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

​   The measurement interval, any filter coefficients, and any
   advertisement intervals MUST be configurable per sub-TLV.

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

If your question is related to configuration and implementation of measurements, well it will not be addressed by this draft.

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?

Regards,
Muthu


s.



Regards.
Muthu

On Thu, May 31, 2018 at 11:37 AM, Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> wrote:
Muthu,

LSR would be a more suitable list to post to, CCed.

Regards,
Jeff

> On May 30, 2018, at 18:06, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com<mailto:muthu.arul@gmail.com>> wrote:
>
> Muthu

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr