Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 15 June 2022 00:36 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 0932DC14F719; Tue, 14 Jun 2022 17:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpzTdxNb976u; Tue, 14 Jun 2022 17:36:41 -0700 (PDT)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597C3C14F75F; Tue, 14 Jun 2022 17:36:40 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.97.163]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id CB3A31C00E5; Wed, 15 Jun 2022 08:36:37 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-AFD1751D-8AB8-4DB0-96DA-3BB457043CD1"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 15 Jun 2022 08:36:37 +0800
Message-Id: <C3F4A00F-3F1E-4FFC-AFC6-D72CA90DE01D@tsinghua.org.cn>
References: <CAOj+MMG3KC=wCYM2hKuK64jfMrPW3aQPWbx4Lma1fSaogGHnMA@mail.gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Christian Hopps <chopps@chopps.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>, draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
In-Reply-To: <CAOj+MMG3KC=wCYM2hKuK64jfMrPW3aQPWbx4Lma1fSaogGHnMA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19F77)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWUJPTkhWSR8fSBlLHx 4YTEJKVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWU9LSFVKSktISkxVS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MRw6Nhw*Cj06HwITLzEKESg6 MzIKCx1VSlVKTU5OSU5ISEJDSU1MVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUJMVUpNSFlXWQgBWUFKTkhCTTcG
X-HM-Tid: 0a8164ca714dd993kuwscb3a31c00e5
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/FpfoaAeNNScxyS9AJ71xRupDFu0>
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 15 Jun 2022 00:36:45 -0000

Hi, Robert:

Agreed. The potential usages of PUA/UPA are not only PE routers(for BGP PIC), but also prevalent Tunnel technologies(GRE/SRv6).
All these nodes are important and we can’t punches so many holes in the summary range.

Aijun Wang
China Telecom

> On Jun 14, 2022, at 22:43, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Acee, 
> 
> > Note that any good implementation will allow one to punch holes in their area ranges so that critical prefixes are advertised or
> 
> Every PE address is critical. The story that one PE can be more important than any other is just to mislead you at best. 
> 
> And we are (I hope) scoped the discussion to summaries. 
> 
> I realize  PUE also wants to cover P failures so in this case each P is also equally important. 
> 
> Thx,
> R,
> 
> 
>> On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee) <acee@cisco.com> wrote:
>> Speaking as WG member:
>> 
>>  
>> 
>> From: Lsr <lsr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
>> Date: Tuesday, June 14, 2022 at 9:27 AM
>> To: Christian Hopps <chopps@chopps.org>
>> Cc: Gunter Van de Velde <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>, "draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org" <draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
>> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>> 
>>  
>> 
>> All,
>> 
>>  
>> 
>> > What is wrong with simply not doing summaries
>> 
>>  
>> 
>> What's wrong is that you are reaching the scaling issue much sooner than when you inject summaries. 
>> 
>>  
>> 
>> Note that any good implementation will allow one to punch holes in their area ranges so that critical prefixes are advertised or included in the range existence criteria.
>> 
>>  
>> 
>> Thanks,
>> 
>> Acee
>> 
>>  
>> 
>>  
>> 
>> Note that the number of those host routes is flooded irrespective of the actual need everywhere based on the sick assumption that perhaps they may be needed there. There is no today to the best of my knowledge controlled leaking to only subset to what is needed. 
>> 
>>  
>> 
>> But this is not the main worry. Main worry is that in redundant networks you are seeing many copies of the very same route being flooded all over the place. So in a not so big 1000 node network the number of host routes may exceed 8000 easily. cri
>> 
>>  
>> 
>> Sure when things are stable all is cool. But we should prepare for the worst, not the best. In fact, the ability to encapsulate to an aggregate switch IP (GRE or UDP) or nowadays SRv6 has been one of the strongest advantages. 
>> 
>>  
>> 
>> So as started before the problem does exist. Neither PULSE nor PUE solve it which are both limited to PE failures detection which is not enough (maybe even not worth). But PE-CE failures need to be signalled in the case of injecting summaries. Maybe as I said in previous msg just BGP withdrawal is fine. If not we should seek a solution which addresses the real problem, not an infrequent one. 
>> 
>>  
>> 
>> Best,
>> 
>> R.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps <chopps@chopps.org> wrote:
>> 
>> 
>> 
>> > On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
>> > 
>> > What is wrong with simply not doing summaries and forget about these PUAs to pinch holes in the summary prefixes? this worked very well during last two decennia. Are we not over-engineering with PUAs?
>> 
>> 100% yes, IMO.
>> 
>> Thanks,
>> Chris.
>> [as wg-member]
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr