Re: [Lsr] Prefix Unreachable Announcement Use Cases

Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 November 2020 09:02 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 07FD03A0A4F for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 01:02:00 -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 DS5vk5hGYJT7 for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 01:01:58 -0800 (PST)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 1C94E3A0A42 for <lsr@ietf.org>; Tue, 17 Nov 2020 01:01:58 -0800 (PST)
Received: by mail-pj1-x1030.google.com with SMTP id gv24so93719pjb.3 for <lsr@ietf.org>; Tue, 17 Nov 2020 01:01:58 -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=kqX1C1qFnMsdUnAF4iAKroZeMmr+DlCLmUdCntIp5jo=; b=i60QjX8Vfw+cNGiuwdL2a/o+GzlELrzMTWqmkpdTkc0pnIWYcoWa/QWPB9SAu+LUB/ HWFuI//K4rpAYWHMC8JAEaPe1mgLGpDs2znEHn7OvTHgBFvbp9qTs/0fATAydBZzVanE faL5QI9fsFohDih399EI4UCH+qryBvDLSS3KW/9PRF9GYkFPoejMc6OJZ3/O/r6NLzeL wq8AECBpVhssI+eF/VjLdO3RvutRDt9x36KKGdbiGY9XDe+AyDwOPWGmLzKXNLFn3P3H jDVmpwXZdWpwDHpx0/KEIq6D0TkTVKye11XoMSMtQSe+2ZSVKJSLBOBuXD8BWdvoowzR EgaA==
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=kqX1C1qFnMsdUnAF4iAKroZeMmr+DlCLmUdCntIp5jo=; b=cF9TI2xCp1j+QwJidVDEOiSAY16HcVNwBseOuj1mXfp/YWn6f18DLcTEVQjbOuQu+x byPU0zIRG7OVomwZIs0tzVc/oMmizMXymVcPmnvXftgEP3ggZ3dFn0hSonfNNqTZHwDu m9MvO/Bz/WgksgMIWjc1GMz8zZLgUBQrd4v9gCpSobGOk2r3XgbGA2gLJM13m4YGBcxK BcmaIVu9UMbITeopK8RbtsYEBqs6mAvW8vxd+m9sQ8oNffAAKECYcHIBZLwajuYBDAra axPsezQmqrINub8UaKr47S9wzyPXdxrMsznWiPCuD/7c6svHVLQg3nxsWcTGJiRMM1m6 D5Mg==
X-Gm-Message-State: AOAM530jQeBev+CXHobXSLaun5VNZUVBC0FRnLcG1tSbicuSrCRCvEMt ZMrB1Eehl03do4AEJN6iQMylJyDSvFqU3FxEC9M=
X-Google-Smtp-Source: ABdhPJzEdgf8W38N5jELnX2eXe/+jQyLdx2ZHdCBwC2ul1PzOdgnZ8pBE4uVbNa6SXXT3u7Tt/P51l8bm9ZFIMdwoEA=
X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr3474510pja.132.1605603717408; Tue, 17 Nov 2020 01:01:57 -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> <CABNhwV1yS1KdPe0hYGOUhDBpqbNqZCaO=xNEr_LaRg35b=f55g@mail.gmail.com> <CAOj+MMGnRkYrTcC45QEy+F5HNCoFn75r=1gn-+OT89Q53D_pYA@mail.gmail.com>
In-Reply-To: <CAOj+MMGnRkYrTcC45QEy+F5HNCoFn75r=1gn-+OT89Q53D_pYA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 17 Nov 2020 04:01:46 -0500
Message-ID: <CABNhwV1pK5JX5sDcPyRKuR67eAkAq-q3wRmYqbsfCwOj0wWjSw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, Jeff Tantsura <jefftant.ietf@gmail.com>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000039ecf905b449bf8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/p_sxo7ie20hZVm9qA3xdW1GMUHk>
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 09:02:00 -0000

On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <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 A**rchitect *



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