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

Robert Raszuk <robert@raszuk.net> Wed, 15 June 2022 12:48 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 DE934C15948A for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 05:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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] 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 gIZI43gVMOiD for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 05:48:00 -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 D8F0EC14CF0C for <lsr@ietf.org>; Wed, 15 Jun 2022 05:48:00 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id h23so22976135ejj.12 for <lsr@ietf.org>; Wed, 15 Jun 2022 05:48:00 -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=0MbFOru0SmzlKldS6dhKPkT13J0IBU3x9HWYIfPd74I=; b=Mwv1cXY8FKZZrn5jeU+eterJcgJXsaSarDY57KpDSUsK2ShBALACwHG7i8UZrVMfL8 Eu7CkpeyxF9fxF9Msql6lTSgFGDKTZWVxpZpnpbztjvBZjnkxTwowQrYPsRvXuscM5dp 93WkfJBSBaQFJ0YZI9QWrds9AWbLajzBTBHD08WAMtTv7SdHxI8tThu8xntlkBjoc38F dm9nIUAdNIqsVWvg1SPVpSf/uJXWhzsWT2SImCe4vKfMGERaTxjnH5bN6zBQtT5XHCFj l1GuqqNSWzhBfOR9gAlF4RjuD02Pc49owRPHkSc4GM0i3Dzk8mkIgWggNvG+61SgWdVZ avVw==
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=0MbFOru0SmzlKldS6dhKPkT13J0IBU3x9HWYIfPd74I=; b=0vqv8OTcHTg3SRg7HBt+Tu17KucpLtczBYZq+PsjKRpjxwGV850sRBj3Y94cAi6jSg T49aJ9XbYDFqRwYsBGea9m5XZ39yzXWjEZ3I2Ib/srYC14XpRaBg0tkV7uTVPGISrcNV 8l3+kSTnq214DR6UFfy5oi5bFHP0vlIbhhFfFcaIJuPIc5cGYs8utyyt94lCUXvXhPWo ibk0mB8p5pHGXF86Jbf3PCqC6HlPY/QfaeuVh4yoLptNnLyWfW4bi9PHzprwx3m6aG2G fuDj9gHvZFdsf+UtEuufospJw1KIwahXUI2PD0cA6ptdK8KzYb83WKrI+M5jqeYSM90f y3JQ==
X-Gm-Message-State: AJIora8kgv243YHU3yp7JTldyqU4Yd1GLVXgvVISatDdI0SS8cAX78OC 9OGqWhfpPwXW2SE7GnVwiDjnXduiNF6HbPYyvY906g==
X-Google-Smtp-Source: AGRyM1sHl1+miLXghhX5om7h25JN30Shk2whB3y8JZcIAgmmOTGybK2wuKuLZqu293d4fiMCcJSiaSke6dRnKqvmmX4=
X-Received: by 2002:a17:906:6a1a:b0:711:ec13:b7bc with SMTP id qw26-20020a1709066a1a00b00711ec13b7bcmr8643983ejc.688.1655297278931; Wed, 15 Jun 2022 05:47:58 -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>
In-Reply-To: <c713806d-6c30-c706-850b-91e3fbcd40ba@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Jun 2022 14:47:48 +0200
Message-ID: <CAOj+MMHZkTJ3kKdgRxFvOzZhdQYrnp1Hn2gANmu_SmntQV5-zg@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>, draft-ppsenak-lsr-igp-ureach-prefix@ietf.org, draft-wang-lsr-prefix-unreachable@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004f089b05e17beef2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/QTVfad3eGqHzEhsOZIyOPCNLwtY>
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 12:48:05 -0000

Peter,

My question is precise .... your answer is pretty loose :)

Imagine I use summarization and as you many times said there is no BGP
running. So how do I indicate planned scheduled maintenance in such cases ?
Say from either ABRs or PEs/Ps itself ?

In fact, looking practically that may be much more useful and needed then
signalling node failures.

And the issue I observed with using UPA is that as it is ephemeral it may
not work well during extended maintenance windows. Stateful solutions
however would work fine.

Thx,
R.







On Wed, Jun 15, 2022 at 2:34 PM Peter Psenak <ppsenak@cisco.com> wrote:

> Robert,
>
> On 15/06/2022 14:13, Robert Raszuk wrote:
> > Peter,
> >
> >     the meaning of LSInfinity has been defined decades ago. No matter how
> >
> >     much you may not like it, but it means unreachable.
> >
> >
> > True. But that brings another question ... Do you envision to use UPA
> > also to indicate planned maintenance of a node ?
>
> depends on how the planned maintenance is performed. If yo just turn the
> node off, UPA will catch it. If you instead set OL-bit, or use link max
> metric initially, it may or may not be used, depending on what the
> ABR/ASBR is programmed to do. There is quite some flexibility if needed.
>
> thanks,
> Peter
>
>
> >
> > Thx,
> > R.
> >
>
>