Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

Robert Raszuk <robert@raszuk.net> Thu, 07 March 2019 11:17 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 AF23613131B for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:17:12 -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 PnCenP4zWmSZ for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:17:10 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 1CA82130F67 for <lsr@ietf.org>; Thu, 7 Mar 2019 03:17:10 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id m9so8736729qkl.4 for <lsr@ietf.org>; Thu, 07 Mar 2019 03:17:10 -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=iM8QHox1tpgRf/jq/d4L02UqfT2y0sZ7KIL6Pr1fGtQ=; b=aV6WLmVPxN7BpYx21InhP3sJp+V3AKYgKr4mU2CeD3NXM9PgL8jGreoAXJf8JDWZ79 w8RUK6qUxx9Ml7J10lL9v1olfDwQM3ZvMsQ4bSuVPByMqDmcUBPmahadd3Qh4BbEg53L Qju7Pol/B8DVPWOFPCPUJ26eTOQfnsHMu2xAOXGE4e9iIWdyiVq7GA6z4MsN7OiEwcxU Pm6zCXgYuohpYhr26BV22jz/8SQx16o1MN/PFmVX2RbftSsXXo/pB25AFiPnRxRzt9qN /umhk+3bdhZPWYFUWXKK8ycxzsF8nVwNrU+d4v5YE0JzGx+vfzJZ2hZjl1khjWvKZp0Q JUNw==
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=iM8QHox1tpgRf/jq/d4L02UqfT2y0sZ7KIL6Pr1fGtQ=; b=TD0KqzqbqL27E/2z6eQEkTfGRbSVfKJ6xobdTjAf1C3n3qT+4/V9jtkKMdTbFR+nAY j4fqR12W81kpMUUq1kSvA4eY7RC5JZPCWsRRWtxZAAlWJMDGn9nCZeZTyKNYriR/b1i2 kF+WyRseJbMgX+u2LXfn/pbK1IOTUnlXhxGTDjjiXZ2HhMb6kD2Fsp6bX+HW7SD+VJ0z skwdMoh6CUHfeRLFNJLMyOS1hnj6KJjBjHLwmJZ4zs2nkHUl4vuilIokrgmxFByDNuKN sSDS66V6TBFvh/V014x9zvytbyFypA55DUDUy9oay8flGuNnp69LoVJL0khi589rCcye 2ScQ==
X-Gm-Message-State: APjAAAUWG4H3NVPH4VI1wavsN00R3SYmbL/rrGyvylLW3qjXhA+Oxtb5 CBnOd0GJfkYoLZgqNy9AwwkXLha9XjsEAtvTWvfMsw==
X-Google-Smtp-Source: APXvYqyb1eIreLjejmIIagpsY9ji1RwVoEiTBb6za2sb5fhVJY5TCKSLnveTzc4Ju0yN6fFsd2Bj4YX8Xy8589TMkWI=
X-Received: by 2002:a37:d8c:: with SMTP id 134mr3421369qkn.336.1551957429201; Thu, 07 Mar 2019 03:17:09 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMGLC7S+Lz+2MtABniBqx9BA_cyeqUhR12SvUJn3ibWZUg@mail.gmail.com> <ceec44ec-b66c-6644-2bc4-aaf09225c224@cisco.com>
In-Reply-To: <ceec44ec-b66c-6644-2bc4-aaf09225c224@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Mar 2019 12:16:59 +0100
Message-ID: <CAOj+MMGBaoy1u+LRXkVTvy11SSXxm1a0QM4F+5qDPb2udUKf3w@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: lsr@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004642d905837f3f7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RAlDBASDRwr5lpjONCxOlpRkIf8>
Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes
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 11:17:13 -0000

Hey Peter,

Yes I was not so much asking from the perspective of the node which does
not support it. I was more curious if his directly adj neighbor will be
smart enough to treat such node rigth.

And precisely to that point I have tried to indicate that if this is by
design there is no point of including those 100s of TORs in constructing
and distributing flooding graph.

But spec seems quite silent on such deployment model hence the post.

Thx,
R.


On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak <ppsenak@cisco.com> wrote:

> Hi Robert,
>
> On 07/03/2019 12:00 , Robert Raszuk wrote:
> > Hi,
> >
> > My reading of draft-ietf-lsr-dynamic-flooding indicates that said
> > document in number of places rather assumes that entire topology (entire
> > instance) supports dynamic flooding (perhaps other then bootstrap phase).
> >
> > Let's observe that there can be lots of L3 TORs only dual attached to
> > access routers which will not benefit at all to be part of the game.
> > Moreover those TORs may be from different vendors and could support link
> > state protocols without any dynamic flooding extensions.
> >
> > So the question is if the proposal considers a case where only part of
> > the fabric in single topology, single area/level, single LSDB etc. is
> > aware about dynamic flooding protocol extensions ?
>
> sure, see section 5.1.2.
>
> If the node does not participate in dynamic flooding, it will use
> standard flooding mechanism. This means that the flooding may be less
> optimal, but nothing would break.
>
> If you wan to be extra smart, your algorithm can even take the node
> participation into account and compute the flooding topology with that
> in mind.
>
> thanks,
> Peter
>
>
> >
> > Let's also observe that In any deployment such state when some nodes are
> > enabled and some not for dynamic flooding can happen during migrating
> > phase or operator's errors which one would assumed must be handled
> > correctly by the protocol.
> >
> > Many thx,
> > R..
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
>
>