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

Robert Raszuk <robert@raszuk.net> Thu, 07 March 2019 11:01 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 69F8A130F67 for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 MTiLMUJJwuHo for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:01:08 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 75E3C13131B for <lsr@ietf.org>; Thu, 7 Mar 2019 03:01:08 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id a48so16512760qtb.4 for <lsr@ietf.org>; Thu, 07 Mar 2019 03:01:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=u1hhN2TgddDp/ywDasHLCoBFYutp4Xw2x4n6R1KRNaY=; b=b5+i/DrkG2taLb6zCChZEhvrVwdRa0727ond7553zBIjowob4HFEBBtwxdJMb96ReT mpRIi73pp09z++paE0hcKuccBPMTAOI99qqWTMN1BtaRRIiIOdft9tDIocQaQxmZe5ic 9/+F/3QL89JstVH9z8ntZZHDzjN6LziwGJkoFvF6YjryYll3HByxaixvNPTP4F1xOsiS ePpHYvWtqGhrApRUfJxjlyv1OWQ3hFGQhQokEIsjYO9cKqpkJxPykBo+4S04OCo7VAnZ MIKC10x69cxWFAU3xYv/rwUiDmAXue08RxYzHoRwbIHSv/to2YQnUtiBZumtymnVfCJV 5Xyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u1hhN2TgddDp/ywDasHLCoBFYutp4Xw2x4n6R1KRNaY=; b=sWXyice4so0QRaI4hLh7KYEh8M9G0jfcj7eUTLUg6jFXHIE0vobz6fNK0Tgd05++mZ B3SDaLhsMAAQYKAWgtIibbqkcpNxeL/u8NgDC8dHHDrAgRotS1d4R889xU0ZPTg2Llt8 ovcXq7Uyqzk5qc1QKGkCPSN/XRvBZG/xx1BKS9hHnXhnO+iLYuMabzc/oaesf4juHLfe wHLYQaoPTjcHiNLRX3rdnoQ5CCurbsETc/e6+9PjEr+cgAnTRutmz8l6y3j+WsVq0V3w wlSDcqhBzLXrK1wHsGHMgWzzQOg7StzlGxyKckvuam3YGfHagdt6hSmrHQz8862yxn6m ubIQ==
X-Gm-Message-State: APjAAAXRcN+bA6hDccqFu86jwfndM3c00ZFsZbbkLacdGjNaiFh3I45e q/IHg/CyK412+v0k0HK2YN7ojlXEC7KLylWdc7g2XaluliU=
X-Google-Smtp-Source: APXvYqxuRuRiq1pHlpVyi85WQlAIkYo+jCnx2wK/asxQjhfRpSKXbMMCYBrZW58D2QcfdmvwXIdorsJhdnDO89TEclM=
X-Received: by 2002:a0c:99e2:: with SMTP id y34mr10249542qve.18.1551956467191; Thu, 07 Mar 2019 03:01:07 -0800 (PST)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 07 Mar 2019 12:00:57 +0100
Message-ID: <CAOj+MMGLC7S+Lz+2MtABniBqx9BA_cyeqUhR12SvUJn3ibWZUg@mail.gmail.com>
To: lsr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ef245d05837f0515"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/DteyMu8_dCKFBXO84lh-1Ze9pWk>
Subject: [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:01:15 -0000

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 ?

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.