IETF Logo Mail Archive

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

tony.li@tony.li Wed, 19 February 2020 19:25 UTC

Return-Path: <tony1athome@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 10F9A120086 for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 11:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 JjZtbLAZ-7RZ for <lsr@ietfa.amsl.com>; Wed, 19 Feb 2020 11:25:29 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 F0D8D120045 for <lsr@ietf.org>; Wed, 19 Feb 2020 11:25:28 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id t14so466682plr.8 for <lsr@ietf.org>; Wed, 19 Feb 2020 11:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jipoHzHkhlSfF3WC8IU2zuryZmOwLe2ynsD8DT+796I=; b=QZQuWnvy1vqiMeijv9O79AskFZSI1AXDI6OZAt6n0k1yVhWJHSr117c6UDB7sPhijv lfbhtvMOUP2eAt6mfTK5PaZfzalG4+Te8neL0AXlOz3iDauJ6WOKaHDBwqK3MFZgNi+W 8WvLvaZ5Rj3RFZXZfPbeyCB/J6WjItOM00ptrZ4IRCxUAC8KKVvxNuOi9lhCuZj7a3Ix 0YEc4eDY8IKG5Dn7kyoczOZpPTVAIcEWeMAPOD8ioEXFQk13nDOPEa+/zyqgdHJwsQ8+ h3AeclR3uGUNeMLr3IMR5qswBjtHfOQQTjffeeLK/8RnSSwiqTEpj2Xj/Fz1CL6vAG+p B3ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jipoHzHkhlSfF3WC8IU2zuryZmOwLe2ynsD8DT+796I=; b=eyK7K03QcWEVmZpQPjWTp0EA8acVquMQE3FQzo9LfZx+nkk1iErboOk9G/Q/As3c6T W9A5kNXBnGQNAVr8yX+o8knoxBnHZkiAcOaI70CyXnAIDAvlNXsYFIROix1vSWqDg186 hXhbEHG5NLgQsBvooizWcEE6Iph1WC2BPU+pyVV3Gwa2z9quRxuqm0inSJ6YMCVKkoez 4N1G/krUZCcy1Zg26QLGhI9vGuncqo6rDOcK+M4bsa2XpZdvQW96fM+NkQS4cSyEwj9R aAPZ9408/dD7GHzK1Bzp2TiMz1KV/xO/SQJ2PJXB9BmjNhGq2F/VnQz7Aen/qrfiBpgi dLJg==
X-Gm-Message-State: APjAAAXKxeMUXuTeKZqjGOSxSwxfDYxuVEhnJiEYBq9TdLh31Ipc8C9R 3In3eWDNdCaAcVf747539KLG13oLIwE=
X-Google-Smtp-Source: APXvYqzwm3C0LnCz1HzKGZA5eveNjQHWNTWkjaVr4yBLtZeqwoSRNM+HGWs3a5ly45chVVqeJPmTRA==
X-Received: by 2002:a17:902:262:: with SMTP id 89mr27630855plc.67.1582140328541; Wed, 19 Feb 2020 11:25:28 -0800 (PST)
Received: from [10.128.13.33] ([118.127.110.110]) by smtp.gmail.com with ESMTPSA id 11sm410205pfz.25.2020.02.19.11.25.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2020 11:25:27 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <4D5A06BB-0522-4FB5-B783-4AD7C78F8EC0@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C4B8B322-6D67-4B5E-843C-C17B1222F4DF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 20 Feb 2020 06:25:23 +1100
In-Reply-To: <f5b56713-2a4d-1bf7-8362-df4323675c61@cisco.com>
Cc: Les Ginsberg <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: Peter Psenak <ppsenak@cisco.com>
References: <5b430357-56ad-2901-f5a8-c0678a507293@cisco.com> <4FC90EB2-D355-4DC5-8365-E5FBE037954E@gmail.com> <f5b56713-2a4d-1bf7-8362-df4323675c61@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Gemsh6eT8Id2b60gvRcjNgOmRnM>
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
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: Wed, 19 Feb 2020 19:25:30 -0000

Peter,

> I'm not scared of polynomial evaluation, but the fact that my IGP implementation is dependent on the PD specifics, which are not generally available and need to be custom built for each PD specifically. I always thought a good IGP implementation is PD agnostic.


Your implementation is always dependent on the underlying hardware.  We have timers, we have filesystems, we have I/O subsystems, threads, and clocks to contend with. The input queue in the hardware is a fact of life and knowing about it can improve our implementations.

Because the PD layer can provide isolation from the specifics, the IGP implementation is reasonably abstracted from those specifics, in much the same way that the OS has abstracted us from the remainder of the underlying hardware. All I’m proposing is adding one more item to that PD abstraction.

Regards,
Tony

v2.23.0 | Report a Bug | By Email