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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 29 May 2019 11:47 UTC

Return-Path: <acee@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 62A0F1200E3 for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 04:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-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 header.b=PQ2NQQB3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Qu+8J9na
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 IbbPl1y0FGpO for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 04:47:46 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F2B12006A for <lsr@ietf.org>; Wed, 29 May 2019 04:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15225; q=dns/txt; s=iport; t=1559130466; x=1560340066; h=from:to:subject:date:message-id:mime-version; bh=LRPaCB0FxNeJnDZQ2C09P7cB8Rb92TD25wg+PSzIbF4=; b=PQ2NQQB3L8npIqFuwUP4tbGhWPDPtGP8wTKw0LF/eFYdDX/MtOU8+zss dxfqqN0+GIxzpRTMSMDxR1ArAkADsbva+2Vp/dnSYjimHvBLG+NQyBdbn mqTmVkI/AeqmjehA6kjYamL3GZQPQ+3QVR1rbzIDn3kq/fdaAR//exDlE 0=;
IronPort-PHdr: 9a23:NlWxMxAjYX2mIKkGAlSZUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUgMdz8AfngguGsmAXETwIfPCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CQAAAacO5c/5xdJa1lHQEBBQEHBQGBUQgBCwGBDi8kLANpVSAECygKhAmDRwOEUoofgjIlklyEUYEugSQDVAkBAQEMAQEjCgIBAYRAGYJbIzQJDgEDAQEEAQECAQRtHAyFSgEDAxIRHQEBOBEBCA4DAwECKwIEMB0KBAEJCSKDAAGBHU0DHQECDJ4UAoE4iF9xgS+CeQEBBYFGQUCCQxiCDwMGgTQBi1IXgX+BEAEnDBOCTD6CYQIDAYFBPAYHgl0ygiaOD4RjlXIJAoINhjiMZxuCH4ZpjUuMdYcGjnsCBAIEBQIOAQEFgU84gVdwFTsqAYJBgg+DcINGgU6FP3KBKYt9AYEgAQE
X-IronPort-AV: E=Sophos;i="5.60,527,1549929600"; d="scan'208,217";a="561724789"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2019 11:47:44 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4TBliZI024673 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 May 2019 11:47:44 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 May 2019 06:47:44 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 29 May 2019 06:47:43 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 29 May 2019 06:47:43 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LRPaCB0FxNeJnDZQ2C09P7cB8Rb92TD25wg+PSzIbF4=; b=Qu+8J9na3YTp7ip+gO5op9Q1MUWO4abJY/YAm2RvzLWKVwFfRjgDMsCybBhS+NF16R5NpqYnS3SreV5GcelMKuMh78f9atsAOBpgRsewkWPbIMwdIqP1XZI97KqZJy8Spf9tZ+YKTCXUlPTOhifofc0Qru/SzIVF7mTMnjoPc1U=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB2688.namprd11.prod.outlook.com (52.135.92.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.17; Wed, 29 May 2019 11:47:42 +0000
Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::3006:a080:19fa:623e]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::3006:a080:19fa:623e%6]) with mapi id 15.20.1922.021; Wed, 29 May 2019 11:47:42 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Huaimo Chen <hchen@futurewei.com>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction
Thread-Index: AQHVFhRS0epP767G40Gu39MaZrqYfg==
Date: Wed, 29 May 2019 11:47:41 +0000
Message-ID: <94860848-4E06-4786-815F-92834A1953E4@cisco.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=acee@cisco.com;
x-originating-ip: [173.38.117.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7dbed0aa-4c1a-46cf-f5de-08d6e42b7536
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR11MB2688;
x-ms-traffictypediagnostic: SN6PR11MB2688:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <SN6PR11MB2688B9F937DF5F477B845971C21F0@SN6PR11MB2688.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0052308DC6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(366004)(136003)(199004)(189003)(81166006)(53546011)(6506007)(36756003)(54896002)(102836004)(186003)(81156014)(2616005)(476003)(68736007)(26005)(53936002)(236005)(6306002)(6512007)(7736002)(5660300002)(8676002)(6436002)(86362001)(316002)(110136005)(99286004)(2906002)(606006)(2501003)(486006)(6246003)(71190400001)(71200400001)(83716004)(229853002)(478600001)(6486002)(966005)(82746002)(25786009)(33656002)(3846002)(8936002)(64756008)(66066001)(6116002)(66476007)(14454004)(66556008)(76116006)(66946007)(73956011)(256004)(91956017)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2688; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: K0gMrt8JBkEuQa2Cvj7NBwj2QLBb3lxVow0FCy3cfcshZwRmgQcVUVXCduqwjkf6DT87ntt8sVLoZZRcZxWWQg28WdfN1IquM9q+GNO2G9I3aKJwbQKen/CdGWSSHY7xcTIMs9EdIjW8jgakJLXJxocXjPwXS0N9Kv2EPIW0hykMD1N4Tu0DRwV3mMhC4VXgQLE3UmMIu3MKroe8bojyojf0embJ6zaALcB+V4btmif7OxUbDX+t4IHeUTOFdCGcOniJ65Svh2P8d16cq+26Hx6zVIRqjYcrf7N8uM2gNnU3Svx3bTAELppXb94sWWtdOqnsfBXOKlDwOV4AAR+dfpcFzojRwBExKREAyy4ofykafVChgAdKzGGqdloxPrPXfWsBsBGc/mQXE1Hg98D7bHrO22BlMCBX1Sk592xO+ww=
Content-Type: multipart/alternative; boundary="_000_948608484E064786815F92834A1953E4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7dbed0aa-4c1a-46cf-f5de-08d6e42b7536
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 11:47:41.8567 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: acee@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2688
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/U4e9J-5jHeW9xXJurIVxuNABFyg>
Subject: Re: [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 11:47:49 -0000

Huaimo,

There have been various proposals for reducing DB synchronization over the years. This is not a new idea and let’s not mix it with dynamic flooding. As Tony replied, the IS-IS and OSPF mechanisms only specify the LSP/LSA headers to determine what has changed. Unless you do something similar, you don’t know how to “send the other end node the LSP/LSAs that are changed during the time period.”.

Note that while there have been many proposals, AFAIK, this optimization is the only one that was standardized - https://datatracker.ietf.org/doc/rfc5243/

This is out of scope for dynamic flooding. If you wish to pursue this as a independent item, please look the previous proposals and list discussion before retreading old ground.

Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org> on behalf of Huaimo Chen <hchen@futurewei.com>
Date: Wednesday, May 29, 2019 at 1:27 AM
To: Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Subject: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction


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