Re: [Lsr] Prefix Unreachable Announcement Use Cases

Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 November 2020 22:44 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 47ADE3A0E37 for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 14:44:58 -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=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 9erkwQI20rpq for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 14:44:56 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 F1F013A0E33 for <lsr@ietf.org>; Tue, 17 Nov 2020 14:44:55 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id gv24so1285509pjb.3 for <lsr@ietf.org>; Tue, 17 Nov 2020 14:44:55 -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=y9pmgIJZT0UCQ13cQ/lPHX/Xhk4jUFC+4Jk6VvU3MXI=; b=Ii9NHKpx49jFPqvQlfbgYwxzNM2dfPiUogz3eIpvBhUS00a745NSmXwTSKeuvW+tS4 RqHKUL18LpGL8z4Mwmjfc5LOpV2UnQA/rRL14vdggg7UH+cr1CWZFTB1+HXJZ9yH4Jpu B2Of4B5RhZFmCj+8ZfmfGYVvlf7bKXxUqhmqJaSF325TQ/MI09pblYpRq71ydedp0D4H lqRKj2TyZ50O/oz0pnnhQAAgO1Z0W5Tw10ci9Aw0YxFKV2AQaB2dJoO/vypKVjvYltU+ yk8eiU5co1OccFn2pf5YFhuUA4y+dOVbAdlGcJPb+yIF2ncgBus7hWI83t0rkiMEFHy9 VA8w==
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=y9pmgIJZT0UCQ13cQ/lPHX/Xhk4jUFC+4Jk6VvU3MXI=; b=dX5JTm3xN+VFtVeGvguw3BpIeVgXbi1xXCvezP17RqXOndt/ekYFDBrbf4GH+7/aHL HbMcGyX+i6lxtKuXDF5xprti+fYgL7lckeqMkCfctEq15cFOZ5QukEy7uFdNnG8A9m5I B/JPBiZd8NxVMiVgfJI3lQzbb/ju7csOI2oeOECEqLiFVafd7nIxmrs+R0pt6STOSMWJ 8XeZBxsGhM/P1MRTwxqKyCKZ7dZb8Pq/9br96a427AVZs8Jjj7YsnnhYBFb0lJIHjm/O GNo+7bQLBc6c/Hz6xeLspozRN5viL20MHTfvBW2V3D4z3oNkBHM3t0Tp9IungPrrACEV B/6w==
X-Gm-Message-State: AOAM5316XbaTk9bbJkmpxigrxlDTat2XO/x6l4L1FNGkpdtG/lUsWRds XmtXCHNkTFiab5Wc4HPnlzRPoxrJNiSVpCzARh8=
X-Google-Smtp-Source: ABdhPJwygt6ao38AFLszPfI/73CGxPKrYjXEOzRpUnntwVhpouD6QHg8bYwi0p5f7ETIokHR54IJoJ5ov89Z32SbtMw=
X-Received: by 2002:a17:902:c395:b029:d7:cdcd:76bc with SMTP id g21-20020a170902c395b02900d7cdcd76bcmr1261457plg.50.1605653095449; Tue, 17 Nov 2020 14:44:55 -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> <CABNhwV2sgbycr2-uNTuYfVEMUvbE78z9FeCNM8+pky5q+ApQfA@mail.gmail.com> <CAOj+MMExKX8fOcGy3BDdfXzYK5197W_6P6vyc=TRLcO43JBfjA@mail.gmail.com>
In-Reply-To: <CAOj+MMExKX8fOcGy3BDdfXzYK5197W_6P6vyc=TRLcO43JBfjA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 17 Nov 2020 17:44:44 -0500
Message-ID: <CABNhwV0TAoqFMHOHZMzcZXfgUhr_iO6WeLkK=U0xNzC_bgy8Dg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, Jeff Tantsura <jefftant.ietf@gmail.com>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006306b505b4553ed9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/llwn0n8Q86iUHGDgqrDQ0LTOIO0>
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 22:44:58 -0000

Thanks Robert!

I will work on spelling out the scenario in updated LSR presentation.

Thanks

Gyan
On Tue, Nov 17, 2020 at 5:31 PM Robert Raszuk <robert@raszuk.net> wrote:

>
> Yes that is the case where I see some potential use case.
>
> Especially considering also https://tools.ietf.org/html/rfc5283 - which
> by many network operators is very desired, but not configured due to "slow
> BGP convergence" - pls let's not go there :)
>
> But again if someone knows how to configure BGP properly I think IGP
> speedup would be marginal or even null hence a grain of hesitation if we
> should use IGP flooding for it. Maybe in some scenarios ... which PUA
> authors need to spell out to move fwd I suppose.
>
> Cheers,
> R.
>
>
>
>
>
>
>
>
> On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>>
>> 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>rg>, Jeff Tantsura <jefftant.ietf@gmail.com>om>,
>>>> Aijun Wang <wangaijun@tsinghua.org.cn>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>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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>
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>>> Spring, MD
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%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
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+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