Re: [Lsr] Open issues with Dynamic Flooding

tony.li@tony.li Thu, 07 March 2019 20:35 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 353E0126C87 for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 12:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NObxZZOYdBwx for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 12:35:45 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 B98D91224E8 for <lsr@ietf.org>; Thu, 7 Mar 2019 12:35:45 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id d25so12334998pfn.8 for <lsr@ietf.org>; Thu, 07 Mar 2019 12:35:45 -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=dcYvAQ/gz58LeyXxkjbNjNIgmUfQissnAn9M5MEH8DE=; b=V1kBvU/972G63pAnzpL/ckrJY7He9J+hm4H3bQOS3YqA1urF0SvWg7lEcc2z2MqYN+ 3gxYfXDN4KMAkeGuybePDuiaI2nd09Dr4CB3ezp9v6izbn7xZN6v4WZObLriI4tS3oTv 3ETwrTqr6EGkZ2BMGNfPmb/vq5dSyS84QBYYNp04Z3TIu/pU/bod9WN/6SMxW4sn4FfT AU9V+a4GnTAGMuLgOzbLwm92m7PIvTAjw7i1glK9KJHSrOqeZEIxfrlOg7hSkOk7OJ+n Jou9TuxVeBKUHefTb7CrRteuTDLGQ1Q3ejPBgS+L17DsCtJvlbTTv88JhI5+32AzUMKy 9d2Q==
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=dcYvAQ/gz58LeyXxkjbNjNIgmUfQissnAn9M5MEH8DE=; b=WwFTX3g1pV1YQpcWh/Y9Jc4DSoKPz4+kBeObgab7WwA/YOD8jMhoI6mWN1c6B2KMZl dPtMqurh7gu3gBt0Xq0JVCBVugE5Dux8xMVQOuYrlYLDq1LSFQwGXePxUllQw5yfGQdo 5aNXvExkhFk3kAdTtUKJWymAmpSd3VBDEp1rCfJx5OlxK5FbldVBpN2RIDEsK3vQI+dW 2tAHpEHfP8uW+6xKBDkHOr3Y4WNvqR7Z876yICAl3JehoMDONM+ostVY1Yk7PIP9rFQh Edg8FVQDh2B8h9CacfP5q8W4Fnh7w2zKpummanrR9UVbXHW1vxL0RD72VRtJty8o1Y0+ bJ3g==
X-Gm-Message-State: APjAAAXr9xE1WDngGkml/kRwDyPDOhLx8dsTpzKYUBn61rN0Fr+OQQtQ pjLvR8DYcmI34prP1LyA4qs=
X-Google-Smtp-Source: APXvYqyjzzIqsv3UaCGJlmbGzFtDs3y14cVl1Kl6zvHdt2wyA10ehR9GuHQg8c3kD2hUKGryQz2BBA==
X-Received: by 2002:a62:1346:: with SMTP id b67mr15040971pfj.195.1551990944880; Thu, 07 Mar 2019 12:35:44 -0800 (PST)
Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id e21sm13345923pfh.45.2019.03.07.12.35.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 12:35:43 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <4E38AE25-74AD-4DB5-BAA2-0A2CDC5D366B@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF320035-A1C0-4DEE-A775-28E9228FE914"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 07 Mar 2019 12:35:41 -0800
In-Reply-To: <BYAPR11MB3638D584975FF64B348D6705C14C0@BYAPR11MB3638.namprd11.prod.outlook.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, Peter Psenak <ppsenak@cisco.com>
To: Les Ginsberg <ginsberg@cisco.com>
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> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> <C723C078-72FD-426C-99F2-F0A494E0E971@tony.li> <BYAPR11MB3638D584975FF64B348D6705C14C0@BYAPR11MB3638.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2wKG4uVxauRCSk5supzUk07PLQE>
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: Thu, 07 Mar 2019 20:35:47 -0000

Les,

> 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.
>  
> [Les:] The first sentence is OK with me.


Great!


> The second one I think goes beyond anything on which we can claim consensus.


Ok, thank you for saying so.  Silence is assent, so what should it say?


> Whether adding the first sentence alone is worth a new revision I think is questionable – but I certainly would not oppose it.


The cost of a new revision is trivial, given that the system is automated.


>  Regarding LANs, the encoding for OSPF is more problematic – basically we need to identify the value as a router id or a network LSA id (or something like that).
> So, committing to this without consensus has a downside that we might live to regret.
>  
> I am in agreement with Peter’s position. LANs introduce additional complexity and it is not clear that including that support is a real benefit in the topologies in which we expect the flooding optimizations to be used.
> I know you believe real deployments may need this support – but what I don’t know is whether we have hard evidence to support that position.
>  
> I am also wondering whether the following serves us better:
>  
> a)We keep LANs always enabled for flooding
> b)The algorithms consider this and are biased towards using LANs when possible as this is a cheaper way to enable flooding to multiple nodes than many P2P interfaces.
>  
> IN this way we keep the simplicity of not having to define LAN behavior/encoding, yet reap benefits in topologies where LANs have a significant presence.
>  
> Let me know what problems you see with this approach.


Again, there are lots of cases where having LANs enabled is sub-optimal.  Parallel LANs, for example.

Yes, LANs MAY be a useful way of covering the topology, but without algorithm specifics, it’s difficult to discuss.  In the simulation work that we’ve done, it’s pretty much a wash. Sometimes it’s helpful, sometimes it’s redundant. It very much depends on the topology.

You can imagine a LS network where ALL links are still in LAN mode.  By your rules, that completely disabled dynamic flooding.  I don’t think that’s tractable.

Not being able to describe the flooding topology precisely is a significant hindrance and is going to cause misbehavior one way or another.  Suppose that we have nodes A, B, and C.  Suppose that AB is a P2P link and {A, B, C} is a LAN.  Now suppose that the topology requests path AB.  What do A and B do?  If the LAN was intended, then C is included.  How does C know that?  

So, I don’t think LANs on all of the time works.  And then we need to be able to specify what’s going on, so that means naming LANs somehow.

Tony