IETF Logo Mail Archive

Re: [Lsr] Open issues with Dynamic Flooding

tony.li@tony.li Tue, 05 March 2019 21:31 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 14DF213104F for <lsr@ietfa.amsl.com>; Tue, 5 Mar 2019 13:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ksQtCY9wfsMH for <lsr@ietfa.amsl.com>; Tue, 5 Mar 2019 13:31:24 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 EEAC3130DEF for <lsr@ietf.org>; Tue, 5 Mar 2019 13:31:23 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id k11so5548438pgb.8 for <lsr@ietf.org>; Tue, 05 Mar 2019 13:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W0EIweRcEM+7gDSRFsObDV8Joa1i2VxdsW/IgpYK7/M=; b=pv76RyK3RJnDg9w+PeMTxNzS9ZaLvp5C+Y4BsSXxo1Z97D8Sd51C2mWA1TJwiBLzMB zB6QceOh0qVz0RsH0regFJYb8u+xHU7YYTOyJ86Ohbp+zX6nUOd2qwH0WxyT3PGib0Dq BDvg7SjgtEYadGxJVIcL8oBjZDqSjmj+lixEgbFHbo8dWslQLwIdiuwvzT+8/pTWok2C QkyfI4tv7AWIf38PA9GZhsXPt/RhblJqwpp/XVRsoyjgiQcIWmmGUKxFBIPkC8Tg3uhx DCF3ZHig5+Asc+3qtbXe3dcrxVZ7pXuRa/JOOeXWT0Q7M1EQW1ftItN8VgNWnXQGcZ8L nOjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=W0EIweRcEM+7gDSRFsObDV8Joa1i2VxdsW/IgpYK7/M=; b=W/FKuLYhWmwpwCFeLflJ8/fTVWiDCwRS2b7CgEkEc+2fG1y4oWNDFPaeWVqzAwZnL+ WtocZnE+6BkGBICqBxhVCFjg/Kc6tsvS/ZDfMmjn0H/3OVt+dKJtJoLnKtdPsYC7T7xC 8m4djt7X3T0/Sr4WQ3a8LzXuufnF/iSfW7+2FmeD+f9UHy0nN6N5ImtMdBTdQDdElD1E hX9VNH/MSc1JsL6C/5fLPUK+gyoPvPLQbz37d0RqXQ3FvjOV6OQ6Kf9tR7EFivGkkxNP dpJfcskrs24kkSBea3Lmlw9cxqwq1qmUphe5FtRzMe/6vSZrlr/SEwchcRID10XhI9wU bqEQ==
X-Gm-Message-State: APjAAAV0G6RmDEqtZqcCewOM29oRu80WE3gsVUk+hTq9KRCdhk2FRijn aHKS+TTC2L2k3gjnFBju+YI=
X-Google-Smtp-Source: APXvYqwWLgXOzPT8HWF+AifUTnsPRuNl5TIpMfjJsQ8SguYczKwN+wAaLCDBaYY2+E0tw4BUFVS+ZQ==
X-Received: by 2002:a17:902:e90b:: with SMTP id cs11mr3243385plb.197.1551821483446; Tue, 05 Mar 2019 13:31:23 -0800 (PST)
Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id v8sm18497428pfm.174.2019.03.05.13.31.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 13:31:22 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: tony.li@tony.li
In-Reply-To: <a33ff3ba-975b-2ef2-93e9-1bc9664fdd5a@cisco.com>
Date: Tue, 05 Mar 2019 13:31:22 -0800
Cc: lsr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li>
References: <AAD29CF0-F0CA-4C3C-B73A-78CD2573C446@tony.li> <c1adac3a-cd4b-130e-d225-a5f40bf0ef55@cisco.com> <F3C4B9B2-F101-4E28-8928-9208D5EBAF99@tony.li> <be28dbcf-8382-329a-229f-5b146538fabe@cisco.com> <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <c8f40acb-94fe-f42a-aa0a-3a42e0067be8@cisco.com> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <a33ff3ba-975b-2ef2-93e9-1bc9664fdd5a@cisco.com>
To: Peter Psenak <ppsenak@cisco.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0lUFghR-rqisIrJcnPj61tczSeA>
Subject: Re: [Lsr] Open issues with Dynamic Flooding
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: Tue, 05 Mar 2019 21:31:26 -0000


>> I agree that optimal is probably unknowable. The question then is what
>> do we say in the document?  How about something about rate limiting?
> 
> yes, something of that nature, with possible config option.


Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 like:

Addition of temporary flooding should be done with caution, as the addition of excessive connectivity to the flooding topology may trigger unwanted behavior. Routers SHOULD add temporary flooding in a rate limited manner, if not configured otherwise.


> the trick is that "all" nodes would comply, where we may only need one/subset to do...


This is the addition of one link, and in particular the onus is really on the DIS to drive synchronization.  Per your above arguments, I’m comfortable with this.

Tony

v2.23.0 | Report a Bug | By Email