Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Robert Raszuk <robert@raszuk.net> Thu, 16 June 2022 09:58 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 7268BC14F733 for <lsr@ietfa.amsl.com>; Thu, 16 Jun 2022 02:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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_HI=-5, 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 1OdfMmO02iAg for <lsr@ietfa.amsl.com>; Thu, 16 Jun 2022 02:57:59 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 8E72DC14F72F for <lsr@ietf.org>; Thu, 16 Jun 2022 02:57:59 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id c2so1449431edf.5 for <lsr@ietf.org>; Thu, 16 Jun 2022 02:57:59 -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=4DF7e+tvujl3eIFjpljUt1malU/a46DzGU4bUM+/w6o=; b=AFxAXDEzCKrc4il0P2nZ/1glt4Kd1hdr79Mpp9/GVYXPMxVD4mUXe51gWcku5FJAmP JMm40LqXhs5sJ9aauNMdsbVwKWn5vgOePYCQaXeeksuPbK4ia1WuVx3JjYeZT3WomxAg wmPBwmdRq3oK4MaswagaLYd50tc6riFGXhg9ojHw46gILzdkxpvC6fm2CQYaJ+lB54oE frhcMtnkI6B+xWB4DjW+35jsTH2GPK6LwMErdpX3tKIjxxl+E8Kh4qChGeOUNAk3E4iu hwrHl0t96lC6AGu4gIfPnSFzKwxh56WLxstYrReMvz7kLHPAul65KVuEsDE8699VJZIK vCgQ==
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=4DF7e+tvujl3eIFjpljUt1malU/a46DzGU4bUM+/w6o=; b=fTyUTXW4KfEtoD2hPsa52tmDMuKsiKYqLQIlVYagw3R9rwtHmIP2lOUsq144GKJxa+ lfsqoYpkteyHiFy/9BY8yT7t8WBMtdSof1gIRieTsE17dPrDRwlNj5nfjHe+lZ++I6E1 1uFqodxuEnKFsF46C1cJhZCSZYsdNsP0z3oNjKam8V2CmD6aUE/RiQdIhrM6p87Cc1he IrJwzfjfepLhypVp1nTgtap/rW7HeISPXN6gB0wdPM64eaqKrDUEawg6b1DweLjbGLdg CMZ9JsUXtCeaqqS6Bz42Lkw3CiIWr/uZ8f+ZyV2DVCYP8oHcEPrG6cryzEmZGO/ERPG0 HflQ==
X-Gm-Message-State: AJIora/uaanZipObZH+EZK0mNmRCYB/HtQV6YWX7tdclfO/jtW9D5iEz 9I0kyuLSuumhMsw2UjDjWBi/dbcV0XW4tgLdCOCDPnQLXEg=
X-Google-Smtp-Source: AGRyM1sZn4QSHn8gqztq/yVaenIIjv01ampIZcnFuOePjeU4N+eSe54UvTaM0kU3BVT/2pQWmw0GmT/oSzq7cdX4LFE=
X-Received: by 2002:a05:6402:11d2:b0:42d:e68a:eae0 with SMTP id j18-20020a05640211d200b0042de68aeae0mr5285119edw.111.1655373477622; Thu, 16 Jun 2022 02:57:57 -0700 (PDT)
MIME-Version: 1.0
References: <5592_1655302155_62A9E80B_5592_217_2_d32a47e482574f5b99fc7c7b4e07e553@orange.com> <CE3F7A94-F22B-48F6-BD20-87F992417E60@tsinghua.org.cn> <18644_1655364632_62AADC18_18644_268_11_6fb283327bd24bf4b52d3f563c7de337@orange.com>
In-Reply-To: <18644_1655364632_62AADC18_18644_268_11_6fb283327bd24bf4b52d3f563c7de337@orange.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 16 Jun 2022 11:57:55 +0200
Message-ID: <CAOj+MMGahc9+hgFrntc6Q1Mrxm6B0T-Ufw7VfnYXcT9ChRk3eQ@mail.gmail.com>
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001acc2005e18dac3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PSz0b5H4rgeV2qC0XfTYVQqY3vo>
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
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: Thu, 16 Jun 2022 09:58:03 -0000

Bruno,

Actually I like your flag suggestion for an additional and different
reason.

If someone does not need to flood UPAs in any remote area it is trivial to
filter those on the ABRs connecting those areas to the core. Otherwise such
filtering could be more difficult if at all possible.

Thx,
R.


[Bruno] I agree that the encoding for the explicit signaling is totally
> open to discussion.
>
> I proposed a flag since:
>
> - all we need is a binary information
>
> - given the use case, this RFC7794 sub-tlv (type 4) seems likely to be
> already present. (e.g. X or R flag, possibly N-flag)
>
>
>
> Thanks for your email and your contribution to this topic.
>
> Best regards,
>
> --Bruno
>
>
>