Re: [Lsr] Prefix Unreachable Announcement Use Cases

Robert Raszuk <> Sun, 15 November 2020 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46A443A09C1 for <>; Sun, 15 Nov 2020 12:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UkyuEc0R3H7X for <>; Sun, 15 Nov 2020 12:03:48 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 411853A099E for <>; Sun, 15 Nov 2020 12:03:48 -0800 (PST)
Received: by with SMTP id w142so22021767lff.8 for <>; Sun, 15 Nov 2020 12:03:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fk7GrjU5SbLsW5g9DlMxhmDf3r5H3MiY/Hf0+OD+phs=; b=SWnFrf9bBPGoFxWbKJyt4ldq3tNw/hAcBakqTm+OPG9lvshmBZ376dwKNulrMe/+mj wBtWEApeOxDK+CLWZHmRItJj1quZ1g48AZk5EtcUrFGVJr2dpQPp4ltoVrIlKaXNaUVl rvJ0VQHOb/SwQYikJvIJXVLImo4f/f44rqgF8R/lZKJ0+3reuNtpXiU5bymh/YN8Hxpr vOYLy/8ruxYe16z/QMUvvYEAuVDXS3W+zpmyzrCo1l+wYBEq/o9fZ7mwbcwlP6bQ1rUO cHR5sLYv3esb5F2ynjQcWBdu8miZdWi0+WGQqDJ67BdPjfmsRJPv3+dIQ+arfHyXlt43 JL7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fk7GrjU5SbLsW5g9DlMxhmDf3r5H3MiY/Hf0+OD+phs=; b=aZx7SlY6lOxYZ29WylLd3HXphgYnayP/1NoUTKI/SikZFtVmn9h4eqzEDmB7XMMa1A n+rXHmkDVFD5w6Lf5QuhDA+TgIInkz5Z4kbhq1LL4ozuXLQyCiIzuk1y1R8s5CS5L9Ws bjNVyQrBjElJM085UbZDdyWgdjNu3zD6bijLZAjWjfu7XGTY7VjKL3w1uqj7Uv2EIEOY LibTXJAnIVIZohBJbNpgpdVR6FHKNAkD8pltc2qTd22Xp+I5V5jZnonRINzIabhAsbdy dLFrzOAtAfhPNug2ONh0C1o5CQE0q+ihd+YwlnsZVTWzSH2QDucgKZBdhhjDQT4KEktG Wg/w==
X-Gm-Message-State: AOAM531m3N+Ay9GhWIDCAyISh8cEczYYcF09viPuyOrzovCWvCn5pPEn o0yrWM2M6RxQVyuldzey6OSnkEO+ootWexUtjRFRlg==
X-Google-Smtp-Source: ABdhPJyVjbMqjU7aDlIEjyI0tsSQBCK5zywlizJ/1UARIhmEJzACySiTInvuIZ0s6wlrkkifY7BGDUT9ZFi2lx0ALC0=
X-Received: by 2002:a05:6512:285:: with SMTP id j5mr2278315lfp.269.1605470626131; Sun, 15 Nov 2020 12:03:46 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sun, 15 Nov 2020 21:03:36 +0100
Message-ID: <>
To: Jeff Tantsura <>
Cc: Aijun Wang <>, lsr <>, "Acee Lindem (acee)" <>
Content-Type: multipart/alternative; boundary="0000000000005e4a1f05b42ac2fb"
Archived-At: <>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Nov 2020 20:03:50 -0000


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).


On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <>

> 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 <> 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