IETF Logo Mail Archive

[Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction

Huaimo Chen <hchen@futurewei.com> Wed, 29 May 2019 05:27 UTC

Return-Path: <hchen@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 1F43412008B for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 22:27:36 -0700 (PDT)
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 (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 Kkkkc-K6a9sf for <lsr@ietfa.amsl.com>; Tue, 28 May 2019 22:27:34 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700091.outbound.protection.outlook.com [40.107.70.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52E112002E for <lsr@ietf.org>; Tue, 28 May 2019 22:27:33 -0700 (PDT)
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=Fgyqfa0XtAQCEUOBAN61K226VXc394RyBQnyAgPZpqY=; b=I0Ly4sYXk9csrelf0GPsCEJvM8WuBeikU7CQhMn/4IQiwCsS8WegWExl7FP+gbn9PiNiBxoL7Szo/j45g7TUZnrfuvWE10CD6GI2Ep3+6f1JzEJNJNn/RqwsgmINzpmK+3Fmv5rciyhMCsPLAW5nq5yps6moRJanR7JlMCWomjc=
Received: from MN2PR13MB3470.namprd13.prod.outlook.com (10.255.237.83) by MN2PR13MB2830.namprd13.prod.outlook.com (20.178.253.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.9; Wed, 29 May 2019 05:27:29 +0000
Received: from MN2PR13MB3470.namprd13.prod.outlook.com ([fe80::b125:6fc1:69df:68b1]) by MN2PR13MB3470.namprd13.prod.outlook.com ([fe80::b125:6fc1:69df:68b1%7]) with mapi id 15.20.1943.015; Wed, 29 May 2019 05:27:29 +0000
From: Huaimo Chen <hchen@futurewei.com>
To: Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Enhancement on LSDB re-synchronization in Flooding Reduction
Thread-Index: AQHVFd2Sd2tSt/EFbEy5UvGTISEsLg==
Date: Wed, 29 May 2019 05:27:29 +0000
Message-ID: <MN2PR13MB3470EE59960F465D7AAC21D4A31F0@MN2PR13MB3470.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=hchen@futurewei.com;
x-originating-ip: [12.111.81.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 96ea8539-7b13-4c64-dae0-08d6e3f65804
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB2830;
x-ms-traffictypediagnostic: MN2PR13MB2830:
x-microsoft-antispam-prvs: <MN2PR13MB283067604964D74050F56C44A31F0@MN2PR13MB2830.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0052308DC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(136003)(396003)(39850400004)(346002)(199004)(189003)(52536014)(7696005)(5660300002)(110136005)(99286004)(86362001)(14454004)(25786009)(9686003)(66066001)(2906002)(6436002)(53336002)(33656002)(68736007)(66446008)(71200400001)(26005)(73956011)(81166006)(81156014)(8676002)(7736002)(71190400001)(6606003)(2501003)(256004)(19627405001)(476003)(55016002)(64756008)(316002)(6116002)(3846002)(53936002)(66476007)(486006)(6506007)(66946007)(102836004)(8936002)(66556008)(508600001)(91956017)(186003)(54896002)(76116006)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB2830; H:MN2PR13MB3470.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: RKh/70rU0954KCI89mYZWqWIRruzBO2LxIfgdqemaoTU0061xkZQruqPVEUzdtTVLcldEvXtzOB6Q141OuWzTLKUHmhiQPiQPAg6Yb4mXlRhkrL1v/UaZXNkWHTNUYcZKTqy8VlAV0gDDmL0pZiJfRfFt64e91Lid5CkjWL9zriYI2BeFjw8fgPsWUnIBGLhlyqfTQBAn3cl0PXQoZPD6i5ad18AQ0/DkChqwNolt275F+AjtM+IVdIxDR/FMTAj6F6OsIlND0chjqTBgP2rg4VYREeQpGiNuY99Wl1VCda9uBR1G4MNHU9IRq7Fk4wLmX7IMEdCzHIkNCMdvxI3DTfsETksclpA6iVHNLGvGQNnuatahlBBcCFPnJVJhHHj8mXq3uzbduFkkmP2R54aVvTvqEO2dRAMzykK1fnjydg=
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3470EE59960F465D7AAC21D4A31F0MN2PR13MB3470namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96ea8539-7b13-4c64-dae0-08d6e3f65804
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 05:27:29.6297 (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: hchen@futurewei.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2830
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/S5c1wGXWdcQH-brT1TD7PbIcER8>
Subject: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction
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: Wed, 29 May 2019 05:27:36 -0000

Hi Tony,


    A possible enhancement on LSDB re-synchronization is described below for discussions.

    The current method: Whenever an existing link/adjacency L is added to the flooding topology (FT for short), a full LSDB re-synchronization is requested and executed over link L. Even though the adjacency between two end nodes over link L is already there and their LSDBs are the same in most of situations, the full LSDB re-synchronization is executed, which consumes the power for processing IGP messages and the link bandwidth for transferring IGP messages. This may cause some issues if some links are added to the FT frequently.

    Considering the cases where the LSDBs may be out of synchronization around the time period from a link on the current FT down to link L added to the FT for some reason such as a new FT computation. This period should be short in general.

    Method A: Let one end node of link L send the other end node the LSP/LSAs that are changed during the time period.

    In general, the LSDBs are mostly synchronized among some nodes (i.e., the number of LSP/LSAs changed is mostly zero) when link L not on the FT is added to the FT. In this case, Method A almost does nothing, i.e., there is no link state with changes that needs the end node to send its adjacent node over link L.

    Method B: Combine the current method with Method A. If the number of LSP/LSAs that are changed is small, then use Method A; otherwise, use the current method.

Best Regards,
Huaimo

v2.23.0 | Report a Bug | By Email