Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Robert Raszuk <robert@raszuk.net> Thu, 02 April 2020 22:17 UTC

Return-Path: <robert@raszuk.net>
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 E9EF43A0B0C for <lsr@ietfa.amsl.com>; Thu, 2 Apr 2020 15:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 Tyf3B9bYn-FT for <lsr@ietfa.amsl.com>; Thu, 2 Apr 2020 15:17:06 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 7DA5E3A0B08 for <lsr@ietf.org>; Thu, 2 Apr 2020 15:17:06 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id z5so5221505oth.9 for <lsr@ietf.org>; Thu, 02 Apr 2020 15:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XzoZTxNZzoO8kMQIYXO+Z8RcxhYJo4ms3In7Km8GGbQ=; b=Y8lQIlB120JgvTzE8bPWJgophKSh+HmGLHfgeV6qqeLzLykyKAXBVJPTL3+Q5ENiNv 6VuSI+NJBfHO365UJyVSYQkBkQrVa7ivRvXPjVD+WNnlwog5uOYkgf1X4NUqqh6vmVLq 355LZjGErmenIcWL+xfSYv29N4rP3lMLC4MyTgyCJA/z9dKtQpptVuWwJCtBo7yMvQzM ts0kCplljmLbg/jMsqWXu4757cZBxz3rv8j38K51l6QneDv3D3Idx6homjCzmF/eXMgM j86aQv1qsWeRJmFG9ITNNwhxmTRHriC270DZHaI/RDLTRbGibIaYnWCXaVBuSYcYzyJU FZiQ==
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=XzoZTxNZzoO8kMQIYXO+Z8RcxhYJo4ms3In7Km8GGbQ=; b=gyAAuv9F4V4buy0HPxoSmqx8UsN1iK3VROjqkw/tTst8f7haY+Ur1w/z8d8Zsn1wmm IC4PrevyTiDXeabv+lpzSsp3eWKke3Urfitt8b6QTpGeiZiUNhSh7/Rh7ZFFY+4L8DFq NJC3NVuzad6RiFlemGmB3Ej5NeXM58+p5Gk/xkumsL8EgUjFLjjxEOQrMvpHaewIO3aD 3fx7p6M42znyMjW/nW4nMPHaZknSsVSzibJjx+r2A0Bof5NsYdQlG4uphqnl0/xYgVp9 5ehioCCV4m1M93R/SFIm9fTzqXZbdpx1YHN8LEbPbMr56AjbjbQFr6t2dvDo6irY44Hb bHgA==
X-Gm-Message-State: AGi0PubGRNJiN0/UTlw3ugYZLxvsEkNZ10CIUzAw5roEbZQeYTpz8af4 BsfMcL6QPrqPjP1AHJLF12P+AxgejzZAoUCb7yjUgA==
X-Google-Smtp-Source: APiQypIPU/447jntY3emE2uz76Ler0u5csD/NQfJYokVqJqUTw5njRe8BEzv3VGN+c73oPhSPGnOeGCYYU4c70VkXLE=
X-Received: by 2002:a05:6830:1e19:: with SMTP id s25mr4197692otr.86.1585865825706; Thu, 02 Apr 2020 15:17:05 -0700 (PDT)
MIME-Version: 1.0
References: <1520992FC97B944A9979C2FC1D7DB0F404DB1AD4@dggeml524-mbx.china.huawei.com> <MW3PR11MB4619361A2CA3A402A44914E5C1FE0@MW3PR11MB4619.namprd11.prod.outlook.com> <1520992FC97B944A9979C2FC1D7DB0F404DB2336@dggeml524-mbx.china.huawei.com> <68249E56-5702-4C15-9748-439E43F3EB0E@chopps.org> <1520992FC97B944A9979C2FC1D7DB0F404DEFC14@dggeml524-mbx.china.huawei.com> <A937FECB-2013-403E-89B2-47971514F6CF@chopps.org> <80a8f83c76d447dda48280495b3a80a7@huawei.com> <6F0E8437-5D82-4FAC-A061-69E56E1E161D@chopps.org> <2189e17f36764960bf2dcc554cde9ce0@huawei.com> <MW3PR11MB4619925BEF83B0C4512DD284C1C90@MW3PR11MB4619.namprd11.prod.outlook.com> <06e8443210924ac788c40fa15972cbdd@huawei.com> <C987B657-64D1-4C70-B471-ED9F1266B990@cisco.com> <3948044C-0CC9-4AE8-8541-4D23A5DF396E@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F404DF089E@dggeml524-mbx.china.huawei.com> <MW3PR11MB46197F8C43B3200B07641838C1C60@MW3PR11MB4619.namprd11.prod.outlook.com> <CAOj+MMGsVkws0sTw4RRdb_SdWvsuh+2Dxc-upXqT2_pmpO_+Lg@mail.gmail.com> <6930807B-2FF0-4A5C-AD39-D05345C37A5E@chopps.org> <MW3PR11MB461955420610E933ACC44BC4C1C60@MW3PR11MB4619.namprd11.prod.outlook.com> <CAOj+MMHoTbDzZrA1ttPsdD5Tk7TADaR=ex5WGF=6+X3X1utoHg@mail.gmail.com> <bd193457-956c-47b0-a50b-8d1778e8349a@Spark> <CAOj+MMGuRHVoJ3ez4nQ3O87J4U+-+yabYWeA1AEfj1UGAbPp7w@mail.gmail.com> <DD4DAC78-3A51-4E8D-802B-9FB515F86AF1@chopps.org>
In-Reply-To: <DD4DAC78-3A51-4E8D-802B-9FB515F86AF1@chopps.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 03 Apr 2020 00:16:55 +0200
Message-ID: <CAOj+MMHa4J-619P6TWjSohB4yP3O5VPaq42VuAzNUmzbXsFcfA@mail.gmail.com>
To: Christian Hopps <chopps@chopps.org>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Tianran Zhou <zhoutianran@huawei.com>, wangyali <wangyali11@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000033f4f005a25629ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Eo-i55GFyDSnuMGgWIh9qK1ilLQ>
Subject: Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02
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: Thu, 02 Apr 2020 22:17:08 -0000

> > If you consider such constrains to provide reachability for applications
> you will likely see value that in-situ telemetry is your friend here.
> Really best friend as without him you can not do the proper end to end path
> exclusion for SPT computations.
>
> [as wg member] Are you thinking that shifting traffic to a router is not
> going to affect it's jitter/drop rate?
>

Well this is actually the other way around.

First you have your default topology. They you are asked to construct new
one based on applied constrains.

So you create complete TE coverage and start running end to end data plane
probing over all TE paths (say SR-TE for specific example). Once you start
collecting the probe results you can start excluding paths which do not
meet your applied constraints. And that process continues.

To your specific question - It is not that unusual where routers degrade
their performance with time and in many cases the traffic is not the cause
for it but internal bugs and malfunctions.

Best,
R.