IETF Logo Mail Archive

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Peter Psenak <ppsenak@cisco.com> Mon, 27 August 2018 12:22 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 448B6130ED2 for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 05:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 YpF6dsK1WuCp for <lsr@ietfa.amsl.com>; Mon, 27 Aug 2018 05:22:12 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A815124C04 for <lsr@ietf.org>; Mon, 27 Aug 2018 05:22:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1042; q=dns/txt; s=iport; t=1535372531; x=1536582131; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9trYSBxS/8m4I8Z6oTzCNPkH6D0WG3z1sKH8dldiMeM=; b=QBQztKb/36Eklg42v5ciYGvvQo188BHLF415iJhnUNJXdwKOqEbwzel6 W20eZx3M6+IfQWvxHhB4Y1VI+fRT1U5NyUpR074BDEXy7hVgZb4FkxxGA 45bBn5zaSuGkM2L53+W4au1Fv+rujhG6mcwQJNXNGK4ts+bBs7bYoVz3K I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BjBAD564Nb/xbLJq1bGQEBAQEBAQEBAQEBAQcBAQEBAYUzKINxiG+NUpggC4RsAoNGORMBAgEBAgEBAm0cDIU3AQEBAQIBIw8BBUABEAsOCgICBRYLAgIJAwIBAgFFBgEMAQUCAQEXhQAIomiBIA6EbIV1gQuIYoFBP4N2LoRYgyeCVwKbLAmPbxeIR4YCk0mBWSCBUjMaCBsVgySJR4cOPTCKToJJAQE
X-IronPort-AV: E=Sophos;i="5.53,295,1531785600"; d="scan'208";a="6076454"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2018 12:22:09 +0000
Received: from [10.147.24.35] ([10.147.24.35]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w7RCM9Ia009603; Mon, 27 Aug 2018 12:22:09 GMT
Message-ID: <5B83ECF1.7080504@cisco.com>
Date: Mon, 27 Aug 2018 14:22:09 +0200
From: Peter Psenak <ppsenak@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Christian Hopps <chopps@chopps.org>, Tony Li <tony.li@tony.li>
CC: Tony Przygienda <tonysietf@gmail.com>, lsr@ietf.org, Jeff Tantsura <jefftant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
References: <8F5D2891-2DD1-4E51-9617-C30FF716E9FB@cisco.com> <C64E476F-1C00-435E-9C74-BEC3053377E8@gmail.com> <2F5FDB3F-ADCA-4DB4-83DA-D2BC3129D2F2@gmail.com> <5B7E78DD.90302@cisco.com> <172728E8-49E6-4F43-9356-815E1F4C22E7@gmail.com> <5B7FCAB3.6040600@cisco.com> <3D1DEC37-ACE7-4412-BB2E-4C441A4E7455@tony.li> <CCF220A3-8308-47B8-8CC6-1989705FF05C@cisco.com> <CA+wi2hNv8AVyR81LRmJ=Pd5_p5rS2djCOjY9YDgKxG=KEO_MkA@mail.gmail.com> <39509D13-4D2D-49A9-8738-C9D1F7C54223@tony.li> <3158427D-B667-4F3B-82DF-FD022074ED27@chopps.org>
In-Reply-To: <3158427D-B667-4F3B-82DF-FD022074ED27@chopps.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.147.24.35, [10.147.24.35]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/goow4Xkl8ds7kpedsjCX_Ut29dw>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 27 Aug 2018 12:22:14 -0000

Chris and All,

On 27/08/18 14:10 , Christian Hopps wrote:
>
>
>> On Aug 24, 2018, at 12:29 PM, tony.li@tony.li wrote:
>>
>> Being distributed would be very nice.  However, that implies that all nodes are going to get to the exact same solution. Which implies that they all must execute the same algorithm, presumably with the same inputs.
>>
>> That’s all well and good, but we don’t have an algorithm to really put on the table yet.  We need experience with one.  We know we want to tweak things based on biconnectivity, performance, and degree because doing it right day one seems unlikely.  Changing algorithms is going to be VERY painful if it’s distributed.
>>
>> However, if it’s centralized, it’s completely trivial.
>
> I find this reasoning quite compelling.

I would leave the door open for both and not limit the solution to one 
or the other.

As an example, draft-li-dynamic-flooding-05 supports both centralized 
and distributed mode of operation.

thanks,
Peter


>
> Thanks,
> Chris.
>

v2.23.0 | Report a Bug | By Email