IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Wed, 15 June 2022 14:04 UTC

Return-Path: <robert@raszuk.net>
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 0C74AC159492 for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 07:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 8titlBO7wRWk for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 07:04:52 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CCBC157B5A for <lsr@ietf.org>; Wed, 15 Jun 2022 07:04:51 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id g25so23448540ejh.9 for <lsr@ietf.org>; Wed, 15 Jun 2022 07:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bStqlLX3DyC3SS2mBldBITiyY1I9v87IO14x6qSkwyY=; b=KXLT0zZUS7aH+S27ydqK/3ISVmM1Z+3gUTWoQk3XnrkUIjpTHsZQM7UbK6JkXjd4h4 lzowINjtGJfTpIMiIOngXPRix5LdP1t/0JOqQYM2QLqgPcLr3ndWuggO9ktvKrQp2eSf O96H1Go+PIYQ37XCFxK0jxUWwBmK7lrzDdIU6o645mPbsH+PPm6Wk0zP5HRvzbgSXcur d93kJPptIK1IfNC4S2l4xLk6I/E1appfABuG56GE5HMQ5DKBnKBjtFWlQoamofL8y9dE 6RBgHtJgdyBHEnK11wWD9OpW8pd2o/bSBJTB2c/7+AzVdpyauQkkuSOvO6Qrv0goBBlk 0CsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bStqlLX3DyC3SS2mBldBITiyY1I9v87IO14x6qSkwyY=; b=uT+xGfIvqtxJQk6mU4DUXlCKokDivZTis6LQkTt6fFzY44rrG9YeNsJS9yzGR3Q8PO 9bfTIEFlXnragKw6FtbdWJidGUDlE29wVl+VKNbWzESqV4RECy3qBMy+RFG36EsP4HLW /RWcXM+gbB430z6mwhgXwT0Kvhae7WT0X1Y/NMRbxKxw2rz4BpPOZZsiAHDbMqbK42u4 WnMgWHw9r5T5kG3Wgtfc7J9UA7J72JpDDESYUCuYmplC9vGmImfTBrg9qZuBKz/oOWqb CQ4xfM3FoUGhY3UPXj/XvG/hk5SNOqzFiVrEvB/aIPP/7cnbUIvPzJTp/iHkFTddG/nG 96yg==
X-Gm-Message-State: AJIora8YxWCMAH4EzOichETku5f/Npc3UVbCKHiK8K2qktnhejnhp95x EO8KWhrTSPXeoMG27QDvt6oguIuHSvpgbkrKlaoiOQ==
X-Google-Smtp-Source: AGRyM1sI7NKiKyRBC1lmzDUWB65Ayqio9rMJkGgDxgWd7J6onzdw/zDK24f+fRoXDwhD6pP4aErBaHEfVSXhbwCtNSY=
X-Received: by 2002:a17:906:aad9:b0:711:d024:4b9b with SMTP id kt25-20020a170906aad900b00711d0244b9bmr4748ejb.490.1655301890177; Wed, 15 Jun 2022 07:04:50 -0700 (PDT)
MIME-Version: 1.0
References: <41ba8fd6-ab16-6278-ba22-91a6a632ed33@cisco.com> <B8F7E718-28A3-4F97-A171-72774F8F1ACF@tsinghua.org.cn> <a71b7df5-4f15-a3ca-6783-3304dacd945b@cisco.com> <CAOj+MMGcgP-hH6zi_7NAkfBbQoGw0Si=55XyK_uEuA76TuGJ7w@mail.gmail.com> <c713806d-6c30-c706-850b-91e3fbcd40ba@cisco.com> <CAOj+MMHZkTJ3kKdgRxFvOzZhdQYrnp1Hn2gANmu_SmntQV5-zg@mail.gmail.com> <9abe29de-d9a2-a65d-d979-c5955e00da93@cisco.com> <CAOj+MMHoHiX+ZhTMRm9UtgupexvwfjiuCG+5EVO5+g4eJB7WGw@mail.gmail.com> <36918b32-9a00-5212-1277-cf7a19826182@cisco.com>
In-Reply-To: <36918b32-9a00-5212-1277-cf7a19826182@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Jun 2022 16:04:39 +0200
Message-ID: <CAOj+MMGG9bwiZURoiL4O7HU0cH7kvRzBO+LOC9uQ+FCdwtCJpw@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000029164205e17d0110"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/aWA-1ngwTUdR0HfrySO5QPt7nhA>
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 14:04:56 -0000

>
> looks to me that you are trying to steer the discussion towards the BGP
> based solution. Not something I'm interested on this thread.
>

Not at all. It was you not me who used argument that UPA/PUA is useful for
networks with no BGP ... example:

Quote:



*"I have explained that several times to you. There are SP networksrunning
the services on top of p2p IP sec tunnels for example, with no BGP."*



> > Also not all tunnels have keepalives. I am talking about mGRE
> > encapsulation as an example where you simply encapsulate and have no
> > idea other than consulting RIB if the dst node is up or down.
>
> in such case you can not use summarization at all.
>

Ok. Good to know :).

Best,
R.

PS.

Btw important point. Yes networks experience scale limits. But those limits
are usually not due to exponential grow of number of PEs. Such grow is
often associated with moving network services from routers to compute
blades. And guess what protocol is used in underlay to those compute blades
... BGP :).

v2.23.0 | Report a Bug | By Email