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

Peter Psenak <ppsenak@cisco.com> Thu, 07 March 2019 11:11 UTC

Return-Path: <ppsenak@cisco.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 2F41A131312 for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qV9HyjX-YcCZ for <lsr@ietfa.amsl.com>; Thu, 7 Mar 2019 03:11:35 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B579130F67 for <lsr@ietf.org>; Thu, 7 Mar 2019 03:11:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1576; q=dns/txt; s=iport; t=1551957094; x=1553166694; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=mB5Dlsay46me6vBEbjcmd4kuJCS2NJltGfUXRX3nynI=; b=Con9pb2/FS141AWy0OATjT088fP/dcc9V48dozuneU1SZVrrw+S7r61v KQXbWFAjy3NVsjFKg+4Bj92J16o+n+OSmpMeSDIhciSNAjHgXVnjSf0xF 7PhFtqJ46jHeITIc5rSvl4s72ywmJIANqvRvQCx7NHeVkniM5ofQh5pfR 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAABL+4Bc/xbLJq1kGgEBAQEBAgEBAQEHAgEBAQGBUgQBAQEBCwEBgnZxEieNAowyJZgjFIFnDRgLhEkChFc1CA0BAQMBAQcBAwJtHAxCAQ4BhHgBAQEBAgEBATY2GwsYFRknMAYBDAYCAQGDHgGBbQgPq3iFRIRjBYEvAYtCgUA/gREnDIIxLoMeAQGBHIEEhSICihWHIpJeCZJ/BhmLAIg1inGSX4FJATWBVjMaCBsVO4JsghYXE4hMhUA+AzCCIYtwAQE
X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208";a="10598936"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Mar 2019 11:11:32 +0000
Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x27BBWJo018373; Thu, 7 Mar 2019 11:11:32 GMT
To: Robert Raszuk <robert@raszuk.net>, lsr@ietf.org
References: <CAOj+MMGLC7S+Lz+2MtABniBqx9BA_cyeqUhR12SvUJn3ibWZUg@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <ceec44ec-b66c-6644-2bc4-aaf09225c224@cisco.com>
Date: Thu, 07 Mar 2019 12:11:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMGLC7S+Lz+2MtABniBqx9BA_cyeqUhR12SvUJn3ibWZUg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LVDubQL12hrxUoGY9n9t_wodtws>
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:11:37 -0000

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
>