Re: [Lsr] Open issues with Dynamic Flooding

Robert Raszuk <robert@raszuk.net> Tue, 05 March 2019 19:53 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 0323D1277D2 for <lsr@ietfa.amsl.com>; Tue, 5 Mar 2019 11:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KO4YYtPgrz87 for <lsr@ietfa.amsl.com>; Tue, 5 Mar 2019 11:53:52 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 BE6F1126C15 for <lsr@ietf.org>; Tue, 5 Mar 2019 11:53:51 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id f196so5443892qke.10 for <lsr@ietf.org>; Tue, 05 Mar 2019 11:53:51 -0800 (PST)
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=JvINW1Oq6bUzlNarUHcne5R7u+N1V6y+4fhaPg6NZWQ=; b=DY5T/8u+X6hj98WvXBSih6oA7SuRiCsTQ791iEv1r0a8aEW61qzTi/16zx71OO6/mS Gp/duNGTnPxiSwCdLyiBhSj68UiEu58wIXnJf4qUw8zkFULDK7/aAsdF6tOpBs9nOQP5 EmS9dvJZwQNjDlUvkq7+iPT04Ik4ZWj7pQht+4kcAdHqEcnK90LJBsFaUbhrwQ7/WWOd bZg11zRD2J+7WqWZ9oXQDWk9LDOl51H0zJGJ5TXY+G30soTNCgiwyOfKyO5owkT07j/f xQf8jI1ux6F1sBK7+KnAzO93/pT7kCyysTUjCRaayHNLv5T4WRSfTKqOwrOB526gSy9O xUHA==
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=JvINW1Oq6bUzlNarUHcne5R7u+N1V6y+4fhaPg6NZWQ=; b=Slbsoz1GU/FqESO31aJBC3M2xmvxgunCBVWOhb+9/62n5OX+j0MeTbj25mI4U1OPwg 9jP10uI4CR5bXz/PV9vyKmyxKwKVZmyJTGXwcyokqnlUlm+yJMsn7q4MFAmfeySXcvSD vBR9T8nkZBlnpuYlNNsnbQ2ZNo/tp7Mzgk6gR+Owy9JTM0IqXQVQB87wajvvuRNKfH2Z 7yBQq0FwwU1Jgq3s5RflxjXzCr1hrfuUE0q+Wkcu/6vInXr68/VcYlSx0n4+8hNqkDZ2 AaJpA8dOUj/8hzmFl2kRdChJ0Ygyv1gBti+wsmEfyTKbB459/4bq+nQYCGhRUG6jbRQ4 0XHA==
X-Gm-Message-State: APjAAAXRHoL6Cp43X6ty0ig3047R6/ziMnBlZW4pnQroopWYk/0aHRDA 068VLjNUwhNIf0akRKnQbTGdzaIuFGdXtHvmCkkSzsGR
X-Google-Smtp-Source: APXvYqwMj3BvZiui7TTDS12s2Aoa6SOfIUgj+1fSnGq2iXlweZCTJXV3dJTBTxT8CjlbucP3llwsvhy0iTveep6R/zE=
X-Received: by 2002:a37:bc04:: with SMTP id m4mr2999497qkf.41.1551815630685; Tue, 05 Mar 2019 11:53:50 -0800 (PST)
MIME-Version: 1.0
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> <CA+wi2hPt-UrekyA9LpCWJHo9KyaOR1=eVQD29y54sciv3zh10A@mail.gmail.com> <CAOj+MMGPp=DffEw7vS4PH_vDtmYL5y2Xxgx2utNt4R6cxsCiwg@mail.gmail.com> <CA+wi2hNq5e+A3z0VyYxaajdqO+qCOgh0Pa84ionZ+BfKEf2iTA@mail.gmail.com>
In-Reply-To: <CA+wi2hNq5e+A3z0VyYxaajdqO+qCOgh0Pa84ionZ+BfKEf2iTA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 05 Mar 2019 20:53:39 +0100
Message-ID: <CAOj+MMFCWhLxoB38yp8+4bjaNaoU+0_obdrkvTSCOKZ+C9aYuw@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Peter Psenak <ppsenak@cisco.com>, lsr@ietf.org, Tony Li <tony.li@tony.li>
Content-Type: multipart/related; boundary="0000000000006d20c805835e3b94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/JP9PF-Fxsb8bBAH_cgwU9Shkmtw>
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 19:53:54 -0000

Tony-P,

I am not talking about LAGs but pure vanilla L3 ECMP paths in any DC.

Any node will be receiving at least two copies of flooded topology
(regardless in which direction you look up or down) so when one of the
links is broken which is used for actual flooding or peer sending link
state info goes down flooding graph can be repaired at its own pace while
data plane is not impacted as there are many more L3 paths still available.

That was my point.

Thx,
r.

On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda <tonysietf@gmail.com> wrote:

>
>
> On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk <robert@raszuk.net> wrote:
>
>>
>> > Slow convergence is obviously not a good thing
>>
>> Could you please kindly elaborate why ?
>>
>> With tons of ECMP in DCs or with number of mechanism for very fast data
>> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
>> is no longer a necessity. Yet many folks still talk about it like the only
>> possible rescue ...
>>
>>
>>
> Agree on FRR in WAN but it seems quite a complexity to drag that into DC
> fabrics (again, depeneding what topologies talk about) especially due to
> the effect I outline below.
>
> ECMP in DCs when used AFAIS is often caused by walking the 10G-50G curve
> where everybody has different economic sweet-spots AFAIS. Sometimes 100G.
> It's often LAG'ed (due to amount of control plane state AFAIU). LAG'ing
> generally creates interesting problems itself and I expect whole thing to
> settle somewhere with 20-50G to the server over either very short copper or
> multimode. I do not think it's a particularly cool architecture to suggest
> "LAG every link so it's 1:1 protected".
>
> Wide fanout is common & will get wider AFAIS. This is cool for failures in
> one direction but doesn't prevent you from blackholing on the "far end"
> until you get control plane reconvergence (or do FRR on a spine but
> honestly, how do you do that, bow-tieing over top of fabric or doing
> harmonica routing over multi-homed servers?)
>
> Then, slow convergence means that new stuff shows up slowly which is
> probably not very desirable and in case of failures that really need
> control plane rerouting causes longer duration blackholes as well. Both
> seem undesirable .. Not mentioning mobility even ...
>
> my
>
> [image: CodeCogsEqn(17).gif]   cents ;-)
>
> --- tony
>
>
>