Re: [Lsr] Prefix Unreachable Announcement Use Cases

Tony Przygienda <tonysietf@gmail.com> Fri, 20 November 2020 09:45 UTC

Return-Path: <tonysietf@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 BE7633A12CD for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 01:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 KWD14Vbo4_69 for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 01:45:23 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 32F9B3A12CA for <lsr@ietf.org>; Fri, 20 Nov 2020 01:45:23 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id s10so9302470ioe.1 for <lsr@ietf.org>; Fri, 20 Nov 2020 01:45:23 -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=wng7qePEw6Kv2OPy7aZlHAd8bQRQNplFxvcEH95tnj4=; b=tSmfwiKbxwuuoTkaUFY/Pha716gIRg/IRadKlTcsKlIrtXr5zWU+EsmBVnIpR4l0KY 7SOx5s9G2ONQOulIE/IdP2ufsa9UROqN6T1SMqU3WKybpWrPtyO2brdV9yrIPsM6qGmL eFJbZonSje84FqzKnD1UVQqMfvHqczAy59zRirpmCMQi12LCwcsdEj+uO0/vJHaxj45V x8GILNndZJ41mj4Dw2eEc94LFWAp6VHWbfRpf7w99eo5H+yD7S/FSHwLPhwIQ0lGuwMK tq+RHO6MJZGLr4Tj7gSInA2p7j2K7ESwIjhQOuTVp4YMTCdzwoM1jSub/NDjJbWxHIsT Jfeg==
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=wng7qePEw6Kv2OPy7aZlHAd8bQRQNplFxvcEH95tnj4=; b=NvKbbW3uu1HGYkmzwfHGrLy0D4/rYOKBee62gC+5ESSFA8qxKwupZj4NT9Gy2JO9vN tMFMZuOnCJwiwCkhYSnmaaPWNxfXnYO+J4cBw4sg5lsgUO44KSA7t7lnxvpUAb0SjamE GI1p9MStDhiOub3ghtayzGQ2iRy4Z83bYNo0GCvGYyO1u4LUJQrvdGu9UdZSX19N0b43 XWr4jPuUowLEUr713KoxJ5UZZ3vmnGD8TbBDM5IYEy0V8s46Mpl5U9ivLqPz26U0rM4s 5mg/SC1Oyyl6h2dd1767tKb3rCWlrSJHFx8SGKQGZNTooZw+4J9DZo9ab+0Zd/e1m0DJ /EpQ==
X-Gm-Message-State: AOAM531cRgrpbfWanyFdbIMrEjbGdXO/33RSQ4LNnq88L+ZxMDO9d/1Z dbYxmcO2peFutDnoreVLe9ke4RSySDT7ClU+Qu8=
X-Google-Smtp-Source: ABdhPJxwrxVZqefd9G3WqH/0WhISJ4E/VhAAnLJNXeHA0V6xMP6DIQESFuOc/Zw+fYqRdedpQZ37PqycmZYD7UKbiK4=
X-Received: by 2002:a6b:8bcf:: with SMTP id n198mr23704581iod.122.1605865522379; Fri, 20 Nov 2020 01:45:22 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMEREV+TCwNiptdVj--HjD5nJV8zOiUJ5THcsomWCa1jJA@mail.gmail.com> <B0A6A569-30F7-4751-9F3B-C65BD23D39F3@gmail.com>
In-Reply-To: <B0A6A569-30F7-4751-9F3B-C65BD23D39F3@gmail.com>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Fri, 20 Nov 2020 01:44:45 -0800
Message-ID: <CA+wi2hNY4tAxoAbQNb13z+CNcP8+GPX2eKV_poFLrrr5TudmsQ@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, lsr <lsr@ietf.org>, Aijun Wang <wangaijun@tsinghua.org.cn>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004be4d05b486b421"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E_OgX075iU8IxK5OuGylxBlj3Tk>
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: Fri, 20 Nov 2020 09:45:25 -0000

Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
work is fine (and normally, when inspired by an idea at least in research
cycles it is considered basic courtesy to refer to the according source,
something has been lost more and more in IETF over time I dare to observe
which in itself reflects on the community IMO) but please do not try to
compare the two beyond that. Disaggregation works well on directed graphs
(lattices) or arguably if your addressing scheme is aligned with regular
topology (hypercube e.g.). it works in generic graphs in super special
cases only & it will be @ best a crutch that may under all the correct
circumstances have some utility but probably ends up hurting operationally
more than helping. The indication that "magic timer" is needed in the draft
should be first warning, all kind of seat-of-pants heuristics to dis- and
re-aggregate 2nd.  Just quickly flying through the draft I see lots of
logic problems already that will lead to vexing effects, e.g. indication of
missing neighbor will work in specific type of topologies, in others
varying by one link only may lead to stable blackholes.

my 2c

-- tony

On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>
> On Nov 15, 2020, at 08:44, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> _______________________________________________
> 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
>