Re: [Lsr] Flooding Negotiation bit

"Acee Lindem (acee)" <acee@cisco.com> Fri, 17 May 2019 13:36 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 A44C5120198 for <lsr@ietfa.amsl.com>; Fri, 17 May 2019 06:36:44 -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=kH+nrUCN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iwMZau6u
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 MZwuN06C3n9s for <lsr@ietfa.amsl.com>; Fri, 17 May 2019 06:36:40 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5933120363 for <lsr@ietf.org>; Fri, 17 May 2019 06:36:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34679; q=dns/txt; s=iport; t=1558100200; x=1559309800; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QGj3ccgq9kzR/tohkmIaFLC7SgsIzNVk9vIuEH26uh4=; b=kH+nrUCNGjdOxrvcTfnVmWcmepqAlQbu1zhfSudAuhPm5ZzFzYtv2t5b vcNOqratGB/fGQWPTh0HBVHf8k4kau8Izl43MLsprsxdhNmAF2QppwTRC ID+gf/Y6MvbsLXc+MnPPyXYi7jFT/6tshb/c9eWfodHZ6ekpVdcmk93Sq U=;
IronPort-PHdr: 9a23:fzo66h805m2Tav9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh4Bh98RmlkpC8OIIUb6N/XtKSc9GZcKWQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAAAUuN5c/4wNJK1hAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYEOLyQsA2lVIAQLKIQSg0cDhFKKIoJXiUCNZ4EuFIEQA1QJAQEBDAEBGAEKCgIBAYRAAheCHSM0CQ4BAwEBBAEBAgEEbRwMhUoBAQEEAQEQER0BAQciAwsBDQICAQgOAwMBAiEHAwICAhkGBgsUCQgCBA4FIoMAAYEdTQMdAQIMnnwCgTWIX3GBL4J5AQEFgTYFg0sNC4IPCQWBLwGEZAKGaheBf4EQAScfgU5+PoIaRwEBAhiBFAELBwElEQkBBQcJEYJDMoImi2KCE4Rdh2GNAiw5CQKCC4YuhEGEMINcG4IdhlWKHoMIkzqBU4x7AgQCBAUCDgEBBYFPODYwcXAVOyoBgkEJggaDb4NGgU6FP3IBMXeMBw8XBIIoAQE
X-IronPort-AV: E=Sophos;i="5.60,480,1549929600"; d="scan'208,217";a="274533060"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 May 2019 13:36:36 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x4HDaakT002377 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2019 13:36:36 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 May 2019 08:36:35 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 May 2019 08:36:35 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 17 May 2019 08:36:35 -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=QGj3ccgq9kzR/tohkmIaFLC7SgsIzNVk9vIuEH26uh4=; b=iwMZau6uc47eBoksDtT4F4/t0Vuhetf5hdaNDlKwjXUQL9MFbb2SLxOKNQYpu66BExWbuGkPnUf7GdKOX/QB6TWHXjoDthroQcIuVf9wKkOqGJudVYcompJpq2i4ti4xDmQBk61jVj+mjRU5XMwWpJRYRPrnqh1YvtM62OdMshU=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB3263.namprd11.prod.outlook.com (52.135.112.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 13:36:33 +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.1900.010; Fri, 17 May 2019 13:36:33 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: Huaimo Chen <huaimo.chen@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>, "tony.li@tony.li" <tony.li@tony.li>
Thread-Topic: [Lsr] Flooding Negotiation bit
Thread-Index: AQHVCsF/BMatt1q1Y06ZcbcK1ON6G6Zr9SWAgAL6VACAACMKgA==
Date: Fri, 17 May 2019 13:36:33 +0000
Message-ID: <1501F6B7-DAB5-463D-A1E6-D2406FC641C1@cisco.com>
References: <5316A0AB3C851246A7CA5758973207D463BB69D9@sjceml521-mbx.china.huawei.com> <C9C79F82-D68C-4843-91EF-2EC38833C51F@tony.li> <9A7C5531-EB4F-4FBB-B984-2E430939A4A8@gmail.com> <A35173A2-E146-456B-8459-52206F0FB0B5@cisco.com> <CABNhwV0ojMVNQ9M3kSUJ+-33nQoBsrOhtYo-7gp4dehz-m-HPw@mail.gmail.com>
In-Reply-To: <CABNhwV0ojMVNQ9M3kSUJ+-33nQoBsrOhtYo-7gp4dehz-m-HPw@mail.gmail.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: [2001:420:c0c8:1006::748]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa24c749-f33f-465f-4d6b-08d6daccad86
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:SN6PR11MB3263;
x-ms-traffictypediagnostic: SN6PR11MB3263:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <SN6PR11MB32633696D606CD256B8FA49CC20B0@SN6PR11MB3263.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(366004)(396003)(39860400002)(199004)(189003)(446003)(54906003)(25786009)(102836004)(8676002)(33656002)(81156014)(81166006)(8936002)(99286004)(11346002)(186003)(486006)(1411001)(606006)(6916009)(6116002)(476003)(53546011)(2906002)(5660300002)(76176011)(2616005)(316002)(7736002)(6506007)(66556008)(64756008)(66476007)(6246003)(82746002)(46003)(71190400001)(53936002)(66574012)(66446008)(6306002)(54896002)(236005)(6512007)(4326008)(91956017)(66946007)(76116006)(45080400002)(71200400001)(6486002)(229853002)(68736007)(14444005)(9326002)(36756003)(73956011)(6436002)(86362001)(83716004)(256004)(966005)(14454004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3263; 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: +++K2yQy2uxrWwoDYm5xYaWQribV50VY2UieT8LimJ802EEFm3LAOw4Szidrm6C1cMQe4kjes5Daf9ctCQvZlRxVngKhDNp3VfT+IrZ6ImoglfO8+s627oVpjL+v0tbNxiyz2MB2WAo59zRJp4se+R2WHb61G6/9yar7Abgj055LNhf9tHksPlKob7004ffG6SfpZF7G/qy/6OIkzGDtd1thAYGOX2MejHgidWO7m84QVmOf53HAUIkETtrmY+cUY+QFamBGuN6ulDBKc2yt0azv30gC9hoMgMOYM8YQbS8q6TLze5Niwllc4mqIKqA8s5W/kzSSVStRIHUQTrBPmoPScbvbQHZ05skeQjIAHnLdY2uIikkUHfJwK2n7aqc7DxCydoRuUCGYPB49ks3DIKC34an7wpKJo7bv/G3BanM=
Content-Type: multipart/alternative; boundary="_000_1501F6B7DAB5463DA1E6D2406FC641C1ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fa24c749-f33f-465f-4d6b-08d6daccad86
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 13:36:33.7248 (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-Transport-CrossTenantHeadersStamped: SN6PR11MB3263
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7eS6hOvQtspOShJ4TqZV-7G-Oqc>
Subject: Re: [Lsr] Flooding Negotiation bit
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, 17 May 2019 13:36:45 -0000

Hi Gyan,

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Friday, May 17, 2019 at 3:31 AM
To: Acee Lindem <acee@cisco.com>
Cc: Huaimo Chen <huaimo.chen@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>, Tony Li <tony.li@tony.li>
Subject: Re: [Lsr] Flooding Negotiation bit


Les

We do have cases with adjacencies around around the 100 range and the process overhead is much worse for ospf with the type 1 type 2 full spf calc so the FN flood bit negotiation would be very useful so we don’t have a cascading effect that would ripple through the mpls core.  We have found that with ISIS is not as taxing with flooding process overhead with the same number of adjacencies is not as bad with flooding and definitely scales much better then ospf.

When the FN bit and a exponential back off happens on a node that rebooted and just came back online does that delay convergence.

How does this impact convergence if Graceful Restart is enabled or CISCO NSR how does the FN bit impact the grace LSA received by helper router which continues to forward on stale paths until topology change occurs at which time GR IS exited and full spf runs.  Also how does this impact LSA group pacing to refresh LSA so full SPF does not have to run on all nodes as root of tree at once.

Without a lot of thought, my take would be that link-scoped LSAs/LSPs are flooded independent of the flooding topology.

Thanks,
Acee


Gyan


Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
Phone: 301 502-1347<tel:301%20502-1347>
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

On Wed, May 15, 2019 at 10:02 AM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Gyan,
The dynamic flooding extensions are all new work and they would be optional enabled. We would appreciate your input and especially on applicability to your existing deployed networks.
Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> on behalf of Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Date: Tuesday, May 14, 2019 at 9:57 PM
To: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Flooding Negotiation bit


Is this a new option that does not exist today in OSPFv3 or ISIS.

Operators have the ability to mark interfaces as passive so only router stub LSA is generated which helps assist in full SPF calculations flooding.

Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike<https://maps.google.com/?q=13101+Columbia+Pike&entry=gmail&source=g> FDC1 3rd Floor
Silver Spring, MD 20904
www..linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
Phone: 301 502-1347<tel:301%20502-1347>
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>


Sent from my iPhone

On May 14, 2019, at 4:31 PM, tony.li@tony.li<mailto:tony.li@tony.li> wrote:

Hi Huaimo,

If I understand you correctly, this seems to have almost the same semantics as the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 5.2.7).

If I’m not understanding you, could you please clarify the differences and why the current mechanisms are insufficient.

Tony


On May 14, 2019, at 1:09 PM, Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>> wrote:

Hi Tony,

For the case you described below, in order to add one or a limited number of links to the flooding topology temporarily, a new bit, called Flooding Negotiation bit (FN bit for short), should be defined and used. In OSPF, the FN bit is defined in Extended Options and Flag (EOF) TLV in OSPF Hello. In IS-IS, the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) of the nodes connected to node N will establish an adjacency with node N. During the process of the adjacency establishment between node X and node N, node X sends a FN-bit set to one in its Hello to node N, node N selects one link/node (or a limited number of links) for temporarily flooding and sends only to this selected node a FN-bit set to one in its Hello. Node N adds the selected link/node to the FT temporarily after receiving the FT bit set to one from the selected node. After receiving the FN bit set to one from node N, the selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT temporarily after it sends and receives the FT bit set to one to/from node N; node N adds a selected link to the FT temporarily after it receives and sends the FT bit set to one from/to node Y.

Best Regards,
Huaimo

==== A case from Tony on 3/6 ====
If the node that rebooted has 1000 interfaces, which interfaces should be temporarily added?  Adding all of them is likely to trigger a cascade failure.  The TLV allows us to signal which ones should be enabled.

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
Mobile – 202-734-1000