Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Peter Psenak <ppsenak@cisco.com> Tue, 14 June 2022 15:45 UTC

Return-Path: <ppsenak@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 E148BC14F74A; Tue, 14 Jun 2022 08:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.229
X-Spam-Level:
X-Spam-Status: No, score=-12.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTmhBGWMGRn2; Tue, 14 Jun 2022 08:45:48 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDC5C1595E6; Tue, 14 Jun 2022 08:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3323; q=dns/txt; s=iport; t=1655221547; x=1656431147; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ERBSytDffsgwyj4noUZXvkXA5CG/2Wb0NsHcCpYjjIo=; b=HmTI/VcmdEurZhDscxxPFDOoDYSI+LxsS5bD8CpliVu6nVXd4P/kcCxq QXR3ZH4IZ968+ajpsN24b2EApFm7tlEdNdyo47A36WwtKP9fkSdV+2KFa qa+8cL5FfZZXJ04FwV5qv1FqKPGzp7lP5nO6zLEVA/59ICT9/fTVcV6zZ k=;
X-IPAS-Result: A0AAAACxrKhilxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIE7BQEBAQELAYF7gX4sEoUSiCFfiAwDnGmBfAsBAQEPQgQBAYUCAoVIJjQJDgECBAEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAQkbBgwFEDWFdYZCAQEBAQIBIwQRQRALGAICJgICVwYBDAgBAReCCliCdiMDrBR6fzKBAYgZgWWBESwBilSEHUOBSUSBFSeCUzA+hBwZg2WCZQSYWiYEDwMaLTQSgSFxAQgGAwMHCgUyBgIMGBQEAhMSUx0CEgUHChwOFBwkGQwPAxIDEQEHAgsSCBUsCAMCAwgDAgMjCwIDFwkHCgMdCAocEhAUAgQTHgsIAxkfLAkCBA4DQwgLCgMRBAMTGAsWCBAEBgMJLw0oCwMFDw0BBgMGAgUFAQMgAxQDBScHAyEHCyYNDQQcBx0DAwUmAwICGwcCAgMCBhcGAgJvCiYNCAQIBBwdJBAFAgcxBQQvAh4EBQYRCQIWAgYEBQIEBBYCAhIIAggnGwcWGR0ZAQVdBgsJIRwKHwsGBQYWAyNzBQo+Dyk1NjwvIRsKgQYGIgEbAplDAWtEKoEjNUAQaAUMkkmPRZ8ag1iEGJtlBg8ELYN1jEGGMZF5hyKPSiCCK581GIUbgWGCFTMaCBsVgyRQGQ+OOY45QmwCBgsBAQMJjDYBJoIgAQE
IronPort-Data: A9a23:48yuQ6DBSIFGFhVW/+Tjw5YqxClBgxIJ4kV8jS/XYbTApD921TACz TFNWD+AOvzYYDPxeo9xYYzk8E8DsMXTnIQwOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOulYAL4EnopH1U8Fn590UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqnnFp46oXC8AnRVoJhRS7hNta+ fJSqsnlIespFvWkdOU1WhRCVip5J6ADo/nMIGO0toqYyEiun3nEmqo1Shpme9dAoaAtWwmi9 tRAQNwJRgibnO+wybGTQeh3jcNlJ87uVG8akis8kGuFUK9OrZbraovQ/tUJxwgLg+NvNsnmR 9EjbSFNc0GVC/FIEg5HVM1h9AuyvVHzaTRWtBeKrKw4pmzI1klpyrXjMcqQZ9qQSMxenk+So m+D9mL/BQwROdmSzyat83+wiKnIhyyTcI4IHbOks+Zym1CVz29WDAYMEFq0ubykkEO3UNIaM 1YZ9Cs+6KE08ku2SNLwdxy1vHDCuQQTM/JUCPcS6QyRxOzT+QnxLmcZSCJMcpo4vckBSTEdy FKNk97BAztssbTTQnWYnop4thu7NDJQLHcFfzNBSwIZpdLiu4o0yBnIS76PDZJZkPXNRGrBz xy1lhMSmusdrPwQ3I6K2k/Y1mfESofyciY54QDeX2SA5wx/ZZK4a4HA1WU3/cqsP67CEQbc5 Clsd9y2qbFRXcvUxURhVc1UROnxj8tpJgEwlrKGInXAy9hP0yLzFWyzyGggTKuMDiriUWW1C KM0kVkLjKK/xFPwMcdKj3uZUqzGN5TIG9X/TezzZdFTeJV3fwLv1HgwOBPJgz21yxRywPlX1 XKnnSCEUCpy5UNPkWTeegvh+eRDKt0WnDmKHsmrk3xLL5LHPyXPIVv6DLd+RrlpsPzbyOkk2 91eLMCNgw5OS/HzZzK/zGLgBQ5iEJTPPriv85Y/XrfaemJOQThxY9eMkeJJU9E0xMx9y7aXl kxRr2cFkTITc1Wccl7UAp2iAZuyNatCQYUTZHR9YwnygiB5Pu5CLs43LvMKQFXuz8Q7pdYcc hXPU5zo7ihnItgfxwkgUA==
IronPort-HdrOrdr: A9a23:N2oWr6xnUc395JDEtE/7KrPwHb1zdoMgy1knxilNoNJuA6+lfr OV/cjzsiWE7gr5OUtQ/uxoV5PsfZqxz+8R3WBVB8bHYOCEggeVxeNZh7cKqgeIc0bDH6xmpM VdmsNFZuEYY2IbsS+32maF+xJK+qj+zEhu7t2utktQcQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,300,1647302400"; d="scan'208";a="2452451"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jun 2022 15:45:45 +0000
Received: from [10.147.24.42] ([10.147.24.42]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 25EFji6Z003583; Tue, 14 Jun 2022 15:45:44 GMT
Message-ID: <16e06718-542f-e266-05fd-a1822bc4fd49@cisco.com>
Date: Tue, 14 Jun 2022 17:45:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>
Cc: "draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org" <draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
References: <AM0PR07MB63863359D147F9EC0FF67689E0AA9@AM0PR07MB6386.eurprd07.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <AM0PR07MB63863359D147F9EC0FF67689E0AA9@AM0PR07MB6386.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.147.24.42, [10.147.24.42]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Q1aK9NjWQyfpdFBWeYB0SObJ-Pk>
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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, 14 Jun 2022 15:45:52 -0000

Hi Gunter,

please see inline:

On 14/06/2022 10:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi All,
> 
> When reading both proposals about PUA's:
> * draft-ppsenak-lsr-igp-ureach-prefix-announce-00
> * draft-wang-lsr-prefix-unreachable-annoucement-09
> 
> The identified problem space seems a correct observation, and indeed summaries hide remote area network instabilities. It is one of the perceived benefits of using summaries. The place in the network where this hiding takes the most impact upon convergence is at service nodes (PE's for L3/L2/transport) where due to the summarization its difficult to detect that the transport tunnel end-point suddenly becomes unreachable. My concern however is if it really is a problem that is worthy for LSR WG to solve.

the request to address the problem is coming from the field. The scale 
of the networks in the field is growing significantly and the 
summarization is being implemented to keep the prefix scale under control.


> 
> To me the "draft draft-wang-lsr-prefix-unreachable-annoucement-09" is not a preferred solution due to the expectation that all nodes in an area must be upgraded to support the IGP capability. From this operational perspective the draft "draft-ppsenak-lsr-igp-ureach-prefix-announce-00" is more elegant, as only the A(S)BR's and particular PEs must be upgraded to support PUA's. I do have concerns about the number of PUA advertisements in hierarchically summarized networks (/24 (site) -> /20 (region) -> /16 (core)). More specific, in the /16 backbone area, how many of these PUAs will be floating around creating LSP LSDB update churns? How to control the potentially exponential number of observed PUAs from floating everywhere? (will this lead to OSPF type NSSA areas where areas will be purged from these PUAs for scaling stability?)

Node going down is a rare event. The expected number of UPAs at any 
given time is very small. Implementations can limit the number of UPAs 
on ABR/ASBR in case of a catastrophic events, in which case the UPAs 
would hardly help anyway.

> 
> Long story short, should we not take a step back and re-think this identified problem space? Is the proposed solution space not more evil as the problem space? We do summarization because it brings stability and reduce the number of link state updates within an area. And now with PUA we re-introduce additional link state updates (PUAs), we blow up the LSDB with information opaque to SPF best-path calculation. In addition there is suggestion of new state-machinery to track the igp reachability of 'protected' prefixes and there is maybe desire to contain or filter updates cross inter-area boundaries. And finally, how will we represent and track PUA in the RTM?

the problem space is valid, as conformed by the field. As described 
above, the number of UPAs will be low, so there is no danger of 
defeating the purpose of the summarization.

> 
> What is wrong with simply not doing summaries and forget about these PUAs to pinch holes in the summary prefixes? this worked very well during last two decennia. Are we not over-engineering with PUAs?

it's the scale of the current networks, which is growing exponentially, 
which demands the use of the summarization.


thanks,
Peter

> 
> G/
>