Re: [Lsr] Prefix Unreachable Announcement Use Cases
Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 November 2020 08:27 UTC
Return-Path: <hayabusagsm@gmail.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 6FBF33A0846 for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 00:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4Ae2bwHiCwqb for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 00:27:26 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF2C3A084D for <lsr@ietf.org>; Tue, 17 Nov 2020 00:27:26 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id s2so9840508plr.9 for <lsr@ietf.org>; Tue, 17 Nov 2020 00:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com> <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn> <CAOj+MMEKbBU1mymU2RzWzwi6Se8ZwQ9OsCBn4NUiX3YAceLdoQ@mail.gmail.com>
In-Reply-To: <CAOj+MMEKbBU1mymU2RzWzwi6Se8ZwQ9OsCBn4NUiX3YAceLdoQ@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 17 Nov 2020 03:20:47 -0500
Message-ID: <CABNhwV1yS1KdPe0hYGOUhDBpqbNqZCaO=xNEr_LaRg35b=f55g@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b927f005b4494336"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/kz4_sGIWeaXyb-V9WXvxl2SLofc>
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: Tue, 17 Nov 2020 08:27:30 -0000
On Tue, Nov 17, 2020 at 3:06 AM Robert Raszuk <robert@raszuk.net> 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
- [Lsr] Prefix Unreachable Announcement Use Cases Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… 王爱俊
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… tony.li
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Huzhibo
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Jeff Tantsura
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Acee Lindem (acee)
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Gyan Mishra
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Aijun Wang
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Robert Raszuk
- Re: [Lsr] Prefix Unreachable Announcement Use Cas… Tony Przygienda