IETF Logo Mail Archive

Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff Tantsura <jefftant.ietf@gmail.com> Sun, 15 November 2020 20:20 UTC

Return-Path: <jefftant.ietf@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 7F5CD3A0D74 for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 12:20:23 -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 uzbfHDOYnxN7 for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 12:20:21 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 7FC653A0C97 for <lsr@ietf.org>; Sun, 15 Nov 2020 12:20:08 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id m9so1232204pgb.4 for <lsr@ietf.org>; Sun, 15 Nov 2020 12:20:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=d5zBsnMrxOvUFrlhh8lnQYuoBLE7/liQYyFXV1F92dQ=; b=TDLcqceX0j2KGjr19Fhnga7nO9O0C1zyWmEfi2HqE6eCl7wwJby7oH/ekg5S93LoGc jQuyr5UEnWyKNO5IhkxbaQHowN94k7KkLeX9VKPhpg4aG5k3nWBVRDzrusQELutnCpFu jEl2knlsCcAKSNQD1uKxQiU3rP4Fwmn1Ybp2QFXN0OVGXa2Xf0xxYVH83bKrOdINJdxh nTQDO2osgWp5sHz0UmgcKd5gWW5oHyxan9IljrnIjpqVOoAieb9VhHY/YKoRZeejfFKT EDrhhW4JEc7akkJfbIvCsQwXyNsEPLYho0rT9qtnqW4ETKz7DjvE2cd6vbzwkWz0jjkf bQ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=d5zBsnMrxOvUFrlhh8lnQYuoBLE7/liQYyFXV1F92dQ=; b=BILhOTgrFD0AkirJoIJB605LH7sqCI76mwvwKl1uhgg5s7owXgpk/rgaAcfFR83EBI i+vFkI0p5cOS6dGKNL5lzx8k5dhgbcr4I1QsTk9TRvYSLdrGkniKF43ui/KO54vNzWHu PFdhtBI3SD4GuuKhK8Q7Aq2DccxxqVxw3ZIj0/nqRO8a5pUgpky/b1PS3WjLO3lWXvl+ apn6gh17XRRBxDyuEnKJt6OB7vHl0zRkmNH8vGWjFYrXCpnEzXMtOAycvpLOeyut02RO Fv2inQ8RRfnQjJftp1MAY2+xqXTA0KDWiOHyOWqJJ2EfHF0H+ghJ8+3BxyQMEJTT3RTF 5wXA==
X-Gm-Message-State: AOAM531HKZCTz+QXSpgOONZJGlrTOtBlflSYPnFuuCFHzqIZYJzpKvT6 PnTaXfi0ryQgjKf4Z4FKOxU=
X-Google-Smtp-Source: ABdhPJzxOaUxmpvA7jgczIJdU00FK/z6nBvtDIgIQypxH3y4Nt9Fv/u8ZTciGVb0vXImA1oL7nkGyw==
X-Received: by 2002:a17:90b:2204:: with SMTP id kw4mr12654246pjb.153.1605471608026; Sun, 15 Nov 2020 12:20:08 -0800 (PST)
Received: from [192.168.1.7] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id k5sm15768195pjj.37.2020.11.15.12.20.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Nov 2020 12:20:07 -0800 (PST)
Date: Sun, 15 Nov 2020 12:19:58 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Message-ID: <9a4b6fb8-a650-401a-bae6-647162173f8b@Spark>
In-Reply-To: <CAOj+MMEYnHeuNnNy-yDuxywMLe+yHv3QfXYqtqEgom7RbTO6Sg@mail.gmail.com>
References: <CAOj+MMEREV+TCwNiptdVj--HjD5nJV8zOiUJ5THcsomWCa1jJA@mail.gmail.com> <B0A6A569-30F7-4751-9F3B-C65BD23D39F3@gmail.com> <CAOj+MMEYnHeuNnNy-yDuxywMLe+yHv3QfXYqtqEgom7RbTO6Sg@mail.gmail.com>
X-Readdle-Message-ID: 9a4b6fb8-a650-401a-bae6-647162173f8b@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5fb18d73_436c6125_ba5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9qPmY09MMyCrlhfgkFl6fgdkVl0>
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: Sun, 15 Nov 2020 20:20:24 -0000

Thanks for clarification Robert, makes sense.

Cheers,
Jeff
On Nov 15, 2020, 12:03 PM -0800, Robert Raszuk <robert@raszuk.net>, wrote:
> Jeff,
>
> I was not bringing RIFT's negative routies example as something inherently negative. I was just pointing it out to illustrate that today's data plane lookup does not really support "if does not match" checks.
>
> So if you intend to use unreachable prefixes in data plane as result you need to break summary into as atomic prefixes as your unreachable advertisement mask.
>
> Hence my recommendation to use IGP to flood unreachable only for the purpose of control plane (namely BGP paths invalidation).
>
> Cheers,
> R.
>
> > On Sun, Nov 15, 2020 at 8:29 PM 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

v2.23.0 | Report a Bug | By Email