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

"Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com> Tue, 14 June 2022 08:59 UTC

Return-Path: <gunter.van_de_velde@nokia.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 1B7FDC1649DA; Tue, 14 Jun 2022 01:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.654
X-Spam-Level:
X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 2dqs7C0O3gkp; Tue, 14 Jun 2022 01:59:18 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2398AC1649D7; Tue, 14 Jun 2022 01:59:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hm3FwxM+aYo6iVx5Y1TE1offbbeqfKXgmUcVd+01gnPO4i2ldLql5um23VhJUUtAdkv1PD0VX908yjqF7/p8zsUTkjMQfTSkuffnJK3IW4QgX1sR/wzUzqTKyzevWRx1+ruFblCa6sWWjZxsG//VGfpIp0ORpmpnjZSe9horjaaEZoCBIcJkwnq8iLnODOO8Op1LL3m1vpvsSulJo5xwDC5YrXj/li19UjD542Ob1p/yrvjBuQihG0rIA57xfFc3Ln/SLdQM+mRkxb82b0Ar1LgRqVdzsAfEQrdP2Hc9cXnCwxeM5+KdbfDbLOysvO7RkNDhwyzi3IyaNQMIOnk1cQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pC3SquGMR8ab5Ii63Qv66VZCcZzhrY8oTY2MWRrTD1I=; b=Hj+OtJXnNADyZVRgmw4LMZW8zzTq4F087bReIiDDygTSCaQG+JbFuhAVmCCaH4MUzjITpbsFCii5djInBWGOJu3bhU9MvwYxJhBmzwGn9F3b3vbjq+Rx0TzQEffs70GNlhAqIYAfeRYUf3mkN4rVu4RoOZJWp4eC23JQkmCDSW/3mtaJRge+TojSIMWnD1vzwXbgTnxsx3bJl0/gWyST9KaiBv9bVvPBTClCIrLB62WzQY6O9isUjAh/p/XXLCweK05HnL0xTWWpde0Z/6bi0KyaCd1JAsCckmR8gCDDHsbB3P2KHiVj0VCTEd/vA0n7vfxsTTil1Qe7txDxPf4LnA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pC3SquGMR8ab5Ii63Qv66VZCcZzhrY8oTY2MWRrTD1I=; b=Gxi+ndqKpCOZ7ujE0542VSTHgYOqdEJ967TErFK0Fb5kuTgMQI0OxmXuYkyKW3CYYF1d9PnyKdp2mzoCeayzZrx49d//Nc+VhGLuNPUpGn/XDKj58I4ZOhmTlEalJs1UdSSYRpwWbJum99MUSrAHDLPwI62XWhojFu6ohaQvQY0=
Received: from AM0PR07MB6386.eurprd07.prod.outlook.com (2603:10a6:20b:144::23) by GV1PR07MB8335.eurprd07.prod.outlook.com (2603:10a6:150:1e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.6; Tue, 14 Jun 2022 08:59:12 +0000
Received: from AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::b5ef:15fe:dc3c:7508]) by AM0PR07MB6386.eurprd07.prod.outlook.com ([fe80::b5ef:15fe:dc3c:7508%8]) with mapi id 15.20.5353.008; Tue, 14 Jun 2022 08:59:12 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
To: 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>
Thread-Topic: Thoughts about PUAs - are we not over-engineering?
Thread-Index: Adh/zPh4Y/SpJPjaRJe30Bd2YQgaiA==
Date: Tue, 14 Jun 2022 08:59:12 +0000
Message-ID: <AM0PR07MB63863359D147F9EC0FF67689E0AA9@AM0PR07MB6386.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5571d23f-2821-4289-9818-08da4de426a1
x-ms-traffictypediagnostic: GV1PR07MB8335:EE_
x-microsoft-antispam-prvs: <GV1PR07MB83358C0C973FDDF269BFEC97E0AA9@GV1PR07MB8335.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hd4sCF08yQZw2ODgMysj5EAdM+pHNsVs32I1pra5poo+So3Zq7p+QylrvkmildaNFo7LJivgzjxq239f23JSvKfFNv4Wp/LXRi9R1lUupgEBfq0A7bjl6/Xge28Ndw1pqGsEav24MROmM69kl3ub8DDJNGXmlbMGY0kIpeqcjiK87wdKM/pCIdFEBK0QxbScZ/vuU2Tn7Mo9yCpjqs3pLI2BoX54RD3GP2gHwMvws/WUZPa92ONY89lUP7bZcqZmmoCU48B17W00meCOdBnaV/YXj/w0gbwFVHOLMAXCecT0cJIOVLijb9UYhmIzIPdGNWhgLWAaRo21JR/qonxWJn8OeHudmj2eEpPhxBJ8l+MZobhYnEQtuxzW59juUj5N4MvTCPvUezKneAZzl6K+Ez6IIFEXKVXX6be7bZaPVfcy3V/rZLj0wzp5gQAt8r1gH1Fdv0TZ2npzzFr8M7mg1+uikzbD5IDHH6qX8dd3QOUnB/teDQpB5DQ+LNUxff9CiXtt55JIzeHyAZ+R+ia/17DMHm39jaag9yX0B+3RL5fvDkHuqBPdO9hpnwqACQiLS+i5HgbdEq+1WJTEOukkuWNznopTeL30dXUWtfpVQbBesOWv4kJpSxWVPvC5A2b9qW23R8BzLbM13PdWSJafMOgIzWWzC6XXPf2E/+tyf/1IveoaTEillYtATbieUEh4Q1vnBKEan5GwaUKNISAR1Sn24X5xgCBCdJfN4wPiz2azD1Kn8EU6//Zb4g5FIbpS
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(366004)(38070700005)(82960400001)(76116006)(450100002)(86362001)(4326008)(8676002)(5660300002)(66476007)(33656002)(64756008)(83380400001)(38100700002)(122000001)(7696005)(6506007)(186003)(66946007)(9686003)(26005)(508600001)(6916009)(54906003)(8936002)(52536014)(316002)(71200400001)(66446008)(55016003)(66556008)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 2g7CUIAeYrVTDlFII/NKQsjweizsrwbeSOBJBOvqDjYlF6yXBFT/zFTf8okOZBpRUqsAP7WFKyVCRzvl8eSkhwmtalRYCDoyVXwGztF1X4/4TX/QfLflPWuG9z64Ml5lHfAC6FoqX56IeQYuTpPiVdji499Icr2q/WbcEbyn/4KK00zcWuRj3VmMIDpH2LGXKJu6I0vOrdgdg+bLuB9C8un64doTlU7lTPoEDmMPBB0jbmfUXH2xceT/AuXrwMgTd44qRqCI9o5F78VA53odzRyvMn9QY1iW1sDgnXK+qLpWzxTSAEqfmE6KcJihgRP7/CsFvr3eMTgUhxP5so9vrVp2OzGciZNWdGgKPVaNBrJ1SN5Cdxd8toRzFqzxDqGs7NttWx5e1gEoCkKlqfvrs0BTGUDO+DoGVj2J9bLV4Yh2spZGCtJEOmfV67R2q2w4ixsA8arsS+QtHUFpkQI5fWqvtqnKC4VUQK3pWg/FNy81dr7QXD593wauAL9/RwmrmEUaVVG7synHlAmwTYnhUbR70I2+TVJV1Yz2svtLmgWSpiu0anTTF2tTbqRS+x/pn8MfqQDsPItO7AlLBEmtDajgIV2kE56puootzeKkP6LbQNdfcQhMd8jvdPTFRLmTtB5cNznYPAnU2JXipyMo0UAxTFVztE5xTpN7uIhJ1jSSngxRks768RMJMfH06oS9gmenceavl6ftIg1ePVEIDo41TlNZgirt3iF8H5BMmufRhIZLcUcFyAQhXXra9A9qvSC8l1mmyuX3bpTAuvnBwtYz2bkC/RqJqsWTWymeXLpysAqobHvbmI4mycuR8Soqr4J3yR6Z89RKuJ0sq6VNeRqVhooIXX6zZOaS17BjVK0J3J+mwwwkalgNDfREdv2Oq7oI58YzLzZ5IJTuFEtnz4H4tGgn8FdMo6A8Nm8RhEwiU29P3nOGCqh+RpTvI3Nu0dqGwmE/wrqxgwnGwLm8tNhLr9bGnbqfJFdZU5ehQvuWWMWfI/HpiZo0hQS23lLO1hnLEyot/E2mSO9QL+0HlGix5Po+7QeQ1RncvRr16svSo3XTMPKj5ovD1ztyDMuyry+rH9vsx0Z/gEx1Vmw78TimqV2QL2CLWCjte1snf22OvFwb/VGJ+CSJGAoJifbiDSXl4alhXANZ6mQ11XZUrYTg7DNEVACq/tmGnaqoyJ1wsHJ2yVwCw67JxQKgiE/sYaoDlXsaatHziNvOzTjp5InJ5WQlg2lPd0Tpi+bzuKkZ7cPLgo7UcNr5KiXVH65AWPW/5gsxYzLycaLYVYkZvQF8z7qC5MsPFUeV3xelnqTmQtyWU3iy0kXFeIFaI50m8R4T2WBFOtDRTq7H2OxudD7oD0+L8V75HqN2dT/lORh2Hp/bQA06wpLtxk6MXPhPY6c3THSkt9raU4+AtJN9BhK5gH5Ba1Rn/KQ+6rshBPpVj5dbs0rDTj49riYuSf2yUWC4wSudemav11kiTiqoXt5bkwwLfCe+yQx8qyTzDPOYvHkYqpRApL4Msuc0zEiBdZ5/GRbrcyzU0hSJQTdXX+PXGE2Pze3fcL4cvt/RRF0jEdUonlN4m/hchYl0kp50LhoPb0P7Mmn7wpxqWmOenNUuXBl8GFSECj6CvlGRZvEOyfs9hcB+LEyCi9024BQ1g3+oa7fuVQjpKyPrZpXA2dYFwGr4zZhBdp31j3hYAD+PoIGiGjnJI6c5LA96wa1BVxECJgNBEzp+1RnFr1j4PKhIzTE2aB+apUvK5AZ4agI=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB6386.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5571d23f-2821-4289-9818-08da4de426a1
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2022 08:59:12.1728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4IlKVypMcUCB82oLouqoHYRHltgXb5sAEse4JbpFKPy8SqwLctq6aqZF3qtVGuBpub9YHGfkvI2wANc1EPvOSe9BdSDFRK0uyr/SxK4huII=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR07MB8335
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/s5PDuhK9Owl_etv39oIBAimNUo4>
Subject: [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 08:59:20 -0000

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.

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?)

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?

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?

G/