Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 12 March 2019 04:28 UTC

Return-Path: <ginsberg@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 D0FC7130E83 for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 21:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, 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, URIBL_BLOCKED=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=NIIavYzL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DQ47oisj
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 voiWRrzsbsxm for <lsr@ietfa.amsl.com>; Mon, 11 Mar 2019 21:28:14 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C028A130E6F for <lsr@ietf.org>; Mon, 11 Mar 2019 21:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19328; q=dns/txt; s=iport; t=1552364893; x=1553574493; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5dFF6QLEEkR9cCHMWzUonFtCSBMXzBn1H9LJIUSSXGg=; b=NIIavYzLJFN/wTX1+B1OPNs6dM+6kp6syd8g7fpXM4gVk7ES/ZFcBPLX /Ta5w4xU9nM1eN1PoTWwRtfvJj4s/gAb2YUksB1adPaZoadhVGNaZizp9 ilsYyyApQMKMDT6DCUM7A/7lq7HU+L26RIrxXeZ2NrT+7gjO6aU7myCRk U=;
IronPort-PHdr: 9a23:PUq48hSvav7vVrOj5OMAk2/va9psv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiM7Gt9IWUVq13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BZAADRNIdc/5NdJa1kHAEBAQQBAQcEAQGBUwUBAQsBgQ0vJAUnA2h0BAsnhAqDRwOPPUqCDZI1hXWBJANUCwEBLIRAAheEIyI2Bw0BAQMBAQkBAwJtHAyFSgEBAQQjChMBATgPAgEIEQQBAR4NAgICMB0IAgQBEgiCT0yBEUwDFQECpTcCihRxgS+CeAEBBYUaGIIMCIEvAYssF4FAP4FXgh4uhQODCDGCJooXgjqECIIBkVIJAotOh1qTO4p5kk4CBAIEBQIOAQEFgU4KJyiBLnAVO4JsggqBIwEEgkaKU3KBKIxOKoIjAQE
X-IronPort-AV: E=Sophos;i="5.58,469,1544486400"; d="scan'208,217";a="242965412"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 04:28:12 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x2C4SChV013193 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Mar 2019 04:28:12 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 23:28:11 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 23:28:11 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Mar 2019 00:28:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dFF6QLEEkR9cCHMWzUonFtCSBMXzBn1H9LJIUSSXGg=; b=DQ47oisjeoB4ZKfpR+hrsK0IMlXoVT79mx25pia3oVapcfCUV58jxODshYaVyZjg607hXrtxy58lvTPeQ9ukP3YA/SbC19fj9a4/22LdnFHb9ARtZFHsNjgrkLAasF+vszoJ4Nj8GTUL1nxn8C5iBLmPD8VuQpcSD3b9N61RsJw=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3669.namprd11.prod.outlook.com (20.178.237.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Tue, 12 Mar 2019 04:28:09 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 04:28:09 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Temporary addition of links to flooding topology in dynamic flooding
Thread-Index: AQHU2FFk2gptIB0Z+EmsBAKlm+uXmKYHXhhw
Date: Tue, 12 Mar 2019 04:28:09 +0000
Message-ID: <BYAPR11MB36388B5D52641053E327A084C1490@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAOj+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@mail.gmail.com>
In-Reply-To: <CAOj+MMHwJW6=SQ+_VSTUqwOWDv=+vkg-TTncA5PEczkAn-bdUg@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=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1002::181]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c30c4430-1ddb-4c5a-85d1-08d6a6a321f5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3669;
x-ms-traffictypediagnostic: BYAPR11MB3669:
x-microsoft-exchange-diagnostics: 1;BYAPR11MB3669;23:fY7snwQG6ZIQiSGt4gwdsYMVnvF/cjWfcTmfJGu2XOw2SPuZvlqwXhRgw9fO0mMjq+dj/i0exAjYvace48ofKkrnJocb3oRl1rPLgBaCLyfXbG2v1xRU9IIi+/XPwkMmEWzKk/6muA0Vkf7VxHOmlgr2ESu642l6O8eOMBdN/pOIVE1hywaIzNLrhBkai0fJTR/8JZ3Q19n7KaDkFFVe1xDdCweU80UDDKtOHgz1kIVCiFVnRQLz8RFQYAp8pBti0KHNgkH7J+PbI6Unz99ioYieIMTBOuKZc/1QsUR6/ifOsVSUPZfjcKG85sAhGYrzU/7JngchcRfMPQydnkf9fUduLYA1NOi9vQRzM2IIpVFu71uWLgEG+qmufoLtCUY96zzwMMka6x9HOHrIybRn3rL4L5vcDb9OO5oFSt55e0uYdG3uKe7xaR53b5g0txlcZGMo3VtbKKYVkmQFsac40B5kb0oCov0PTmuEdtyclx6MuIk1/NaKPql2AWEDzcqmtQC8DOZ8qMWSvf4hs0gfQhZ8KI0p3rCz4P54XMoFk8yWMZUgYHCDG6s9NqE7VV+ZDbjGAQ4fpZZNV/f9BGdGj+pRKs6s7nLlsLGo0fhPuZm/SZeOQaFeNs0B8gUA36zjtqU4+rIjOAewpdiRjzh0AWgq43l4FhCUvWoXD2ypKEPMaJuyfPlDMMsm7jL8rKTIZrng60Bae44CSIktx+QkfFdp2ZeikvTGaIsH9TtUCaaC1SXFKaX/3WVR9aIVGBueewh5x3xDiPLEP42ZRkllmgm7xruD5UAuHzCwVAqO+TJ64Kyi3TAWiRwf2L9Yv5SU0UsdB6+i3cyPtNaQgLAlhwv01VFfuFoPNTJkNx9lH80FSZCc/EZbMb8Gf+ryDPqBr9GnRfix8riudeCInf9mPflK54eGmLpT+nzaNqTJ7bP9+SnVp1EOsBDVvBgm7DxNwtaFU3uTG9kUH9G5QQW7t+6tUJ/SNCzS2zWguakTP/fgJz+RCW/S5yZPi6eJLZCXiNgsoEQJgNZIketR4emhYuzVNdDv9SnFHQoKBVKRNzeDWncqhhAZ9227jnZVnarMspYRog22ftnslaOd60eYFHRNR0f49Km6JFSwzu99UwelUUA/HwBMBYuOJgf5HNPxI1nCoSUix6Yzd5XNrjIRRzVe/xn39Z9ytFd7/g4/WZEF/a45UpwSKwHMEseRh8+Kqyz5+GbZYyxreqeWLq5SdQ==
x-microsoft-antispam-prvs: <BYAPR11MB36690E6A67D511F4BC896C26C1490@BYAPR11MB3669.namprd11.prod.outlook.com>
x-forefront-prvs: 09749A275C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(396003)(346002)(39860400002)(199004)(189003)(7696005)(46003)(2906002)(486006)(71200400001)(99286004)(6506007)(97736004)(76176011)(186003)(8676002)(74316002)(790700001)(256004)(86362001)(106356001)(81166006)(6116002)(11346002)(14444005)(8936002)(71190400001)(81156014)(7736002)(229853002)(446003)(52536013)(5660300002)(6306002)(6246003)(6436002)(33656002)(54896002)(53936002)(9686003)(68736007)(2501003)(476003)(478600001)(105586002)(102836004)(25786009)(53546011)(110136005)(316002)(55016002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3669; H:BYAPR11MB3638.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: xi/UvrqENSbbxiCEw/QLDyf6MSxtDTWLG//zrHMUW4kxQt3vpD0lScFqv+9KFw/BSYoo+lCrZOKashc7T5pOBW3T+kldmEyHi2jhPFf+MHVgCwIHRraBAWoTSJCeyx2Gi9hgltDxL/I8NHGxkn0+vjURWbpxYr5EnS03Czj4PtJjHKnPrhtslgGHWkf33BcktRdB+9ku5yVAdZCIYAutioMPPF+1xw2u27kzz39VDBAIWk9bScyIjsz0bgM8l9nt0iJ45Z8txHrd/VmdunSlSD4BNSIEiLGYSzA1wJdfypCDoCSQQST6vGnYUnni1e9r08xPXfrtRwKryLa00kj8jWUsaR0TMgxlVij+C/Jw3DjkTAUZyBZTcW+LH5i92VjNW0ZJWzipbpQkUh9gzP5d4c5xMdE31AqNulnyBU0US8E=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36388B5D52641053E327A084C1490BYAPR11MB3638namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c30c4430-1ddb-4c5a-85d1-08d6a6a321f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 04:28:09.6650 (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: BYAPR11MB3669
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/dWTTzynrnFrQWX9SQ3yRVRrShcg>
Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding
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: Tue, 12 Mar 2019 04:28:17 -0000

Robert –

I don’t think the word “random” is applicable.

Section 6.7.11 states (emphasis added):

“In the unlikely event of multiple failures on the flooding topology,
   it may become partitioned.  The nodes that remain active on the edges
   of the flooding topology partitions will recognize this and will try
   to repair the flooding topology locally by enabling temporary
   flooding towards the nodes that they consider disconnected from the
   flooding topology until a new flooding topology becomes connected
   again.”

This isn’t a case of every node in the network trying to decide how to repair the partition. It is only the nodes at the edge(s) of the partition doing so. I do not see this as “random”.

What is being debated on the list is not related to randomness – it is the degree of temporary flooding along the continuum from “minimal” (one additional edge) to “maximal” (all edges to nodes which are seen as currently disconnected). The former risks longer convergence – the latter risks temporary flooding storms. But neither approach is random. Once the failures are known, the set of candidates is predictable.

The concept of LFA also isn’t applicable here.  LFA (if we use the term in this case to mean a precalculated set of temporary flooding edges) is useful when it can be preinstalled in the forwarding plane, allowing a node to eliminate waiting for control plane intervention when a local failure is detected.
But LSP/LSA flooding is always done by the control plane – so having a precalculated LFA wouldn’t produce a faster response time. If you are going to suggest that the calculation required to determine a flooding topology partition is itself costly I think this is not supported by current SPF calculation times. In addition, given temporary flooding is normally only required in the event of multiple failures, the combinations required to be supported in order to have a useful set of pre-calculated temporary flooding edges becomes quite large – which makes such an approach impractical.

   Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 2:28 PM
To: lsr@ietf.org
Subject: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

Hi,

As of now at the event of failure of any of the FT enabled link additional links are being added in more or less random fashion by nodes directly connected to the failed links.

In the event of 100s of links on such nodes and advisable rate limiting addition of those links it seems that repair of FT may take some time.

In order to reduce such time interval better then random addition of remaining links seems recommended. How about we hint participating nodes to execute purely in control plane of FT an LFA algorithm for possible future event of active link failure and use results of the LFA computation to prioritize links which will be first temporary additions upon active flooding links failures ?

Such optimization is local and optional and does not require any changes to proposed protocol signalling.

Therefor how about just one sentence addition to section 6.7.1 of draft-ietf-lsr-dynamic-flooding:

Temporary additions of links to flooding topology could be more educated if given node runs a pure control plane LFA ahead of any FT failure on active FT links completely detached from potential LFA runs for data plane topology.

Kind regards,
R.