IETF Logo Mail Archive

Re: [Lsr] IGP TE Metric Extensions

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Wed, 06 June 2018 01:26 UTC

Return-Path: <muthu.arul@gmail.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 60072130E03 for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 18:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ewW5sosCwcks for <lsr@ietfa.amsl.com>; Tue, 5 Jun 2018 18:26:06 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 6BF92130DFD for <lsr@ietf.org>; Tue, 5 Jun 2018 18:26:06 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id k17-v6so16049945ita.0 for <lsr@ietf.org>; Tue, 05 Jun 2018 18:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iV8VvJhIpUVez4rJ4JfTdZjTaRbyElGGVMiO/UGY21E=; b=jV6y/JxndZSHnWtIiQWejzpOYqrFq1l+pxXpbtWZI26r2/BQjCump/RJ1xar3OVrTh h69qqygZmOxNV0OjskZtkAWuI6I2Wf1zkL9d1ql4cTNXvDuACqM1Y62BqRQI+4wO4ZIN ftcYngk2KeYpXTqwp7u32G3m3NvYsiBjVqO/TF8Lt8YetG3uJUY0bphQRJIWI0CvsS5B L5Mmf+kd1eHoqY//QY8XUV/66qBIxgKzbZRlvFd89IcByDElfUhitnWKXjDeIj6g+Zad ra7cJuz7o/3y5SAKLK/wPjQrD5UVTLT6JfIVJK4Ss+lvEjXRreI/u4d2lB0IH+XKnQUv udUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iV8VvJhIpUVez4rJ4JfTdZjTaRbyElGGVMiO/UGY21E=; b=CWIefom4EZZjShOhO8warXP1lGMcdNujXybgkagISNDzvKWafWoqPaLG+4ph7FEtUL xQzSzXeSNp9SiLes+59ZQtjwgyvZUO4abQat9R6zrqWJReng8PuohO/kh4saMKe84ACT L4nqe/acOhE5I3ZHINuNOBrBMtt+wg62WDAJgDL5E5NLC5Wx32J9rPJM/ZsdPv9obw2m C+WuwXm/A/pyYRFFbudrsrEj4LXii1latfPRBqoljGQT1vSsvyiNyQRaB3xeFPfB3mHW fIbWGRj5g5WMJdFcv8AMfbIH8E30xvV71WrQvv50p5ys4xwPss1RDladpDtpzefTVGPs wUUQ==
X-Gm-Message-State: APt69E3sZOxNKHwb4BcjDTJ3byi63+yi+2dB5LGRLbh2Eq1wIKFtzd0m OZnvU7Kgi0aWTkEt9xhxtLt60/2l4+fyQlKFO9A=
X-Google-Smtp-Source: ADUXVKIqPyScIA+yq5RJpzjrN+RQgUP2u5TnvNPHG0unchcjiSnv9AqRqfhYFr0C+UtWNd9wNZhWBC4vBje58x0FM4g=
X-Received: by 2002:a24:1cc8:: with SMTP id c191-v6mr571652itc.139.1528248365676; Tue, 05 Jun 2018 18:26:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:9802:0:0:0:0:0 with HTTP; Tue, 5 Jun 2018 18:26:04 -0700 (PDT)
In-Reply-To: <CA+b+ERkZNimVR0XnZUS=k6wcZRQx2z4irbE0W2y2y3+V4vG01A@mail.gmail.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>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Wed, 06 Jun 2018 06:56:04 +0530
Message-ID: <CAKz0y8xySKpuTLx75+uinZk0b6knY0Ti0AFPHjKp4U6-j_W7Fw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Stefano Previdi (IETF)" <s@previdi.net>, lsr@ietf.org, Jeff Tantsura <jefftant.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f6ff27056def0cac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nPmr1-WnjbFjvjbQIgxTZMFFwZQ>
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 01:26:09 -0000

Robert,

On Tue, Jun 5, 2018 at 9:28 PM, Robert Raszuk <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.
>
>

v2.23.0 | Report a Bug | By Email