[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.
- [Lsr] Clarification on co-existance of dynamic fl… Robert Raszuk
- Re: [Lsr] Clarification on co-existance of dynami… Peter Psenak
- Re: [Lsr] Clarification on co-existance of dynami… Robert Raszuk
- Re: [Lsr] Clarification on co-existance of dynami… Peter Psenak
- Re: [Lsr] Clarification on co-existance of dynami… tony.li
- Re: [Lsr] Clarification on co-existance of dynami… Robert Raszuk
- Re: [Lsr] Clarification on co-existance of dynami… tony.li