Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Yingzhen Qu <yingzhen.qu@futurewei.com> Fri, 05 June 2020 22:25 UTC

Return-Path: <yingzhen.qu@futurewei.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 5ACFB3A0EC0 for <lsr@ietfa.amsl.com>; Fri, 5 Jun 2020 15:25:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 4Cow_mhTnzIn for <lsr@ietfa.amsl.com>; Fri, 5 Jun 2020 15:25:13 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2117.outbound.protection.outlook.com [40.107.237.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC27E3A0E95 for <lsr@ietf.org>; Fri, 5 Jun 2020 15:25:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ORnegfB6TSis1xNZlYnQ3m72H5GvY99L6Y4CZfkV3D1G+j61iDmTm4Sp43s28RbrKO/aC8x5HhzbR/8r5swydzeOsZ89XOzVTdoxQ6s14zKuqP7L+0E7abhqtw83g1Igw9Oo3GL8U8rLiAPJXatwa9vlRYyCogXPqU8KgGsijDzXemRbdOl74PrPWHwqz7Za+A6yR90oH7XQfEF73omXQgjNk636RZkML6r5hXzwm+XuG6/I0MpazFhPVslMjnSvfX13un/jcmqeZP4ym3lQNxPBfcnzyQJUyOGbVlA7ZSylbvxdsPIkwYc6gYFNiR6pwjhwOUAi6CseXGkCamqi7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IbFf3qwiFomaJRkU7HLezrRIjSuTRAXPlsonoNaRPAc=; b=Xeq3lbD6BgDxriBpkdecwUdxyg0K2glaNEpImKljo2xhCG57SS1HtCi+9EQZvvleweGoNRF2q8Dx5DFg0BuQZ8U323+UXPC1EJPP8pmtTtC7VKKj2ObCR4h9oJbXTYK/K1vayKUaAeZ3vYDNnZVS/uBuF9nCr19fg14q/7tn4zMl09By27JQhna1iPhW3s+Q5wLpe5ARqq8pyK+nCzlHoHSbjXbH3mssaMU6unlUpFulu9UlN5uSvZUNZpVHrirWFczRV759jNBpVMKKzLt1dNht/8D/A8JSI91BW59SsSUg8KlP2MHHVeJaceXgPPNFPGoFmUReFuTUCfDLP3dS3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IbFf3qwiFomaJRkU7HLezrRIjSuTRAXPlsonoNaRPAc=; b=E9X+Kp8CfstZHzkINaepLWtwffQNMLOSilXePHQakjrKNJXc+BPnGljV5IjLnOVIoKg98ZZsCtExNyiGqBbi3UgwcLYRZTfKitA5g62/nUC4258g/rFvk2NPEifablEAG4IU9ylg/wXA5swX0TD1J4kIETGa/ZvPT+KMMY3u8Dw=
Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB3126.namprd13.prod.outlook.com (2603:10b6:a03:189::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9; Fri, 5 Jun 2020 22:25:10 +0000
Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::28f0:8a33:3418:b39b]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::28f0:8a33:3418:b39b%4]) with mapi id 15.20.3088.000; Fri, 5 Jun 2020 22:25:10 +0000
From: Yingzhen Qu <yingzhen.qu@futurewei.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>
Thread-Topic: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Thread-Index: AQHWO1m9yw++VQZRYkaPzDWvpZxjvKjJ9X6AgACcEID//5K8AA==
Date: Fri, 5 Jun 2020 22:25:10 +0000
Message-ID: <B6D0FFA4-560B-4015-853A-54BB468B04F2@futurewei.com>
References: <7B1E9ED7-F2B6-45AA-9E64-AD9E5B439D02@cisco.com> <8FACDF6D-B0E7-4EE5-B568-A32450D8BA5F@futurewei.com> <89CC2518-AAE7-4CA2-9910-C56EBD8A2200@tony.li>
In-Reply-To: <89CC2518-AAE7-4CA2-9910-C56EBD8A2200@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [2601:646:9500:c900:a0f5:a272:5138:6a1e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0e916d90-5653-4cac-2b77-08d8099f4ef1
x-ms-traffictypediagnostic: BY5PR13MB3126:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR13MB3126E768E66E4F731D817373E1860@BY5PR13MB3126.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0425A67DEF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nID75rDOGWzAzGviTEMF1FeEsRSD8x2/n0mB32BrZ9tHlt8VaeSRyC8pYCWEGyNxnOVENsPTAuVRQRYCJLMG9vjU9ArsAnO9fLu+HDCF5LZa5nNVoCDy51cus3JSRim1v+SvdptG8iFu7PeaVbfa5+Ob0tjeuTTvZTw6BkjbYNrjFOjK5IBV9J6KmFb0dnn2BOrXnDPcMf9HaNQ6XFMxlJg8Dkv6/iBaDI6b2epS7uPzSQFOpOynJgbgzoFMtc9fVT/FjCyxVgv9Qi6J+9WE9mdokeFD822wLqsj5pMHaMg+qX2XnSYPbail2FPVWgF4MS9cNOW+Udf6FE8hEoFUew==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39850400004)(366004)(346002)(376002)(36756003)(186003)(107886003)(2906002)(9326002)(6512007)(4326008)(6486002)(2616005)(6916009)(8936002)(8676002)(66556008)(54906003)(66476007)(6506007)(53546011)(44832011)(33656002)(316002)(83380400001)(71200400001)(478600001)(66946007)(64756008)(86362001)(66446008)(76116006)(5660300002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 31uYoZZ8DLKXwvYpuXuGcHqQNVvJCsrjJKneqy+CGUI5p/ZxE+EZzYMWVae9gPTcqyS/GtJRAQreIw8yteCgFSoSQACXjhitHL4ainnj8AhxVr1HOWlq0iPXUJUrzhE7VpaZHZgtoOyFJOVXv9BN3PX0SydifO0MNIrtyW9xeRFnW3q06HdJYBsdRdes5QFyRvIx5Z5asL1Y5Pzm2bArJA5J6OTEgappIzIXPzbiYxLHsXWs/2GGa5IImTIFnEE6egd5gKi1FtFd7Y+j9afFw1fCJK7xQ36PvL237Ym/MLQwCJOGInhI0pGNcuuryq7f6kjs2jzTrBl4aavPOTqVVg2ljVCNjXuQDPWiT9lbsaIcVAZOBDdXjPDn4GtXn1PES3oP6xlFemiS8pkYFUECgzqjQKz7qivjyKOm4EeBgvgOHWRA+dizDvwRsjLKHE+A3m3eytlr28A0WHA4NBqj3fAO4kqlJqB3bIS/v0xP7/30F9hJKGxCUal4Hj7FpsKKZKzFVlaLojpBU7WF0d3AF1AspdaR/GlQ4WKwpFjeY6+BY6FO8LA1hweT+1eiwPnS
Content-Type: multipart/alternative; boundary="_000_B6D0FFA4560B4015853A54BB468B04F2futureweicom_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e916d90-5653-4cac-2b77-08d8099f4ef1
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 22:25:10.0783 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: whgOU1IEQmBdnWCnArEWK81BZ7lN8Qz4AYxdFIHzvXYkY0dTWEiPObF9gwf+FAjhB7UQw2b44dbMgIkR8zsJVQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3126
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/A2ws6P3UcDS6SDZjYP_g2SglODk>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
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: Fri, 05 Jun 2020 22:25:14 -0000

Hi Tony,

Thanks for jumping in and the explanation. I support the idea of tradeoffs between pefection and simplicity. Analysis about the change of topology can be tricky, especially when adding links, and for a distributed algorithm it’s more important to achieve a definitive result. Maybe it’s easier to optimize some cases in a centralized-mode, but we always need to consider benefit-cost ratio.

The text in the draft is “MUST be”, so I thought I’d ask to confirm.

Thanks,
Yingzhen

From: Tony Li <tony1athome@gmail.com> on behalf of "tony.li@tony.li" <tony.li@tony.li>
Date: Friday, June 5, 2020 at 2:56 PM
To: Yingzhen Qu <yingzhen.qu@futurewei.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>rg>, "lsr@ietf.org" <lsr@ietf.org>rg>, Huaimo Chen <huaimo.chen@futurewei.com>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I have a question regarding the draft. At the end of section 3, it says if there is any change in the base topology, the flooding topology MUST be re-computed. So in case of a link failure in the base topo, it’s possible that the link is not part of the flooding topology (e.g. one of the multiple links between two nodes), it might be optimal if we can figure it out and save recalculation here.


This comment isn’t specific to this algorithm, so you’ll pardon me if I jump in.

Always recomputing the flooding topology is always a safe thing to do and for the case of a distributed algorithm is probably the safest design choice.

Doing the analysis about the change is not exactly trivial and computing the flooding topology is not that hard.  We are typically not short of CPU cycles and recomputing the flooding topology is outside of the critical convergence window, so while there is some theoretical benefit, it’s not at all clear that it’s of great practical benefit.  But it is up to those specifying the algorithm.

Regards,
Tony