Re: [Lsr] Prefix Unreachable Announcement Use Cases

Gyan Mishra <> Tue, 17 November 2020 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FBF33A0846 for <>; Tue, 17 Nov 2020 00:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Ae2bwHiCwqb for <>; Tue, 17 Nov 2020 00:27:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FF2C3A084D for <>; Tue, 17 Nov 2020 00:27:26 -0800 (PST)
Received: by with SMTP id s2so9840508plr.9 for <>; Tue, 17 Nov 2020 00:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sABakDCzQCWDrbUvDduFuLy0SrPdsmNMVBoEaCvIWCU=; b=vMnqAsus3+m6BXjM/y0K9RJl9o0TJH4OYcPi2sjEnWUxTml4Zq4FqnCJIG22P+tz7o voQ5mp2I3q6kNXU85jxHd/3E04fMRjx/nS3lxAHcZAOuQOPdOylig7QXUTZcY+mcv7mw NVcOHdYM4GNnVrFoVm/63xzsoEuwYAB2P0GD2ObhWX+xx3QtyqViI0+s611rDXMdhqg/ /51/W+9oDj4sMavyIChg2OGBMn09I6uF30qr/JvA8YDLTi6q2iVqPgfd896yoeBTFrpK fYH1S0YNNDPiibkqPXYtDvhcdRDTi//KeKGzK4/hy95cBrieyzGk+dOQaS8+gVJ2l0qB zKwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sABakDCzQCWDrbUvDduFuLy0SrPdsmNMVBoEaCvIWCU=; b=ZmIkoteFOlJGSLhGWojLeG7ybLW45tNwkUfgLNf7CzHYS3hXSPcD1SKhWBtX5FLcFz t3tyODVHhAqrO4rMAnSG/SfrVuEgiRoFXUqj2rDuyUgc9NFd32oFhf8GlV1QarRzzQhy xbCEXRQzNDBhkQFK4wrU2AepPx5kUyDUXcF2FSzd9elxAy8CZ0UZi7ZOhjrN94U8XHVT G1KDAVb9URP9xm7T52WH0LYWcJbXd1O3CdarI5Tt69OoknAx5Dt4U5K9YiG8ARtUgsQU 4dBy0Tpm0dTYaU7tVNtSHBFebA+uEoxJtbTkdanJxnPIs2umqYIyz9cvi9XdpqoxL16B kBLg==
X-Gm-Message-State: AOAM530PnpfM6qtUyC4nEDBNzxh0CLi1HI+iDvzDYkuOoIzGSRmGO+Ot fxhMVAN1PSc46x+xF8n3Y44CaNsIiomjw5Gh6Yo=
X-Google-Smtp-Source: ABdhPJxaSKAi0fW34UoXSE3K/sGAPK0UaBzBfhPObwoELfDuvAVCbUuVlp7MAumoiaKf39DxodASS8VPy6/3Cyr6f9U=
X-Received: by 2002:a17:90b:1490:: with SMTP id js16mr3421873pjb.215.1605601645372; Tue, 17 Nov 2020 00:27:25 -0800 (PST)
MIME-Version: 1.0
References: <> <> <016b01d6bca9$cf908c20$6eb1a460$> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Tue, 17 Nov 2020 03:20:47 -0500
Message-ID: <>
To: Robert Raszuk <>
Cc: Aijun Wang <>, lsr <>, Jeff Tantsura <>, "Acee Lindem (acee)" <>
Content-Type: multipart/alternative; boundary="000000000000b927f005b4494336"
Archived-At: <>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 08:27:30 -0000

On Tue, Nov 17, 2020 at 3:06 AM Robert Raszuk <> wrote:

> Moreover it seems that it will just also prevent any local protection to
>> locally bypass the failed destination.
>> *[WAJ] No, It will trigger the local protection instead, not prevent.*
> You missed my point.
> I am talking about *local* protection in a sense of adjacent node(s) to
> the PE/ASBR which failed. *Local* to the failure.
> You are talking about *local* protection on ingress to the network. Let's
> focus on this:
> Q1 - You are installing a /dev/null route in a router. That means that any
> packet sent to this destination will be dropped. How is this of any
> protection ?
> Q2 - What you may be actually trying to say is that by installing such PUA
> into RIB you will via RIB let know those clients (ex: BGP) which track this
> route that it is gone and that their possibly best path is no longer valid.
> Sure that is one way to share such information between IGP and BGP. But
> this needs to be described in the document that this is your intention.
> Otherwise when you say you are installing a drop route in RIB & FIB I am
> not sure how helpful that is (well other then transiently relaxing the
> network to drop some traffic few router hops away).

   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.

   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.

    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.

    The  one use case I had mentioned to you in the past a while back is
related to BGP PIC core convergence which I mentioned during the
presentation as you brought up BGP next hop convergence as a use case on
the ML.  So in cases where you run BGP PIC edge and have the pre programmed
backup path best-external add-paths advertised backup paths you are set,
however with BGP PIC core prefix independent convergence with the H-FIB
next hop rib convergence - with next-hop-self rewrite to the loopback, the
loopback never goes down so that does impact iBGP path PIC core
convergence.  So a workaround is to not do next hop self and so when link
goes down its detected and that fixes the issue.  Downside is you now have
a massive LFIB FEC binding database if you have tons of customer edges.  So
I think PUA could help for this but I was trying to connect the dots and I
think there is something missing but maybe we can figure out how PUA can be
leveraged to fix the PIC Core convergence.  I am assuming that is what you
meant on the ML with next hop tracking convergence would be the obvious use
case for PUA.  So the tricky part here is you you can send a PUA when your
PE-CE link goes down and now your H-FIB IGP forwarding plane would now
converge immediately on the alternate PUA path, however you still have
next-hop-self rewrite happening to the loopback which is still Up.  So even
though PUA fixed the Core IGP detection of the PE-CE link failure, it did
not fix the next hop self rewrite to the loopback which is always Up.  I
guess there would be still an improvement with data plane convergence for
the PE-CE with the PUA being sent to converge the BGP next hop when "next
hop self" is not used.  It would be nice if there was some way to make PUA
fix the next-hop-self rewrite to loopback to improve PIC core convergence.
You would need a flag to tie the loopback to the PE-CE connected interfaces
state to be tracked.  I believe you wrote a draft way back that fixes that
issue but was never adopted I believe.  I would have to dig up on ML to
find it.

> Thx,
> R.
> _______________________________________________
> Lsr mailing list



*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD