Re: [Lsr] Prefix Unreachable Announcement Use Cases

Robert Raszuk <robert@raszuk.net> Fri, 20 November 2020 20:45 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 BE1643A116E for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 12:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=raszuk.net
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 wN-naVLc-9Bm for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 12:45:25 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 3335E3A1166 for <lsr@ietf.org>; Fri, 20 Nov 2020 12:45:24 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id a9so15324007lfh.2 for <lsr@ietf.org>; Fri, 20 Nov 2020 12:45:24 -0800 (PST)
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=TdSjT4lBXFM4f4ZlvHn7hA2mSwGZ3O9XdzNskRTLXa4=; b=WVWvoykStt12OUvYpJydUl40cljNqiJOIYatJsmShzzxvT2ZUGOJy+huqNkRFoaE+y Fd6mW8Uz3Gm+FlGa3o3O/kSkhnQ/Uvhj+nRIAo/11hLE+ZPmK0crTp6SzpoJ7Qh5hMbi iRABxnUDvUeS6cEcGCHYvaIgbQyn+EKbdofchu3iUmnIYo1W0aRaDQN70XWmQ9RnLfvo lFEcTQEDbTRPnxYdcflcdbTCID12/4PYfYgo6rPIeSF373NYmeTudvRGq1/ZvaWfzd9x 5bJyHbghZXGki7grCjQcgaz69lZmH9SABEUKg3RIplvIAD0aKKUai6kdKnb56tGzUi2l MSDg==
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=TdSjT4lBXFM4f4ZlvHn7hA2mSwGZ3O9XdzNskRTLXa4=; b=fBRcdXJLIQHhIBZ6O5zDp/+HUHuPYN9ZFU6chXcEYq3kfXkKjAFpdqnBEVW0aDGOz3 i3YH64wkYuq1ebqbt0EPv7OpIKJBIJx7DbBgxj+dGgUiPVCFlj5TnrAngqviMQv00s5x YNpo3a41fhtfNkBeAVTJdKs04XLxlsehlndYjHrb/NwZsuEgLp1qLrDXGsQaHGymF9r3 lOSvf6G/+nECsHFd2CtClL/HcQCKqzXqPCRe4rof7pz4RFq9XxJV7Rv1hwcsVZPPaw/j pY5x3EaTssJrhjHC7I8c9D5maBoFBFautvmmDcPUsKsg8zTmUf07yy/VfyzTWeSB6tjA GrxQ==
X-Gm-Message-State: AOAM532+MM0wSnsJuw8hQJ6Xwx4XAHis4nnFOlQKaIvV1z3e4I1usR1n 3zakHkSn7H4qq45sQGFs7aelSe+Krl7cNJ4qofxwVg==
X-Google-Smtp-Source: ABdhPJw7l7UFtG4AvC0hHpKoWxoY1unFba0pmFM1eKeJ1DaVXKny56jtuqaSwzFVbYaLK4X551hSYWrAWC3chVO8/f4=
X-Received: by 2002:ac2:598f:: with SMTP id w15mr8172810lfn.148.1605905122711; Fri, 20 Nov 2020 12:45:22 -0800 (PST)
MIME-Version: 1.0
References: <CA+wi2hNY4tAxoAbQNb13z+CNcP8+GPX2eKV_poFLrrr5TudmsQ@mail.gmail.com> <8384F1B4-7AB2-4951-BAEA-3FC02A0ADDBD@tsinghua.org.cn> <CA+wi2hPza=KBJHHjQkqLDQKvZ=-D9uSTXEnSqzmb-xXi_eVARQ@mail.gmail.com>
In-Reply-To: <CA+wi2hPza=KBJHHjQkqLDQKvZ=-D9uSTXEnSqzmb-xXi_eVARQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 20 Nov 2020 21:45:12 +0100
Message-ID: <CAOj+MME7NjfzBpoQmr5pxvtmKMr400_hR8M4_Diyp=6uALbdXQ@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000061f57c05b48fec53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/88CRpbJq5d0_BJqf2WNvtdf_7-8>
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 20:45:30 -0000

Hey Tony,

>  people somehow implying a map of RIFT negative disaggregation in
relation to this work

I think those people just made a subtle point that considering IGP alone if
you want to influence your data plane forwarding by advertising PUA in
today's hardware you really need to install more specific blocks of the
summary routes which PUA punched the hole in as sent by say one of the
ABR's. Analogy made to RIFT was just limited to this data plane fragment
only.

And that comment was not to compare PUA to RIFT negative routing in any
way. It was just to a) realize what could be required if such a use case
continues and more importantly b) highlight that if we just use PUA in the
control plane to for example invalidate BGP next hops or other overlay
service routes the disaggregation piece does not apply.

Cheers,
R.





On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda <tonysietf@gmail.com> wrote:

>
>
> On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang <wangaijun@tsinghua.org.cn>
> wrote:
>
>> Hi, Tony:
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 20, 2020, at 17:45, Tony Przygienda <tonysietf@gmail.com> wrote:
>>
>> 
>> 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.
>>
>> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
>> it encountered, but welcome the experts have such design experience to
>> point out the pitfall that PUA can bypass.
>>
>>
> aha, ok, I just chimed in because I saw people somehow implying a map of
> RIFT negative disaggregation in relation to this work but if this is a
> completely different mechanism than I just watch from the sidelines
>
> thanks
>
> -- tony
>