Re: [Lsr] Prefix Unreachable Announcement Use Cases

Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 November 2020 20:40 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 8ADAA3A097A for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 12:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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=ham 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 3IZSZLSzjGz8 for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 12:40:31 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 5B0B73A091C for <lsr@ietf.org>; Tue, 17 Nov 2020 12:40:31 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id gi3so1197879pjb.3 for <lsr@ietf.org>; Tue, 17 Nov 2020 12:40:31 -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=ozTAbr0Thb59W3Bx/WLvl87yHD55gDCT7XjRL4sTPQY=; b=iKurmNcv6jPrNEuXnsTlLFW7yRsDoyJvKPX8yYHVBiOV37zgh5S2AVdBC2Fo8/u7sX wLeYzkOsHAbHsFn4R8HiaA/Z3fHK0EEfdegMbetWgYYQjmlqSi4Rr122pijCpK1Z7uFU 9TAjw+6M6say8UGP36+rgI+oRAfAJpA3wyFbU89ioLCV29Kc5QN9tgntzlDT6Acrb7yu i7D/fti+Gz3WXksUUGo9cN4c+c/d/Rln0WiNeNKCmP5DbakYy3eYyUKjQfcQytViNqje l5aHAzQuXlVQWYZQIRGNzEJNX/1rsaBp95A97UJrIjyJTfOelCQ7diwa24AkfpJvzrx0 Tk0g==
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=ozTAbr0Thb59W3Bx/WLvl87yHD55gDCT7XjRL4sTPQY=; b=mvXlz6Aa9F8FNNyh45FHV3TCrp7TwmHT7C5vO5g6SriJDgf+YuZnTUatCSIIid9lHE ZUtrcm9d4jA/kl9FFEnvgEgHX66KLvMhDGzTzzj4m/Yd0SHP6Sg5N+PKD6i0E0P+oy+i QxKUl78PfcCi+jbNvASi0WarAZ+zHsiJ6hcQh4WxN7o9w7jBDNaBsU/j13GtlTM/KmBd VsS/BZNtBQipC1k3xmwAMI/sUJJZ2I+pHyF4HaYBTBK+MpJVpqzdGQ4PhGdKg7JT6xQu RJP5DtkZb0VnQbK1h9m6qlL3Z7yRd4TQlaVNlZ04NlH9PqU+5kYO/2pnR1icIJjcCzYo Jblw==
X-Gm-Message-State: AOAM533ubrfAIowakmdVG+3o26dyyFn7uu+yH30xB8u2xU8R/2C7L2C/ T9Sw00MH9KGU0jemD/9bWRLHrcfHNGY4enuKosk=
X-Google-Smtp-Source: ABdhPJyEbMWPmoIzp8dSYLfxakuCu1oiPDL4FrVcdCKQGYCGueayAGjhj4asmsIxd6irTTnW6d+axvWOJse7B+uwj0k=
X-Received: by 2002:a17:90a:c254:: with SMTP id d20mr830289pjx.112.1605645630789; Tue, 17 Nov 2020 12:40:30 -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> <CABNhwV1pK5JX5sDcPyRKuR67eAkAq-q3wRmYqbsfCwOj0wWjSw@mail.gmail.com> <32DFCE3A-D41C-48CA-928A-37011D158AEF@cisco.com> <CABNhwV0xyWbV_BCn5YmRpVha+hc7SWYSaGTPGwvueW=HxhEj+w@mail.gmail.com>
In-Reply-To: <CABNhwV0xyWbV_BCn5YmRpVha+hc7SWYSaGTPGwvueW=HxhEj+w@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 17 Nov 2020 15:40:19 -0500
Message-ID: <CABNhwV2sgbycr2-uNTuYfVEMUvbE78z9FeCNM8+pky5q+ApQfA@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, Jeff Tantsura <jefftant.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000755c1705b4538185"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/oOleA4NlPF0F1SijjCa_1JxULKQ>
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 20:40:34 -0000

Robert

I am recalling now the BGP use case you mentioned.

If the next hop is being summarized between areas which it would be, the
next hop failure component prefix is now hidden in the summary and now you
have to wait for BGP timer to pop and route withdrawal.

So for this failure scenario one option is multihop BFD but that does get
way complicated.

So here the obvious and best use case for PUA would be for the data plane
detection of the next hop component down at which time PUA is sent flooded
and the routers in the other area now set next hop to null for that next
hop and are forced to converge on alternate next hop.

Let me update the presentation to add this use case.

Thanks

Gyan

On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

> Agreed.
>
> Robert
>
> Can you explain the BGP scenario you had in mind that you have mentioned a
> number of times that you think this PUA feature would pertain?
>
> I will respond to your other email separately.  I was trying to guess  as
> to the BGP next hop use case you were referring to but apparently was way
> off.
>
> Thank you
>
> Gyan
>
> On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee) <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> on behalf of Gyan Mishra <
>> hayabusagsm@gmail.com>
>> *Date: *Tuesday, November 17, 2020 at 4:02 AM
>> *To: *Robert Raszuk <robert@raszuk.net>
>> *Cc: *lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Aijun
>> Wang <wangaijun@tsinghua.org.cn>, "Acee Lindem (acee)" <acee=
>> 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> 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.
>>
>>
>>
>>
>>
>> --
>>
>> [image: Image removed by sender.] <http://www.verizon.com/>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions Architect *
>>
>>
>>
>> *M 301 502-1347 13101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>> *Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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