IETF Logo Mail Archive

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

tony.li@tony.li Mon, 20 April 2020 16:28 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 C16683A0B10 for <lsr@ietfa.amsl.com>; Mon, 20 Apr 2020 09:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level:
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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 UoW_U6oMKTu2 for <lsr@ietfa.amsl.com>; Mon, 20 Apr 2020 09:28:40 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 7C3B33A0B0B for <lsr@ietf.org>; Mon, 20 Apr 2020 09:28:40 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id t4so4121925plq.12 for <lsr@ietf.org>; Mon, 20 Apr 2020 09:28:40 -0700 (PDT)
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=J2q8GI0q7SuWHrpyueaMDgQX4YAVSZa9fXrJ2Ox8HRc=; b=R2RwzbCa2xRgrIyw54FJ5tSaA3ySgs/mGovLVYAaQ/+xxAFg8ngSmkReqvaOa1wlw7 QtRc4Qnlvf1q8/rmbKxPAiOPlRrWBE74puWDpKn2FhsijJ3BV68dZ8H7o8iQs7JEhSgX V9JcWMGuWGNVfhlXapeHncTrox2bAjOC+jzmN/ZdXrWQdAkvjc/XRsSKO1qML9mN27YM tKZdYKCK3aDKjRBsaUAtSgKF7InySqTeYohmZetVTtmGATAMAe/wMwXcacWOElIrI0bk xT763DUS7o1IDDPRpm4T1NVnCdQQysPI+HgQ3ny5/bfUsxvbdwV8FvwHpcEsbenWtQAi Y84Q==
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=J2q8GI0q7SuWHrpyueaMDgQX4YAVSZa9fXrJ2Ox8HRc=; b=jpEm2TlMsAC9JpbE/NHOJiVoJc7xbzpbnOFiO80jeZE81F1vHkCj9m1VPAKA+mJ1P6 KjkyNF4Mi/YbzaeiJwyoPf8+WPg212+qllvo9R4LxqbfVHCDAnI6cx2xMiheu81nFMrl jjabPl3Tb/lmyxVPskD42y0ZVi3b+H0przY0ly2CakX7DYtsBnr35tBmG6Mp+fjghHgJ gEFFhvd69dOA8jn/vO4W2On3lTkuFudjSLn1SinFKZN7dlGID9mvmDhwfZRrLVOKQZIN Rc1wxFmmhknSW8kP7RAf6ryexi4aGXKlyGlVyw679qVmtNd8e6SPD23V7iU6b9CCiZ4X vEZQ==
X-Gm-Message-State: AGi0PuaXNhqJBnP7ygjvsu6p/uxUgNKWBQYV2P+THI8pDXgZqrjOJONF 1XkCI1YJB3gPSugj+/DyeN8=
X-Google-Smtp-Source: APiQypKg2iV/m1JnH5Qhr3vi/pM3x6hFUU0HpZq1lhzl2DBxrggi2cRzePZ4wboRoUe7G+QFO3B2ww==
X-Received: by 2002:a17:90a:2401:: with SMTP id h1mr228173pje.1.1587400119829; Mon, 20 Apr 2020 09:28:39 -0700 (PDT)
Received: from [10.95.89.81] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id x192sm1640942pfd.3.2020.04.20.09.28.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 09:28:39 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <FDF93B2C-7730-44B1-BEED-E409CDE52C69@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0548B52A-8CB7-46DF-96B6-DDBE05C3F4AC"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 20 Apr 2020 09:28:37 -0700
In-Reply-To: <23109_1587385240_5E9D9398_23109_285_1_53C29892C857584299CBF5D05346208A48E22BAF@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Cc: Les Ginsberg <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: Bruno Decraene <bruno.decraene@orange.com>
References: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com> <MW3PR11MB461942C752F9CCB0A6E6C1BFC1100@MW3PR11MB4619.namprd11.prod.outlook.com> <15812_1582743802_5E56C0FA_15812_292_1_53C29892C857584299CBF5D05346208A48DB43B6@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46198978E071B8C7E79770CEC1D90@MW3PR11MB4619.namprd11.prod.outlook.com> <23109_1587385240_5E9D9398_23109_285_1_53C29892C857584299CBF5D05346208A48E22BAF@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Ke9px_JK3v9pwcT9y9gWW7skG7c>
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: Mon, 20 Apr 2020 16:28:42 -0000

Bruno,

> Waiting some more details, as per you below email, the IS-IS receiver does have a queue, sometimes dedicated to IS-IS, but in general relatively dedicated to very important and time sensitive traffic to the control plane. Details are indeed implementation specific. But in general, this queue is designed to protect the IS-IS traffic from lower priority traffic, e.g. burstyBGP.. So can we assume that the receiver have (or at least may have) such a queue, and work with this?


That would be ideal, but probably not realistic. Not all implementations are going to have separate queues for BGP and IS-IS.

IMHO, that’s a very good thing, of course, but not all merchant silicon is quite that sophisticated. Yet. And it takes years to change, so it’s best that we proceed without.

Tony

v2.23.0 | Report a Bug | By Email