Re: [Lsr] Prefix Unreachable Announcement Use Cases

"Acee Lindem (acee)" <acee@cisco.com> Wed, 18 November 2020 16:42 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 841213A0C87 for <lsr@ietfa.amsl.com>; Wed, 18 Nov 2020 08:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TtpoYiK5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ubAvJPR7
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 ly1znTUy-AD3 for <lsr@ietfa.amsl.com>; Wed, 18 Nov 2020 08:42:38 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD8D3A0C50 for <lsr@ietf.org>; Wed, 18 Nov 2020 08:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42109; q=dns/txt; s=iport; t=1605717757; x=1606927357; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ikJW2bi6COkO1wHFSq4J1RvFEpcRf1vgEje9XjZmSo8=; b=TtpoYiK5pmvz60iJQ447w8y26VP/ATXEGqTDOzCGmvJxjrkOKv9iR/jz mBsmDGlRvht80rBGI5t9sTWt5w3H5ns2RlD78c+d/xMqWCo3d1l2SLLfe 5TbpyD+EGlBQYYcFQePnV7+1ybI8p7maLor7EcvGWW99dmPoQNxqdxrxo E=;
X-IPAS-Result: A0BhBgCdTbVffYgNJK1fAxwBAQEBAQEHAQESAQEEBAEBgg+BIy8jBih7WS8uCoQzg0kDjTYmgQWJEY5uglMDVAsBAQENAQEfDgIEAQGESgIXgg4CJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQEDEhEdAQE3AQ8CAQgHCgMBAQEhAQYDAgICHxEUCQgCBAENBRkCB4MEAYF+VwMuAaQ1AoE8iGh2gTKDBAEBBYUPDQuCEAmBOIJzg3aBBoVRG4IAgREnDBCCGgcuPoIbQgSBFx1ACQEVCAmCUDOCLJAlJ4JiPocenFpVCoJtlRZwgiWCbgMfgxk5iV2US45rhGiCAItukmkCBAIEBQIOAQEFgWshgVlwFWUBgj4JRxcCDY4fERKBAgEJgkKKVwF0AjUCBgEJAQEDCXyLBoE1AYEQAQE
IronPort-PHdr: 9a23:H/LOiB8RCvFbDv9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+7ZhKN+e5silDJQIyd7OhLzeHQ4OjsWm0FtJCGtn1KMJlBTAQMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9rlZlvdomC7qzkIFVP0M1k9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV3CpX4bdg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,488,1596499200"; d="scan'208,217";a="615100469"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2020 16:42:20 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AIGgIo1014668 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2020 16:42:18 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 10:42:18 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 10:42:17 -0600
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 18 Nov 2020 10:42:17 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MVNQEYOPgQFP/GBCLQp47dn3Iq8gnnujJ8AmbkIu01gP77ZZz2gnBh06C8FLzJ0hGZ93LUQesXgDZV4KRGJP1Eqfu8+HVubNA5wtB0EvKO/etWzCmYLO9o4GB75YwmwdbO1fEJQKjE+Shp4jRpBlCbz/bgwqJRy7vH8qF+r0mnbBDTkJfyXEuTMQV+hDC2YKxjsm559JaVJNjg2z1T5gpKo0RooAbh0AETMx0PUQ35jON533IyuBeFAXsKfOV4Oh4ABMjir38AE4Zb1lwHq87PimH+miBQcVHnZZtNRObPmFp+RG1uV2guEuME+DhP0A1oXIX5/FkRM1aTn5AMx2rQ==
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-SenderADCheck; bh=ikJW2bi6COkO1wHFSq4J1RvFEpcRf1vgEje9XjZmSo8=; b=aPLaX9cNl50NiFOOcUiUlp3yPg87khIfe5OW1yfHTpaopJXEPqO189XBPterZ5KTnhdgxXxHO1MA/FXtWvTDkbKm8zc/8R63QKOJFFE80emavNCJPgjUCs4NADQNgXVNyTZmu1CSFEpKEwXrBDbQLwzty9NqXQiTSekiefTMfHQZaj9A307w97eiwD6MKd4EyF5tZ+gGMcxybbCcMQEw3u9KrzrxNWgHSonqEh8QMyRZMiCxrCEn5ih0mfrJ5ZU0hjVszPm5hEB+K9w01ojsT5h95s9svUkIg7wtrxfHZpLx6CNWLG2xL3NlXCJp0Sh8LoCreavYpOymyHH0tOn6iQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
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=ikJW2bi6COkO1wHFSq4J1RvFEpcRf1vgEje9XjZmSo8=; b=ubAvJPR7hpbJSFolN3wWUUw1+fM5LJTuYGbZdeX9vHkkrNzw7zRHnzgXEddWf/wUmwtWUcZtP+FEriJN9EDfIj+6zZjUXMenynxA7MyXJ6WQbssInYNnGjyneRDTt6CXBqX0LfvJ3FV2QoLESBWfyhy7UXAGbCj3OZW+nMaeg0E=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3799.namprd11.prod.outlook.com (2603:10b6:a03:fb::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Wed, 18 Nov 2020 16:42:16 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3564.028; Wed, 18 Nov 2020 16:42:16 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, 'Robert Raszuk' <robert@raszuk.net>, 'Jeff Tantsura' <jefftant.ietf@gmail.com>
CC: 'Gyan Mishra' <hayabusagsm@gmail.com>, 'lsr' <lsr@ietf.org>, "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>
Thread-Topic: [Lsr] Prefix Unreachable Announcement Use Cases
Thread-Index: AQHWu1Gr6nBEatikRUm9MC1o5feYm6nJZmuAgAAuKgCAAAmVAIAAdmCAgABY4gCAACRvAIABSx8AgAAdWoCAAAQigIAABF0AgAAHFwCAAAvDAIABKv2AgABHJQCAAAS3AIAAPI2A
Date: Wed, 18 Nov 2020 16:42:15 +0000
Message-ID: <2C21FE6C-4AC0-4949-ADE0-357DD7E18A87@cisco.com>
References: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com> <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn> <CAOj+MMEKbBU1mymU2RzWzwi6Se8ZwQ9OsCBn4NUiX3YAceLdoQ@mail.gmail.com> <CABNhwV1yS1KdPe0hYGOUhDBpqbNqZCaO=xNEr_LaRg35b=f55g@mail.gmail.com> <CAOj+MMGnRkYrTcC45QEy+F5HNCoFn75r=1gn-+OT89Q53D_pYA@mail.gmail.com> <CABNhwV1pK5JX5sDcPyRKuR67eAkAq-q3wRmYqbsfCwOj0wWjSw@mail.gmail.com> <32DFCE3A-D41C-48CA-928A-37011D158AEF@cisco.com> <c646fecb-2d45-4ece-adc1-eb0635a58c3c@Spark> <CAOj+MMGrZz3pJfmP1gh+4YO6XfKr_NWe+QOy8mfjyqUxqub5kw@mail.gmail.com> <019901d6bd81$9565b5b0$c0312110$@tsinghua.org.cn>
In-Reply-To: <019901d6bd81$9565b5b0$c0312110$@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dc507aa3-b1b2-47ed-e579-08d88be0e87d
x-ms-traffictypediagnostic: BYAPR11MB3799:
x-microsoft-antispam-prvs: <BYAPR11MB37993711DBC2366388F6752DC2E10@BYAPR11MB3799.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: e1uDIrfY56T6aLesre4prKBFOozU7clxzE4R6SXID+7DMw0WDtukRgdmDkdPmd3s95+tQDtyxieDar25G5SdtLcDfGhgHL3WQhThaK6rVFnAMqwP6tKMUCIxsFt8N0LyF8G05JEQO0kel7b9XOoEwhTTsa3jSQTmDx412arLSoCMe5tN9XGqJja2Q3c3CIA+2fgBp9CP3Pj/xXUHAf/t83cXLbI6ShrqvVm9DQVVkPrgr3U+f3bukw/ezX0fsmYse3W2Tk5mnjWXLcZyiE7sIiIOKEist1TnMXtWlhQIOdI0Igg78KoouxB8/9dMlXY2IdvT+oOou0c5AAMb83U/qPpGwql90NRNpu2g/cjpQyjxcXKFUIxerGwvdGcYIio+tYBsPHLDQclzSeuUnxZD1Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(346002)(376002)(396003)(8676002)(186003)(8936002)(66476007)(76116006)(66446008)(71200400001)(5660300002)(4326008)(66946007)(33656002)(86362001)(66556008)(53546011)(26005)(64756008)(6506007)(54906003)(2616005)(478600001)(110136005)(166002)(6512007)(316002)(6486002)(36756003)(83380400001)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: /tYXCt/udVspqC7OOrgcPXLZyFLCjHsAj2PRVg4JkdWyEv1oiowEVfA4wjus5hQPly+hLiNqKb5kKD4uaVIlHvbMhxi86jU33Fo99A7A2XakrjYfcsQVf7tGsdQQOQZu03J4YKMbmFC7zdw+VnexOV2refAkzphClUy4oU2Tr34AHdlI+8oZvzRIypfi4kVssz+hGMUFAEcIjF3U4lxKW+NoAsrnnb/Fin68US8fr4Fxfm/NDbsh5IH0spAqhRXXP2ukx6RnqMcoE/H56cT6zBKavoDH2tjIykHPJctk5LepN7kspZRz5lp4h7CjAA74Shh8eA9BLWT+qn1NuUo9ZOSqbZldoCOTk0XylZMlu3H+8sj02U6w48tO5B+0RQzpuPJUDrybJr7Lmw/pSyspTY14tR6qlqKQxiMFw4HgqaMO/iKw7P6akcNGqN+MYgyEUN+PXGeEG82NgsiRK4GqsbZW4XnF7zgPADhoyOHe5j34prfWMHHVjpf3Xc83EAtdxHIRqa3+KB/NVHxb+9jPaGjS5EFbQNiLxp+EYI2Cwg5IhZA0kMyr2YwtRe+prGOsvIUM6j22W3SbGfJd8r/t+4YX5CwUK4B78I/UWcTzeoChgilPQ8JBa0VjPapNpgIUgasyIbH0bGDhSv0Orj9vzQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_2C21FE6C4AC04949ADE0357DD7E18A87ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dc507aa3-b1b2-47ed-e579-08d88be0e87d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 16:42:16.1425 (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: 2KYsjr7F4Me58imMfUq3iDhGXSriOYsYaK5Qlqf/sukuDaw3MmXhl+KMGGugm96b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3799
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/N1B006ByCpjRaazo5jaWR5M-xMg>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
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, 18 Nov 2020 16:42:45 -0000

Speaking as WG Co-Chair:

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Wednesday, November 18, 2020 at 3:05 AM
To: Robert Raszuk <robert@raszuk.net>, Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: 'Gyan Mishra' <hayabusagsm@gmail.com>, Acee Lindem <acee@cisco.com>, 'lsr' <lsr@ietf.org>, "'Acee Lindem (acee)'" <acee=40cisco.com@dmarc.ietf.org>
Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases

Hi, Robert:

The trigger and propagation of PUA info can be standardized, the actions based on the PUA can be different in different situation.
We can discuss and describe the actions based on different scenarios after its WG adoption?

There will be no adoption call until there is a coherent draft with use case(s) and viable actions.

Thanks,
Acee


Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk <robert@raszuk.net>
Sent: Wednesday, November 18, 2020 3:49 PM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>; Acee Lindem (acee) <acee@cisco.com>; lsr <lsr@ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff,

Please notice that WAN is not an IX.

While you can have full mesh of BFD sessions among all IXP participants each bombarding each over over TB fabric every 100 ms or so to map the same over global WAN is a different game. If nothing else RTT between IXP participants in healthy IX is around 1 ms while RTT between PEs distributed globally is often 100-200 ms.

Just imagine 1000 PEs in 10 areas distributed all over the world. That means that in worst case scenario (say same mgmt VPN present on each PE) you will establish 1000*999 BFD sessions. Now for this to make sense timer needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will defeat the purpose as BGP withdraw will be faster.

Then we go into queuing issues. If BFD packets are queued at any interface meltdowns may occur which can be far worse in consequences then waiting for BGP service route removal. Such meltdowns often result in cascading effects to the applications itself.

So this is not at all about autodiscovery with which address to setup the BFD session. It is much more about operational aspects of going that direction.

With that I am supportive of this work even if we label it as experimental for some time. As each network is different what is optimal solution for one design and deployment may not be optimal for the other.

Many thx,
Robert


On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> wrote:
We have been discussing for quite some time and in different wg's (there’s IX with RS use case) BFD verification based on next-hop extraction, Robert - you should know. (also built a well working prototype in previous life).

Very simple logic:

Upon route import (BGP update received and imported), extract next-hop, walk BFD session table, if no match (no existing session) - establish (S)BFD session (Discriminators distribution is a solved problem) to the next-hop, associate fate of all routes received from it, keep timers reasonable to prevent false positives.

State is limited to PE’s importing each others routes (sharing a service) only
High degree of automation
No IGP pollution

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>, wrote:


Speaking as WG member:

I think it would be good to hone in on the BGP PE failure convergence use case as suggested by Robert. It seems there is some interest here although I’m not convinced the IGP is the right place to solve this problem.

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, November 17, 2020 at 4:02 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: lsr <lsr@ietf.org<mailto:lsr@ietf.org>>, Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases



On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:


   Robert, I believe the original intention was related to having the data plane converge quickly when summarization is used and flip so traffic converges from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both ABRs will get the same info. As mentioned before there is no practical use of PUA for making any routing or fwd decision on which ABR to use. If your ABRs are not connected with min redundancy this draft is a worst patch ever to work around such a design.

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track the component prefixes and in case where component is down and traffic is still forwarded to the ABR and dropped.  The other more important use case is when links are down within the area and the area is partitioned and so one ABR has all component prefixes however other ABR is missing half the component prefixes.  So since the ABR will by default advertise the summary as long as their is one component UP the summary is still advertised.  So this use case is severely impacting as now you have an ECMP path to the other area for the summary via the two ABRs and you drop half your traffic.  So now with PUA the problem is fixed and the PUA is sent and now traffic is only sent to the ABR that has the component prefixes.

Please present us a picture indicating before and after ABRs behaviour.

     Gyan> will do

   However PUA can be used in the absence of area segmentation within a single area when a link or node fails to converge the data plane quickly by sending PUA for the backup path so the active path.

If there is no area segmentation then there is no summaries. So what are we missing in the first place ?

    Gyan> Sorry I am stating that PUA feature can also be used intra area where if a link or node goes down to improve data plane convergence.


With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the convergence is well into sub second.  So for Intra area convergence with all the optimizations mentioned I am not sure how much faster the data plane will converge with PUA.

Even without any of the above listed chain of acronymous things will generally work well intra-area without PUAs.

    Gyan> Agreed which is why I mentioned the BGP next hop self use case if I could figure out how PUA could help there that would be a major benefit of PUA.

Thx,
R.


--

<><http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD